A todos nos encanta hablar de nuestros éxitos y realmente no nos gusta hablar de fracasos. Pero la experiencia de los errores suele ser más valiosa que la ganancia de un negocio completado con éxito. Por lo tanto, me gustaría hablar sobre estos casos hoy. Entonces vamos ...
¡Olla, no cocines!
Esta historia sucedió hace unos años, al comienzo de mi carrera como desarrollador de 1C.
Ha aparecido un proyecto en nuestra empresa para optimizar la operación de una base muy cargada de un cliente muy grande y respetado. El cliente estaba con un servicio de seguridad tan paranoico que no había ni acceso remoto a los servidores desde el exterior. Para conectarse a las bases directamente a nuestra oficina, se instaló una red de área local separada con VPN de hardware y se instalaron estaciones de trabajo con software estrictamente negociado. Por supuesto, sin los derechos de un administrador local.
Como cualquier otro proyecto de este tipo, comenzó con la recopilación de datos. Se asumió que primero recopilaremos varios indicadores dentro de un mes, y luego nos dedicaremos a optimizar la base de información en sí. Cómo y cuánto tiempo en este entorno burocrático tomó para establecer el CCM, este es material para una historia separada. Pero ahora, en algún momento, sucedió, el MCC se configuró y se inició. Después de eso, el experto que dirigió este proyecto (Dima, ¡hola!), Se subió a su lujoso automóvil y se fue a viajar por nuestro vasto país, y luego más a los países vecinos. Pero, de hecho, todavía sabía poco y sabía cómo, pero ya me consideraban un desarrollador bastante responsable. Por lo tanto, antes de partir, Dmitry me instruyó una tarea muy importante y seria: 2 veces al día, en el momento de la carga máxima, tenía que ir a esa computadora muy secreta y comenzar las mediciones en el CCM, y apagarlas después de una hora. Las instrucciones fueron extremadamente simples y claras:
- Mire, presiona este pequeño botón verde "reproducir", se ejecutan diferentes gráficos, espere una hora, luego presiona este botón - "detener". Eso es todo.
¿Qué podría ser más fácil, verdad? ¿En vano estudié durante 5 años en la facultad de matemáticas?
Toda la semana observé estrictamente este ritual en la mañana y en la noche. Y todo estuvo bien hasta el último día. Después del almuerzo, el viernes, como de costumbre, comencé a recopilar datos, y luego ... Bueno, ya sabes cómo sucede ... Viernes, por la noche, tenemos que terminar algunos asuntos urgentes, terminar algunas tareas, después del trabajo llevar a mi esposa a mi suegra, en el camino caer en una tienda, un segundo, etc. En general, dejé el trabajo, olvidándome por completo de este MCC desafortunado.
El sábado por la mañana comenzó con una llamada. Tenemos TODA la 1ª base en el cliente. Achtung y desastre! Nuestro experto está en algún lugar entre Dzheyrakh y Pasanauri, fuera del área de acceso a la red. El administrador principal del cliente también está en alguna casa de campo e inaccesible. Tratando de averiguar por teléfono, ¿cuál es la razón? De alguna manera resulta que el espacio en disco se ha agotado, por lo que el servicio del agente 1C se levantó. Aquí ya comencé a sospechar algo ...
Como recordarás, no hay udalenka. La computadora no solo está aislada de Internet, sino también fuera de nuestra red local. Nada que hacer, ir a trabajar. Mientras se preparaban y conducían, los administradores se dieron cuenta de que los registros de MCC ocuparon todo el lugar e hicieron lo que pensaron que era más razonable: lo cortaron a través del administrador de tareas. Adelante No puede simplemente eliminar registros del disco: perderemos los datos de medición. De alguna manera encontraron suficiente espacio en la red compartida y copiaron los archivos allí. El trabajo parece haberse reanudado.
El domingo por la mañana comenzó con una llamada. Tenemos TODA la 1ª base en el cliente. ¡Achtung y el desastre toman dos! Todo el pánico se acabó, el lugar se acabó. Pero como es eso? MCC apagado? A toda prisa, voy a volver a trabajar, tirando los troncos para liberar espacio. Y todos crecen y crecen, ¡malditos sean! Bajo el temor de las ejecuciones más perversas, los administradores me prohibieron comenzar cualquier cosa o configurar cualquier cosa. Durante el resto del domingo, estuve sentado frente a la computadora y copiando los registros a la pelota para que las bases no volvieran a levantarse.
Solo a altas horas de la noche, Dima se puso en contacto y dijo que solo necesita eliminar un pequeño archivo en el servidor 1C. Más tarde, un par de semanas después, leí sobre él en un conocido libro de "escritorio", pero ese día, exhausto, el torturado se fue a casa a dormir.
El lunes por la mañana, nuestra cuenta fue bloqueada hasta que Dmitry regresó de vacaciones, y se dijo claramente a mi cuenta: "¡Para que no lo volvamos a ver!"
Así es como terminó mi primer proyecto de optimización.
Dos veces en un embudo
Gran explotación. 18 bases de información con idéntica configuración, ubicadas en todo el país. La actualización se realiza una vez por semana y es el mismo ritual: el archivo de entrega debe prepararse con anticipación, cargarse en la nube, asegurarse de que se haya descargado en todas las sucursales (incluso en 2018, en algunas regiones, Internet es más lento que el típico 1C: ERP), compruebe que las copias de seguridad se crearon en todas partes (no parecemos ser responsables de esto, pero la amarga experiencia nos enseñó a estar seguros), luego ejecute el script de actualización manualmente en cada rama y asegúrese de que funcionó sin errores. A menudo, en el último momento, se descubre que se debe incluir una tarea más en la entrega y esta es una corrección menor, porque la próxima actualización es solo en una semana.
Entonces fue ese momento. Un desarrollador experimentado con muchos años de experiencia a toda prisa cometió un error en una línea al transferir una tarea a un circuito de combate. El error resultó ser crítico, se descubrió después de actualizar todas las bases de datos.
Bien que hacer El desarrollador corrige rápidamente el código. No deja que nadie pruebe:
- Sí, hay basura ... ¿No puedo cometer un error dos veces en una línea?
Una hora después, 18 sucursales se actualizaron por tercera vez.
Desarrollador que podría
La historia contada por un colega en Skype.
[Colega]: ¡Había una vez un "Desarrollador que podía!" Tenía un traje de desarrollo. Quería abrir una prueba, pero falló y abrió una productiva ...
[Colega]: ¿Pero esto podría detener al "Desarrollador que podría"? No!
[I]: ¿Y al actualizar, no entendió que había gente sentada allí, por así decirlo? )))
[Colega]: Además, él ve que el konf está en soporte ... ¿Pero crees que esto podría detener al "Desarrollador que podría"? No!
[Colega]: Elimina la configuración del soporte (!) Y ve su mod sin pasar por todos los repositorios ...
[I]: ¡Eso no es todo! Terminar la historia, actualización dinámica)))
[Colega]: Actualizaciones ... El sistema dice: "¡Hay 18 sesiones activas en la base de datos!". Pero, ¿cómo podría esto detener al "Desarrollador que podría"? ¡No y no otra vez!
[Colega]: Actualiza la base de datos y pasa la tarea a la prueba ...
[Colega]: El consultor no puede encontrar el atuendo ... y solo entonces, después de mucho tiempo, se da cuenta de que se lo perdió.
[Colega]: tuve que regañarlo ...
[Colega]: lo llamo ... y me río del teléfono ...
[Colega]: Simplemente no entiendo ... ¿CÓMO?
Colapso del transporte
La historia contada por un colega y registrada a partir de sus palabras.
Sucedió en una gran empresa de logística. La mayoría de los procesos comerciales se concentran en una base de información. Usuarios competitivos para 2012: alrededor de 3.000 personas de todas las regiones del país.
Establece una tarea simple. Según él, hizo su propio registro de información, en el que los datos se escriben cuando se publican ciertos documentos. Aunque no hay muchos tipos de documentos, la cantidad de estos documentos por día es enorme. En teoría, la operación de escritura que agregué al registro no debería cargar mucho el sistema. Pero hubo un matiz en la implementación de la tarea: al grabar un conjunto, la propiedad Overwrite se estableció en False. Es decir, cada documento que contiene entradas agregadas al registro. Esto era necesario de acuerdo con las condiciones del problema, pero prácticamente no afectaba el rendimiento, porque De acuerdo con las condiciones de selección, siempre había entre 1 y 10 entradas.
La prueba funcional fue exitosa. Realizamos varias docenas de documentos, nos aseguramos de que las entradas en el registro fueran correctas, no notaron nada sospechoso y las enviamos a los productivos.
Ese desafortunado viernes por la mañana, actualizamos la base de combate y los usuarios comenzaron a trabajar. 3000 personas llenaron documentos alegremente y el registro comenzó a llenarse de datos. Después de verificar que todo iba bien, unas horas después nos fuimos a casa con un alma tranquila (trabajamos en diferentes zonas horarias con los principales usuarios de la base de información).
Cabe señalar que los servidores en los que se ejecutaba el IS son casi uno de los más potentes en Rusia utilizados bajo 1C. Pero después de unas horas "algo salió mal" (c).
Los usuarios comenzaron a notar una disminución en el rendimiento del sistema. Todas las operaciones comenzaron a disminuir. Las respuestas a cualquier acción se hicieron más largas. La carga en el equipo aumentó constantemente. Mientras el departamento de TI entendía lo que estaba sucediendo, el trabajo en el sistema casi se detuvo. El equipo no podía hacer frente, las colas en los discos eran más largas que en las oficinas de correos de Rusia. Si el equipo fuera más débil, el problema se detectaría casi de inmediato. Pero los servidores más poderosos resistieron heroicamente mis manos torcidas durante medio día.
"De las palabras" de MSSQL, la solicitud más severa de repente se convirtió en una solicitud de lectura en mi registro. Aunque no hice ninguna lectura. Se descubrió rápidamente un problema en el código 1C. Olvidé establecer selecciones en un conjunto de registros. Si la propiedad "Sobrescribir" se estableciera en "Verdadero", entonces inmediatamente encontraría un error, porque cada entrada borraría todo el registro. Pero en nuestro caso esto no sucedió. En el ejemplo de una docena de documentos, por supuesto, no notamos ninguna pérdida de rendimiento. Pero cuando el registro comenzó a llenarse con decenas y cientos de miles de líneas, el sistema cada vez tuvo que verificar todo el registro para buscar registros coincidentes.
En ese momento, según algunos usuarios, ya se había producido un colapso del transporte, porque los automóviles no recibieron documentos del 1C y no pudieron abandonar los puntos de descarga.
Entonces, "solo" olvidando poner una selección en el conjunto de registros, puse una de las bases de datos 1C más grandes de Rusia.
PD Ver también: