¡Hola, Habr! Durante diez años he estado manteniendo sistemas de TI de alto carga. No escribiré en este artículo sobre los problemas de configuración de nginx para funcionar en modo 1000+ RPS ni otras cosas técnicas. Compartiré mis observaciones sobre los problemas en los procesos que surgen en el soporte y operación de tales sistemas.
Monitoreo
El soporte técnico no espera a que llegue una solicitud con el contenido «¿Por qué… el sitio no funciona otra vez?». El soporte, un minuto después de que caiga el sitio, ya debe ver el problema y comenzar a resolverlo. Pero el sitio es la cima del iceberg.Su disponibilidad se monitoriza como una de las primeras cosas.
¿Qué hacer en la situación en la que los inventarios de una tienda en línea han dejado de llegar del sistema ERP? ¿O cuando el sistema CRM, que calcula los descuentos para los clientes, ha dejado de responder? El sitio, sin embargo, parece estar funcionando. El hipotético Zabbix recibe su respuesta 200. El turno de guardia no recibió ninguna notificación del monitoreo y alegremente está viendo el primer episodio de la nueva temporada de «Juego de Tronos».
A menudo, el monitoreo se limita únicamente a medir el estado de la memoria, RAM y carga de los procesadores. servidores. Pero para el negocio es mucho más importante obtener la disponibilidad del producto en el sitio. La caída hipotética de una máquina virtual en el clúster hará que el tráfico deje de ir hacia ella y aumentará la carga en otros servidores. La empresa no perderá dinero.
Por lo tanto, además del monitoreo de los parámetros técnicos del sistema operativo en los servidores, es necesario configurar métricas comerciales. Métricas que afectan directamente al dinero. Diversas interacciones con sistemas externos (CRM, ERP y otros). La cantidad de pedidos en un determinado período de tiempo. Autorizaciones exitosas o fallidas de clientes y otras métricas.
Interacción con sistemas externos.
Cualquier sitio o aplicación móvil con un volumen anual de más de mil millones de rublos interactúa con sistemas externos. Desde los mencionados CRM y ERP hasta la transmisión de datos sobre ventas a un sistema de análisis Big Data externo que presenta al cliente un producto que definitivamente comprará (en realidad, no). Cada uno de estos sistemas tiene su propio soporte. Y a menudo, la comunicación con estos sistemas causa dolor. Especialmente cuando el problema es global y se necesita analizarlo en diferentes sistemas.
Algunos sistemas proporcionan el teléfono o telegram de sus administradores. En otros lugares, es necesario enviar correos electrónicos a los gerentes o acudir a los rastreadores de errores de estos sistemas externos. Incluso dentro de una gran empresa, a menudo diferentes sistemas operan en diferentes sistemas de seguimiento de solicitudes. A veces, rastrear el estado de una solicitud se vuelve imposible. Recibes una solicitud en una Jira. Luego, en el comentario de esa primera Jira, colocas un enlace a la tarea en otra Jira. En la segunda Jira, alguien ya ha escrito un comentario que es necesario llamar al administrador condicional, Andrei, para resolver el asunto. Y así sucesivamente.
Una solución óptima a este problema sería crear un espacio único para la comunicación, como en Slack. Invitar a todos los participantes del proceso de explotación de sistemas externos. Y también un rastreador único, para no duplicar las solicitudes. Las solicitudes deben rastrearse en un solo lugar, desde la notificación de monitoreo hasta la implementación de la solución de errores en producción. Podrán decir que esto es irreal y que históricamente han trabajado en un rastreador, mientras que ellos lo hacen en otro. Han surgido diferentes sistemas, cada uno con sus propios equipos de TI autónomos. Estoy de acuerdo, y por eso el problema debe resolverse desde arriba, a nivel de CIO o propietario del producto.
Cada sistema con el que interactúan debe brindar soporte como un servicio con un SLA claro para la resolución de problemas según prioridades. No cuando el administrador condicional, Andrei, tenga un momento para ustedes.
La persona - cuello de botella
¿Hay alguien en el proyecto (o producto) cuya ausencia por vacaciones provoca convulsiones en la gerencia? Puede ser un ingeniero de devops, un analista o un desarrollador. Después de todo, solo el ingeniero de devops sabe en qué servidores están instalados qué contenedores, cómo reiniciar un contenedor en caso de problema, y en general, cualquier problema complejo no se resuelve sin él. El analista es el único que sabe cómo funciona su complejo mecanismo. Qué flujos de datos van a dónde. Bajo qué parámetros de solicitudes en qué servicios, qué respuestas recibiremos.
¿Quién podrá entender rápidamente por qué hay errores en los registros y arreglará rápidamente un error crítico en producción? Por supuesto, ese mismo desarrollador. Hay otros, pero curiosamente, solo él entiende cómo están estructurados los diferentes módulos del sistema.
La raíz de este problema es la falta de documentación.. Porque si todos los servicios de su sistema estuvieran documentados, se podría abordar el problema sin la necesidad de un analista. Si el devops dedicara un par de días de su apretada agenda a documentar todos los servidores, servicios e instrucciones para resolver problemas típicos, se podría solucionar el problema en su ausencia. No es necesario apresurarse a acabar la cerveza en la playa durante las vacaciones y buscar wi-fi para resolver problemas.
Competencia y responsabilidad del personal de soporte
En grandes proyectos, las empresas no escatiman en el salario de los desarrolladores. Buscan a costosos mid-level o seniors de proyectos similares. La situación con el soporte es un poco diferente. Estos gastos se intentan reducir de diversas maneras. Las empresas contratan a inexpertos y se lanzan a la batalla sin dudar. Esta estrategia es viable si se trata de un sitio web de presentación de alguna fábrica en Zelenograd.
Si estamos hablando de una gran tienda en línea, cada hora de inactividad cuesta más que el salario mensual de un administrador inexperto. Tomemos como punto de partida un giro anual de 1 mil millones de rublos. Este es el giro mínimo de cualquier tienda en línea en el ranking . Dividimos esta cantidad entre el número de horas en un año y obtenemos más de 100,000 rublos en pérdidas netas. Y si no consideramos las horas nocturnas, podemos doblar fácilmente esa suma.
Pero el dinero no es lo principal, ¿verdad? (No, por supuesto que lo principal) También hay pérdidas de reputación. Una hora de caída de una conocida tienda en línea puede generar tanto una avalancha de comentarios en redes sociales como publicaciones en medios especializados. Y las charlas de amigos en la cocina del estilo 'No compres nada allí, su sitio web siempre está caído' son completamente incalculables.
Ahora, sobre la responsabilidad. En mi experiencia, hubo un caso en el que el administrador de guardia no reaccionó a tiempo a la alerta del sistema de monitoreo sobre la inaccesibilidad del sitio. En una agradable noche de viernes de verano, el sitio de una conocida tienda en línea de Moscú estaba caído. En la mañana del sábado, el product manager de ese sitio no entendió por qué no se abría, y en los chats de soporte y alertas urgentes en Slack, había silencio. Tal error nos costó una suma de seis cifras, y costó el trabajo a ese administrador de guardia.
La responsabilidad es una habilidad difícil de desarrollar. O tienes en una persona o no. Por eso, en las entrevistas trato de descubrir su presencia a través de diversas preguntas que indirectamente muestran si la persona está acostumbrada a asumir responsabilidades. Si la persona responde que eligió la universidad porque se lo dijeron sus padres o que cambia de trabajo porque su esposa dice que gana poco, entonces es mejor no involucrarse con personas así.
Interacción con el equipo de desarrollo
Cuando surgen problemas sencillos en la producción durante la operación de los usuarios, el soporte los resuelve por su cuenta. Intenta reproducir el problema, analiza los registros, etc. Pero, ¿qué hacer cuando aparece un error en producción? En este caso, el soporte crea una tarea para los desarrolladores y aquí es donde comienza lo interesante.
Los desarrolladores están constantemente sobrecargados. Se dedican a crear nuevas características. Corregir errores en producción no es, digamos, la tarea más interesante. Hay plazos que cumplir para finalizar el próximo sprint. Y aquí llegan personas desagradables del soporte y dicen: "Dejadlo todo, tenemos problemas". La prioridad de esas tareas es mínima, especialmente cuando el problema no es crítico y la funcionalidad principal del sitio sigue funcionando, y cuando el gestor de lanzamientos no corre con los ojos desorbitados diciendo: "Hay que incluir esta tarea en el próximo lanzamiento o hotfix".
Las tareas con prioridad normal o baja se trasladan de lanzamiento a lanzamiento. A la pregunta "¿Cuándo se completará la tarea?" recibirás respuestas del estilo: "Lo siento, ahora hay muchas tareas, pregunta a los líderes de equipo o al gestor de lanzamientos".
Los problemas en producción tienen mayor prioridad que la creación de nuevas características. Las malas reseñas no tardarán en llegar si los usuarios siguen encontrando errores. Es difícil recuperar una reputación dañada.
Las cuestiones de interacción entre desarrollo y soporte las resuelve DevOps. Esta abreviatura se utiliza a menudo en referencia a una persona concreta que ayuda a crear entornos de prueba para desarrollo, establece tuberías CICD y lleva rápidamente el código probado a producción. DevOps es un enfoque para el desarrollo de software donde todos los participantes del proceso interactúan estrechamente entre sí y ayudan a crear y actualizar más rápidamente productos y servicios de software. Me refiero a analistas, desarrolladores, testers y soporte.
El soporte y desarrollo en este enfoque no son departamentos diferentes con sus propios objetivos y tareas. El desarrollo está involucrado en la operación y viceversa. La famosa frase de los equipos distribuidos: "El problema no está de mi lado" ya no aparece tan a menudo en los chats, y los usuarios finales se están volviendo un poco más felices.
Fuente: habr.com
