Todos los desarrolladores de 1C de una forma u otra interactúan estrechamente con los servicios de TI y directamente con los administradores de sistemas. Pero esta interacción no siempre se desarrolla sin problemas. Me gustaría contarles algunas historias divertidas sobre esto.
Canal de comunicación de alta velocidad.
La mayoría de nuestros clientes son grandes holdings con sus propios grandes departamentos de TI. Y los especialistas del cliente suelen ser responsables de las copias de seguridad de las bases de datos de información. Pero también hay organizaciones relativamente pequeñas. Especialmente para ellos tenemos un servicio según el cual nos encargamos de todas las cuestiones relacionadas con la copia de seguridad de todo 1C. Esta es la empresa de la que hablaremos en esta historia.
Llegó un nuevo cliente para dar soporte a 1C y, entre otras cosas, el contrato incluía una cláusula de que éramos responsables de las copias de seguridad, aunque ellos tenían su propio administrador del sistema en el personal. Base de datos cliente-servidor, MS SQL como DBMS. Una situación bastante estándar, pero todavía había una salvedad: la base principal era bastante grande, pero el aumento mensual era muy pequeño. Es decir, la base de datos contenía una gran cantidad de datos históricos. Teniendo en cuenta esta característica, configuré planes de mantenimiento de copias de seguridad de la siguiente manera: el primer sábado de cada mes se hacía una copia de seguridad completa, que era bastante pesada, luego se hacía una copia diferencial cada noche, un volumen relativamente pequeño y una copia del registro de transacciones cada hora. Además, las copias completas y diferenciales no solo se copiaron a un recurso de red, sino que también se cargaron en nuestro servidor FTP. Este es un requisito obligatorio a la hora de prestar este servicio.
Todo esto se configuró, puso en funcionamiento con éxito y, en general, funcionó sin fallas.
Pero unos meses después, el administrador del sistema de esta organización cambió. El nuevo administrador del sistema comenzó a reconstruir gradualmente la infraestructura de TI de la empresa de acuerdo con las tendencias modernas. En particular, apareció la virtualización, estantes de discos, se bloqueó el acceso en todas partes y en todo, etc., lo que en el caso general, por supuesto, no puede dejar de alegrarnos. Pero las cosas no siempre le fueron bien, a menudo surgieron problemas con el funcionamiento de 1C, lo que provocó algunos desacuerdos y malentendidos con nuestro soporte. Además, cabe señalar que nuestra relación con él fue en general bastante fría y algo tirante, lo que no hacía más que aumentar el grado de tensión en caso de que surgiera 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í como respuesta algo como "Nuestro servidor falló, estamos trabajando en ello, no depende de usted". Bueno, es bueno que funcionen. Esto significa que la situación está bajo control. Después del almuerzo, vuelvo a llamar y, en lugar de irritación, ya puedo sentir fatiga y apatía en la voz del administrador. Estoy tratando de averiguar qué pasó y ¿hay algo que podamos hacer para ayudar? Como resultado de la conversación surgió lo siguiente:
Movió el servidor a un nuevo sistema de almacenamiento con un raid recién ensamblado. Pero algo salió mal y unos días después esta redada fracasó de forma segura. No recuerdo exactamente si el controlador se quemó o si les pasó algo a los discos, pero toda la información se perdió irremediablemente. Y lo principal fue que el recurso de red con copias de seguridad también terminó en la misma matriz de discos durante varias migraciones. Es decir, se perdieron tanto la propia base de datos productiva como todas sus copias de seguridad. Y no está claro qué hacer ahora.
Cálmate, digo. Tenemos su respaldo nocturno. En respuesta, hubo un silencio, por el cual me di cuenta de que acababa de salvar la vida de un hombre. Comenzamos a discutir cómo transferir esta copia a un servidor nuevo recién implementado. Pero aquí también surgió un problema.
¿Recuerdas cuando dije que la copia de seguridad completa era bastante grande? No en vano lo hacía una vez al mes los sábados. El hecho es que la empresa era una planta pequeña, que estaba ubicada lejos de la ciudad y su Internet era muy regular. El lunes por la mañana, es decir, durante el fin de semana, esta copia apenas logró subirse a nuestro servidor FTP. Pero no había forma de esperar uno o dos días para que se cargara en la dirección opuesta. Después de varios intentos fallidos de transferir el archivo, el administrador sacó el disco duro directamente del nuevo servidor, encontró un coche con conductor en algún lugar y rápidamente corrió a nuestra oficina, afortunadamente todavía estamos en la misma ciudad.
Mientras estaban en nuestra sala de servidores esperando a que se copiaran los archivos, nos reunimos por primera vez, por así decirlo, "en persona", tomamos una taza de café y hablamos en un ambiente informal. Me compadecí de su dolor y lo envié de regreso con un montón de copias de seguridad, restaurando apresuradamente el trabajo detenido de la empresa.
Posteriormente, todas nuestras solicitudes al departamento de TI se resolvieron muy rápidamente y no surgieron más desacuerdos.
Póngase en contacto con el administrador de su sistema
Una vez, durante mucho tiempo, no pude publicar 1C para acceso web a través de IIS para un cliente. Parecía una tarea normal, pero no había manera de que todo funcionara. Los administradores del sistema local se involucraron y probaron diferentes configuraciones y archivos de configuración. 1C en la web normalmente no quería funcionar de ninguna manera. Algo andaba mal, ya fuera con las políticas de seguridad del dominio, o con el sofisticado cortafuegos local, o Dios sabe qué más. En la enésima iteración, el administrador me envía un enlace con las palabras:
- Inténtalo de nuevo siguiendo estas instrucciones. Allí se describe todo con bastante detalle. Si no funciona, escribe al autor de este sitio, tal vez pueda ayudarte.
"No", digo, "no ayudará".
Por que
— Soy el autor de este sitio... (
Como resultado, lo lanzamos en Apache sin ningún problema. IIS nunca fue derrotado.
Un nivel más profundo
Teníamos un cliente: una pequeña empresa manufacturera. Tenían un servidor, una especie de “clásico” 3 en 1: servidor de terminal + servidor de aplicaciones + servidor de bases de datos. Trabajaron en alguna configuración específica de la industria basada en UPP, había entre 15 y 20 usuarios y el rendimiento del sistema, en principio, se adaptaba a todos.
Con el paso del tiempo, todo funcionó de forma más o menos estable. Pero luego Europa impuso sanciones contra Rusia, como resultado de lo cual los rusos comenzaron a comprar principalmente productos de producción nacional, y el negocio de esta empresa se fue cuesta arriba. El número de usuarios aumentó a 50-60 personas, se abrió una nueva sucursal y el flujo de documentos aumentó en consecuencia. Y ahora el servidor actual ya no podía hacer frente a un fuerte aumento de carga, y 1C comenzó, como dicen, a "desacelerarse". Durante las horas pico, los documentos se procesaban durante varios minutos, se producían errores de bloqueo, los formularios tardaban mucho en abrirse y todo el resto de servicios relacionados. El administrador del sistema local hizo caso omiso de todos los problemas y dijo: "Este es su 1C, lo resolverá". En repetidas ocasiones hemos propuesto realizar una auditoría de desempeño del sistema, pero nunca llegamos a la auditoría en sí. El cliente simplemente pidió recomendaciones sobre cómo solucionar los problemas.
Bueno, me senté y escribí una carta bastante larga sobre la necesidad de separar las funciones del servidor terminal y del servidor de aplicaciones con el DBMS (que, en principio, ya hemos dicho muchas veces antes). Escribí sobre DFSS en servidores de terminal, sobre memoria compartida, proporcioné enlaces a fuentes autorizadas e incluso sugerí algunas opciones de equipo. Esta carta llegó a los que estaban en el poder de la empresa, volvió al departamento de TI con las resoluciones "Implementar" y, en general, se rompió el hielo.
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. Dice que allí se implementan los componentes del servidor MS SQL y 1C, y las bases de datos deben transferirse, pero por ahora solo al servidor DBMS, ya que han surgido algunos problemas con las claves 1C.
Entré, efectivamente, todos los servicios estaban funcionando, el servidor no era muy potente, pero bueno, creo que es mejor que nada. Transferiré las bases de datos por ahora para aliviar de alguna manera el servidor actual. Completé todas las transferencias en el momento acordado, pero la situación no cambió; siguen los mismos problemas de rendimiento. Es extraño, por supuesto, bueno, registremos las bases de datos en el clúster 1C y ya veremos.
Pasan varios días, las llaves no han sido transferidas. Me pregunto cuál es el problema, todo parece simple: sáquelo de un servidor, conéctelo a otro, instale el controlador y listo. El administrador responde quejándose y diciendo algo sobre reenvío de puertos, un servidor virtual, etc.
Mmmm... ¿Servidor virtual? Parece que nunca ha habido virtualización y nunca ha habido... Recuerdo un problema bastante conocido con la imposibilidad de reenviar una clave de servidor 1C a una máquina virtual en Hyper-V en Windows Server 2008. Y aquí algunas sospechas comienzan a formarse en mí...
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 conecto... Y efectivamente... Nuestro nuevo servidor de base de datos...
¿Así que lo que? Se han cumplido las instrucciones de las autoridades y mis recomendaciones, se han separado los roles. La tarea se puede cerrar.
Después de un tiempo, llegó la crisis actual, hubo que cerrar la nueva sucursal, la carga disminuyó y 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 está: servidor de terminal + clúster 1C en una máquina física, servidor de base de datos allí en una virtual.
Y sería bueno si esto fuera una especie de oficina de Sharashkin. Entonces no. Una empresa muy conocida cuyos productos probablemente conozca y haya visto en los departamentos correspondientes de todas las Lentas y Auchans.
Calendario de vacaciones del disco duro
Un gran holding con ambiciosos planes de conquistar el mundo ha vuelto a comprar una pequeña empresa con el objetivo de incluirla en su megacorporación. En todas las divisiones de este holding, los usuarios trabajan en sus propias bases de datos, pero con una configuración idéntica. Y entonces iniciamos un pequeño proyecto para incluir una nueva unidad en este sistema.
En primer lugar, es necesario implementar bases de datos de producción y prueba. El desarrollador recibió los datos de conexión, inicia sesión en el servidor, ve MS SQL instalado, servidor 1C, ve 2 unidades lógicas: la unidad "C" con una capacidad de 250 gigabytes y la unidad "D" con una capacidad de 1 terabyte. Bueno, "C" es el sistema, "D" es para los datos, el desarrollador lógicamente decide e implementa todas las bases de datos allí. Incluso establezco planes de mantenimiento, incluyendo copias de seguridad, por si acaso (aunque no somos responsables de esto). Es cierto que aquí se agregaron copias de seguridad en "D". En el futuro, se planeó reconfigurarlo en algún recurso de red separado.
El proyecto comenzó, los consultores brindaron capacitación sobre cómo trabajar en el nuevo sistema, se transfirieron los restos, se realizaron algunas mejoras menores y los usuarios comenzaron a trabajar en la nueva base de información.
Todo iba bien hasta que un lunes por la mañana se descubrió que faltaba el disco de la base de datos. Simplemente no hay una “D” en el servidor y eso es todo.
Una investigación más profunda reveló esto: este "servidor" era en realidad la computadora de trabajo de un administrador del sistema local. Es cierto que todavía tenía un sistema operativo de servidor. La unidad USB personal de este administrador estaba conectada al servidor. Y así el administrador se fue de vacaciones, llevándose su tornillo con el objetivo de meterle películas durante el viaje.
Gracias a Dios, no logró eliminar los archivos de la base de datos y logró restaurar la base de datos productiva.
Cabe destacar que, en general, todos quedaron satisfechos con el rendimiento del sistema ubicado en una unidad USB. Nadie se quejó del desempeño insatisfactorio de 1C. Sólo más tarde el holding inició un megaproyecto para transferir todas las bases de datos de información a un único sitio centralizado con superservidores, sistemas de almacenamiento por más de un millón de rublos, hipervisores sofisticados y frenos 1C insoportables en todas las sucursales.
Pero esa es una historia completamente diferente ...
Fuente: habr.com