Todos los desarrolladores de 1C de una forma u otra interactúan estrechamente con los servicios de TI y directamente con los administradores del sistema. Pero no siempre esta interacción transcurre sin problemas. Me gustaría contarte algunas historias divertidas sobre esto.
Canal de comunicación de alta velocidad
La mayoría de nuestros clientes son grandes empresas con sus grandes departamentos de TI. Y para las copias de seguridad de las bases de datos, por regla general, los especialistas del cliente son responsables. Pero hay organizaciones relativamente pequeñas. Especialmente para ellos, tenemos un servicio según el cual nos ocupamos de todos los problemas relacionados con la copia de seguridad de 1C. Sobre esta compañía se discutirá en esta historia.
Un nuevo cliente vino en apoyo de 1C, y, entre otras cosas, el contrato tenía una cláusula de que éramos responsables de las copias de seguridad, aunque tenían su propio administrador del sistema en el personal. La base de datos cliente-servidor, como el DBMS - MS SQL. Una situación bastante estándar, pero aún había una advertencia: la base principal era bastante grande, pero al mismo tiempo el aumento mensual era muy pequeño. Es decir, la base de datos contenía muchos datos históricos. Dada esta peculiaridad, configuré planes de mantenimiento de respaldo de la siguiente manera: el primer sábado de cada mes se realizaba un respaldo completo, era bastante pesado, luego se hacía una copia diferencial todas las noches, una cantidad relativamente pequeña y cada hora una copia del registro de transacciones. Además, las copias completas y diferenciales, no solo que se copiaron en un recurso de red, también se cargaron adicionalmente a nuestro servidor FTP. Este es un requisito obligatorio para la prestación de este servicio.
Todo esto se configuró con éxito, se puso en funcionamiento y funcionó en general sin fallas.
Pero unos meses después, el administrador del sistema cambió en esta organización. El nuevo administrador del sistema comenzó a reconstruir gradualmente la infraestructura de TI de la compañía de acuerdo con las tendencias modernas. En particular, apareció la virtualización, los estantes de disco, el acceso estaba cerrado en todas partes y todo, etc., que en el caso general, por supuesto, no puede dejar de alegrarse. Pero no siempre fue fácil para él, a menudo hubo problemas con el rendimiento de 1C, lo que causó algunos desacuerdos y malentendidos con nuestro apoyo. Además, debe tenerse en cuenta que nuestras relaciones con él generalmente se desarrollaron bastante frías y algo tensas, lo que solo aumentó el grado de tensión en caso de algún problema.
Pero una mañana resultó que el servidor de este cliente no estaba disponible. Llamé al administrador del sistema para averiguar qué sucedió y recibí algo como "Nuestro servidor se ha bloqueado, estamos trabajando en ello, no depende de usted". Bueno, eso funciona. Entonces la situación está bajo control. Después del almuerzo, vuelvo a llamar, con voz de administrador, en lugar de irritación, ya siento cansancio y apatía. Tratando de aclarar lo que sucedió, ¿y podemos ayudar de alguna manera? La conversación reveló lo siguiente:
Trasladó el servidor a un nuevo sistema de almacenamiento con una redada recién ensamblada. Pero algo salió mal y después de unos días esta incursión se desmoronó con seguridad. O el controlador se quemó, o algo les sucedió a los discos, no recuerdo exactamente, pero toda la información se perdió irremediablemente. Y lo principal era que el recurso de red con copias de seguridad también en el proceso de cualquier migración estaba en la misma matriz de discos. Es decir, tanto la base productiva en sí como todas sus copias de seguridad se perdieron. Y qué hacer ahora no está claro.
Con calma, digo. Tenemos tu respaldo nocturno. La respuesta es el silencio, por el cual entiendo que acabo de salvar la vida de una persona. Comenzamos a analizar cómo transferir esta copia a un nuevo servidor recién implementado. Pero aquí surgió un problema.
¿Recuerdas que dije que la copia de seguridad completa era bastante grande? Lo hice por una razón una vez al mes los sábados. El hecho es que la compañía era una pequeña planta, que se encontraba mucho más allá de la ciudad y que Internet era muy regular. Para el lunes por la mañana, es decir, durante el fin de semana, esta copia con pena por la mitad tuvo tiempo de cargarse en nuestro servidor FTP. Pero no había forma de esperar uno o dos días hasta que se carga en la dirección opuesta. Después de varios intentos fallidos de arrastrar el archivo, el administrador retiró el disco duro directo del nuevo servidor, encontró un automóvil con conductor en algún lugar y rápidamente se apresuró a nuestra oficina, ya que todavía estamos en la misma ciudad.
Mientras estábamos parados en la sala de servidores y esperando que se copiaran los archivos, nos conocimos, por así decirlo, “en vivo”, tomamos una taza de café, hablamos en un ambiente informal. Simpaticé con su dolor y lo envié de vuelta con un montón de copias de seguridad, a toda prisa para restaurar el trabajo detenido de la empresa.
Posteriormente, todas nuestras aplicaciones al departamento de TI se resolvieron muy rápidamente y no hubo más desacuerdos.
Póngase en contacto con el administrador del sistema.
Una vez, con un solo cliente, durante mucho tiempo no pude publicar 1C para acceso web a través de IIS. Parece ser una tarea ordinaria, pero aquí no salió del camino. Los administradores del sistema local se conectaron, probaron diferentes configuraciones y archivos de configuración. 1C en la web normalmente no quería trabajar en ninguno. Algo estaba mal con las políticas de seguridad de dominio, o con un firewall sofisticado local, o qué demonios. En la enésima iteración, el administrador me suelta un enlace con las palabras:
- Inténtalo de nuevo con estas instrucciones. Todo está bastante detallado allí. Si no funciona, escriba al autor de este sitio, tal vez él lo ayude.
"No", le digo, "no ayudará".
- por qué?
- Soy el autor de este sitio ... (
Como resultado, lanzaron Apache sin ningún problema. IIS no pudo ganar.
Más profundo
Teníamos un cliente, una pequeña empresa de fabricación. Tenían un servidor, un peculiar "clásico" 3 en 1: servidor terminal + servidor de aplicaciones + servidor de bases de datos. Trabajaron en algunas configuraciones de la industria basadas en arrancadores suaves, había alrededor de 15-20 usuarios en el sistema, y el rendimiento del sistema era en principio adecuado para todos.
Pasó el tiempo, todo funcionó más o menos estable. Pero Europa impuso sanciones contra Rusia, como resultado de lo cual los rusos comenzaron a comprar principalmente productos nacionales, y las cosas en esta empresa fueron cuesta arriba. El número de usuarios ha crecido a 50-60 personas, se ha abierto una nueva sucursal, y también lo ha hecho el flujo de trabajo. Y ahora el servidor actual ha dejado de hacer frente a la carga fuertemente aumentada, y 1C comenzó, como dicen, "ralentizar". En las horas pico, los documentos se mantuvieron durante varios minutos, llovieron los errores de bloqueo, los formularios se abrieron durante mucho tiempo, bueno, y el resto de los servicios relacionados. El administrador del sistema local descartó todos los problemas y dijo: "Este es su 1C, tiene que resolverlo". Hemos sugerido en repetidas ocasiones realizar una auditoría del rendimiento del sistema, pero esto no llegó a la auditoría en sí. El cliente simplemente solicitó recomendaciones sobre la resolución de problemas.
Bueno, me senté y escribí una carta bastante voluminosa indicando que es necesario separar las funciones del servidor terminal y el servidor de aplicaciones del DBMS (que, en principio, ya lo hemos dicho repetidamente antes). Escribí sobre DFSS en servidores de terminal, sobre Memoria compartida, lancé enlaces a fuentes autorizadas e incluso ofrecí algunas opciones de hardware. Esta carta llegó a los poderes de la empresa, volvió al departamento de TI con las resoluciones de "Ejecutar", y el hielo generalmente se rompió.
Después de un tiempo, el administrador me envía la dirección IP del nuevo servidor y las credenciales de inicio de sesión. Él dice que MS SQL y los componentes del servidor 1C se implementan allí, y que necesita transferir las bases de datos, pero hasta ahora solo al servidor DBMS, ya que hubo algunos problemas con las claves 1C.
De hecho, todos los servicios entraron, el servidor no es muy poderoso, está bien, creo que es mejor que nada. Transferiré las bases de datos hasta ahora para al menos de alguna manera aliviar el servidor actual. En el tiempo negociado, realizó todas las transferencias, pero la situación no cambió, todos los mismos problemas de rendimiento. Extraño, por supuesto, bueno, vamos a registrar las bases en el grupo 1C, ya veremos.
Lleva varios días, las claves no han sido transferidas. Estoy interesado en cuál es el problema, todo parece ser simple allí: lo eliminé de un servidor, lo pegué en otro, instalé el controlador y está listo. El administrador responde, dice algo sobre el reenvío de puertos, un servidor virtual y más.
Hmm ... un servidor virtual? Parece que nunca ha habido virtualización y no fueron ... Recuerdo un problema bastante conocido con la imposibilidad de reenviar la clave del servidor 1C a la máquina virtual en Hyper-V en Windows Server 2008. Y aquí comienzan a acumularse algunas sospechas ...
Abro el administrador del servidor - Roles - ha aparecido un nuevo rol: Hyper-V. Voy al administrador de Hyper-V, veo una máquina virtual, me estoy conectando ... Y realmente ... Nuestro nuevo servidor de base de datos ...
Bueno que? Se cumplen las instrucciones de las autoridades y mis recomendaciones, los roles están separados. La tarea puede cerrarse.
Después de un tiempo, la crisis ahora sucedió, la nueva sucursal tuvo que cerrarse, la carga disminuyó, el rendimiento del sistema se volvió más o menos tolerable.
Bueno, por supuesto, no pudieron reenviar la clave del servidor a la máquina virtual. Como resultado, todo quedó como estaba y se fue: el servidor terminal + 1C cluster en la máquina física, el servidor de la base de datos en el mismo lugar en el virtual.
Y bueno, sería una especie de oficina de Sharashkin. Entonces no. Una empresa conocida, cuyos productos probablemente conozca y haya visto en los departamentos correspondientes de todo tipo de Cintas y Auchanov.
Programa de vacaciones en el disco duro
Una gran sociedad de cartera con ambiciosos planes
para conquistar el mundo una vez más compró una pequeña empresa con el objetivo de incorporarla a su megacorporación. En todas las divisiones de esta explotación, los usuarios trabajan en sus bases de datos, pero con una configuración idéntica. Y entonces comenzamos un pequeño proyecto para incluir una nueva unidad en este sistema.
En primer lugar, es necesario desplegar bases de combate y pruebas. El desarrollador recibió los datos para la conexión, inicia sesión en el servidor, ve el MS SQL instalado, el servidor 1C, ve 2 unidades lógicas: una unidad C de 250 gigabytes y una unidad D de 1 terabyte. Bueno, "C" es un sistema, "D" para datos, el desarrollador decide lógicamente e implementa todas las bases de datos allí. Incluso configuré planes de mantenimiento, incluidas copias de seguridad, por si acaso (aunque no somos responsables de esto). Las copias de seguridad verdaderas tomaron forma aquí en la "D". En el futuro, se planeó reconfigurar ya en algún recurso de red separado.
El proyecto se lanzó, los consultores impartieron capacitación sobre cómo trabajar en el nuevo sistema, se transfirieron las sobras, se hicieron algunas mejoras pequeñas y los usuarios comenzaron a trabajar en la nueva base de información.
Todo salió bien hasta que una mañana del lunes se descubrió que la unidad de la base de datos había desaparecido. Simplemente no hay una "D" en el servidor y eso es todo.
La investigación adicional reveló esto: de hecho, este "servidor" era la computadora de trabajo del administrador del sistema local. Es cierto que el sistema operativo del servidor todavía estaba en él. Se insertó un disco USB personal de este administrador en el servidor. Y el administrador se fue de vacaciones llevando consigo su propio tornillo, con el objetivo de bombear películas en el camino.
Gracias a Dios, no logró eliminar los archivos de la base de datos y logró restaurar la base de datos de trabajo.
Es de destacar que todos, en general, estaban satisfechos con el rendimiento del sistema ubicado en la unidad USB. Nadie se quejó de ningún trabajo insatisfactorio de 1C. Ya era más tarde que el megaproyecto comenzó en la explotación para transferir todas las bases de datos de información a una única plataforma centralizada con super-servidores, almacenamiento por más de un millón de rublos, hipervisores sofisticados y frenos insoportables de 1C en todas las sucursales.
Pero esta es una historia completamente diferente ...
PD Ver también: