¡Hola Habr! Llevo diez años dando soporte a los sistemas informáticos de Highload. No escribiré en este artículo sobre los problemas de configurar nginx para que funcione en modo 1000+ RPS u otras cosas técnicas. Compartiré mis observaciones sobre los problemas en los procesos que surgen en el soporte y operación de dichos sistemas.
Monitoreo
El soporte técnico no espera hasta que llegue una solicitud con el contenido "¿Qué por qué... el sitio no funciona nuevamente?" Un minuto después de que el sitio falle, el soporte ya debería ver el problema y comenzar a resolverlo. Pero el sitio es la punta del iceberg.. Su disponibilidad es una de las primeras en ser monitoreadas.
¿Qué hacer con la situación en la que los productos restantes de una tienda online ya no llegan desde el sistema ERP? ¿O el sistema CRM que calcula los descuentos para los clientes ha dejado de responder? El sitio parece estar funcionando. Zabbix condicional recibe su respuesta 200. El turno de guardia no ha recibido ninguna notificación del seguimiento y se encuentra feliz viendo el primer episodio de la nueva temporada de Juego de Tronos.
La monitorización a menudo se limita a medir únicamente el estado de la memoria, la RAM y la carga del procesador del servidor. Pero para las empresas es mucho más importante obtener la disponibilidad del producto en el sitio web. La falla condicional de una máquina virtual en el clúster provocará que el tráfico dejará de llegar a ella y aumentará la carga en otros servidores. La empresa no perderá dinero.
Por lo tanto, además de monitorear los parámetros técnicos de los sistemas operativos en los servidores, es necesario configurar métricas comerciales. Métricas que afectan directamente al dinero. Interacciones diversas con sistemas externos (CRM, ERP y otros). El número de pedidos durante un período de tiempo determinado. Autorizaciones de clientes exitosas o no y otras métricas.
Interacción con sistemas externos.
Cualquier sitio web o aplicación móvil con una facturación anual de más de mil millones de rublos interactúa con sistemas externos. Empezando por los CRM y ERP antes mencionados y terminando con la transferencia de los datos de ventas a un sistema Big Data externo para analizar las compras y ofrecer al cliente un producto que definitivamente comprará (de hecho, 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 es necesario analizarlo en diferentes sistemas.
Algunos sistemas proporcionan un número de teléfono o un telegrama a sus administradores. En algún lugar deberá escribir cartas a los gerentes o acudir a los rastreadores de errores de estos sistemas externos. Incluso dentro del contexto de una gran empresa, a menudo operan diferentes sistemas en diferentes sistemas de contabilidad de aplicaciones. A veces resulta imposible rastrear el estado de una solicitud. Recibes una solicitud en un Jira condicional. Luego en el comentario de este primer Jira pones un enlace al tema en otro Jira. En el segundo Jira de la aplicación, alguien ya está escribiendo un comentario que debes llamar al administrador condicional Andrey para resolver el problema. Y así sucesivamente.
La mejor solución a este problema sería crear un espacio único para la comunicación, por ejemplo en Slack. Invitando a unirse a todos los participantes en el proceso de operación de sistemas externos. Y además un único rastreador para no duplicar aplicaciones. Las aplicaciones deben rastrearse en un solo lugar, desde el monitoreo de notificaciones hasta la salida de soluciones de errores en el futuro. Dirás que esto no es realista e históricamente ha sucedido que nosotros trabajamos en un rastreador y ellos trabajan en otro. Aparecieron diferentes sistemas, tenían sus propios equipos de TI autónomos. Estoy de acuerdo y, por lo tanto, el problema debe resolverse desde arriba, a nivel de CIO o propietario del producto.
Cada sistema con el que interactúa debe brindar soporte como servicio con un SLA claro para resolver los problemas por prioridad. Y no cuando el administrador condicional Andrey tiene un minuto para ti.
Hombre cuello de botella
¿Todos en un proyecto (o producto) tienen una persona cuya salida de vacaciones provoca convulsiones entre sus superiores? Podría ser un ingeniero, analista o desarrollador de Devops. Después de todo, solo un ingeniero de Devops sabe qué servidores tienen qué contenedores instalados, cómo reiniciar el contenedor en caso de un problema y, en general, cualquier problema complejo no se puede resolver 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, a qué servicios, a cuáles recibiremos respuesta.
¿Quién entenderá rápidamente por qué hay errores en los registros y corregirá rápidamente un error crítico en el producto? Por supuesto, el mismo desarrollador. Hay otros, pero por alguna razón sólo él entiende cómo funcionan los diferentes módulos del sistema.
La raíz de este problema es la falta de documentación.. Después de todo, si se describieran todos los servicios de su sistema, sería posible solucionar el problema sin un analista. Si Devops se tomara un par de días de su apretada agenda y describiera todos los servidores, servicios e instrucciones para resolver problemas típicos, entonces el problema en su ausencia podría resolverse sin él. No necesitas terminar rápidamente tu cerveza en la playa mientras estás de vacaciones y buscar wifi para resolver el problema.
Competencia y responsabilidad del personal de apoyo.
En los grandes proyectos, las empresas no escatiman en salarios de los desarrolladores. Buscan personas medias o superiores caras de proyectos similares. Con apoyo la situación es un poco diferente. Están intentando reducir estos costes de todas las formas posibles. Las empresas contratan a los trabajadores baratos de Enikey de ayer y se lanzan audazmente a la batalla. Esta estrategia es posible si hablamos del sitio web de la tarjeta de presentación de una planta en Zelenograd.
Si hablamos de una gran tienda online, entonces cada hora de inactividad cuesta más que el salario mensual de un administrador de Enikey. Tomemos como punto de partida mil millones de rublos de facturación anual. Esta es la facturación mínima de cualquier tienda online según la calificación. . Divida esta cantidad por el número de horas al año y obtenga más de 100 rublos de pérdidas netas. Y si no cuentas las horas nocturnas, puedes duplicar la cantidad con seguridad.
Pero el dinero no es lo principal, ¿verdad? (no, por supuesto lo principal) También hay pérdidas de reputación. La caída de una conocida tienda online puede provocar tanto una ola de reseñas en las redes sociales como publicaciones en medios temáticos. Y las conversaciones de amigos en la cocina al estilo de “No compres nada allí, su web siempre está caída” no se pueden medir en absoluto.
Ahora a la responsabilidad. En mi práctica, hubo un caso en el que el administrador de turno no respondió a tiempo a una notificación del sistema de seguimiento sobre la indisponibilidad del sitio. Una agradable tarde de viernes de verano descansaba en silencio la página web de una conocida tienda online de Moscú. El sábado por la mañana, el gerente de producto de este sitio no entendía por qué el sitio no se abría y se hizo el silencio en los chats de soporte y notificación urgente en Slack. Semejante error nos costó una suma de seis cifras y a este oficial de servicio su puesto.
La responsabilidad es una habilidad difícil de desarrollar. O una persona lo tiene o no. Por eso, durante las entrevistas trato de identificar su presencia con diversas preguntas que muestran indirectamente si una persona está acostumbrada a asumir responsabilidades. Si una persona responde que eligió la universidad porque así lo dijeron sus padres o cambia de trabajo porque su esposa dijo que no gana lo suficiente, entonces es mejor no involucrarse con esas personas.
Interacción con el equipo de desarrollo.
Cuando los usuarios encuentran problemas simples con un producto durante su funcionamiento, el soporte los resuelve por sí solo. Intenta reproducir el problema, analiza los registros, etc. ¿Pero qué hacer cuando aparece un error en el producto? En este caso, el soporte asigna la tarea a los desarrolladores y aquí es donde comienza la diversión.
Los desarrolladores están constantemente sobrecargados. Están creando nuevas funciones. Corregir errores con las ventas no es la actividad más interesante. Se acercan los plazos para completar el siguiente sprint. Y luego viene gente desagradable del servicio de asistencia y dice: "Deja todo inmediatamente, tenemos problemas". La prioridad de tales tareas es mínima. Especialmente cuando el problema no es el más crítico y la funcionalidad principal del sitio funciona, y cuando el administrador de versiones no corre con los ojos saltones y escribe: "Agregue urgentemente esta tarea a la próxima versión o revisión".
Los problemas con prioridad normal o baja se trasladan de una versión a otra. A la pregunta "¿Cuándo se completará la tarea?" Recibirá respuestas del estilo: "Lo siento, hay muchas tareas en este momento, pregúntele a los líderes de su equipo o al gerente de versiones".
Los problemas de productividad tienen mayor prioridad que la creación de nuevas funciones. Las malas críticas no tardarán en llegar si los usuarios tropiezan constantemente con errores. Una reputación dañada es difícil de restaurar.
DevOps resuelve los problemas de interacción entre desarrollo y soporte. Esta abreviatura se utiliza a menudo en forma de una persona específica que ayuda a crear entornos de prueba para el desarrollo, crea canalizaciones CICD y rápidamente pone en producción el código probado. DevOps es un enfoque para el desarrollo de software en el que todos los participantes en el proceso interactúan estrechamente entre sí y ayudan a crear y actualizar rápidamente productos y servicios de software. Me refiero a analistas, desarrolladores, probadores y soporte.
En este enfoque, el soporte y el desarrollo no son departamentos diferentes con sus propias metas y objetivos. 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 quedan un poco más felices.
Fuente: habr.com