Hola Habr! Durante diez años he estado apoyando los sistemas Highload IT. 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é observaciones sobre problemas en los procesos que surgen en el soporte y operación de tales sistemas.
Monitoreo
El soporte técnico no espera hasta que llegue una aplicación con el contenido "
¿ Por qué ... el sitio vuelve a estar inactivo?". El soporte un minuto después de que el sitio se bloquee 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é pasa con la situación cuando los restos de los productos de la tienda en línea dejaron de venir del sistema ERP? ¿O ha dejado de responder el sistema CRM que calcula los descuentos para los clientes? Al mismo tiempo, el sitio está funcionando. El Zabbix condicional obtiene su respuesta 200. El turno de servicio no recibió ninguna notificación del monitoreo y felizmente inspecciona el primer episodio de la nueva temporada de Game of Thrones.
A menudo, el monitoreo se limita solo al medir el estado de la memoria, la RAM y la carga de los procesadores del servidor. Pero para los negocios, es mucho más importante obtener la disponibilidad de bienes en el sitio. Una caída condicional de una máquina virtual en el clúster hará que el tráfico deje de fluir hacia ella y la carga en otros servidores aumentará. La empresa no perderá dinero.
Por lo tanto, además de monitorear los parámetros técnicos de los sistemas operativos en los servidores, debe configurar métricas comerciales. Métricas que afectan directamente al dinero. Diversas interacciones con sistemas externos (CRM, ERP y otros). El número de pedidos para un determinado período de tiempo. Autorizaciones de clientes exitosas o no exitosas 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. Comenzando por el CRM y ERP antes mencionado y terminando con la transferencia de datos de ventas a un sistema externo de Big Data para analizar compras y ofrecer al cliente el 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 necesita analizarlo en diferentes sistemas.
Algunos sistemas dan el teléfono o telegrama a sus administradores. En algún lugar debe escribir cartas a los gerentes o ir a los rastreadores de errores de estos sistemas externos. Incluso en el contexto de una gran empresa, diferentes sistemas a menudo funcionan en diferentes sistemas de contabilidad de aplicaciones. A veces se hace imposible rastrear el estado de una aplicación. Recibe una solicitud en una Jira condicional. Luego, en los comentarios de esta primera Jira, pones un enlace a la tarea en otra Jira. En el segundo Jira en la aplicación, alguien ya escribe un comentario que
necesita llamar al administrador condicional Andrei 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. Invitación a todos los participantes en la operación de sistemas externos. Además de un solo rastreador, para no duplicar aplicaciones. Las aplicaciones deben monitorearse en un solo lugar, comenzando desde el monitoreo de alertas hasta la visualización de errores en los productos. Dirás que esto no es realista y que sucedió tan históricamente que trabajamos en un rastreador, y ellos están 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 proporcionar 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 el proyecto (o producto) tienen una persona cuya partida de vacaciones causa calambres a las autoridades? Puede ser un ingeniero, analista o desarrollador de Devops. Después de todo, solo un ingeniero de Devops sabe qué contenedores están instalados en qué servidores, cómo volver a cargar el contenedor en caso de un problema y, de hecho, 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. En qué parámetros de solicitudes a qué servicios, que recibiremos respuestas.
¿Quién comprenderá rápidamente por qué hay errores en los registros y solucionará rápidamente un error crítico en el producto? Por supuesto el mismo desarrollador. Hay otros, pero por alguna razón solo él comprende cómo se organizan los distintos 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, entonces sería posible tratar el problema sin un analista. Si devops seleccionó un par de días de su apretada agenda y describió todos los servidores, servicios e instrucciones para resolver problemas típicos, entonces un problema en su ausencia podría resolverse sin él. No es necesario en vacaciones para terminar rápidamente su cerveza en la playa y buscar wi-fi para resolver el problema.
Competencia y responsabilidad del personal de apoyo.
En proyectos grandes, las empresas no escatiman en salarios a los desarrolladores. Cazan intermediarios caros o personas mayores de proyectos similares. Con apoyo, la situación es ligeramente diferente. Están intentando de todas las formas posibles reducir estos costos. Las empresas están contratando el enikeyshikov de bajo costo de ayer y van valientemente a la batalla. Tal estrategia es posible cuando se trata de un sitio de tarjetas de visita de alguna planta en Zelenograd.
Si hablamos de una gran tienda en línea, cada hora de inactividad cuesta más que el salario mensual de un administrador-enikeik. Tome como punto de partida mil millones de rublos de facturación anual. Esta es la facturación mínima de cualquier tienda en línea de la calificación
TOP-100 para 2018 . Divida esta cantidad entre la cantidad de horas por año y obtenga más de 100,000 rublos de pérdidas netas. Y si no cuenta las horas nocturnas, puede duplicar la cantidad de manera segura.
Pero el dinero no es lo principal, ¿verdad? (no, por supuesto, lo principal) Todavía hay pérdidas de reputación. La hora de la caída de la conocida tienda en línea puede causar tanto una ola de reseñas en redes sociales como publicaciones en medios temáticos. Y las conversaciones de amigos en la cocina al estilo de "No compre nada allí, su sitio está constantemente fuera de servicio" no se prestan a la medida en absoluto.
Ahora responsable En mi práctica, hubo un caso en el que el administrador de turno no respondió a tiempo para notificar al sistema de monitoreo sobre la inaccesibilidad del sitio. En un agradable verano el viernes por la noche, el sitio de una conocida tienda en línea en Moscú yacía en silencio. El sábado por la mañana, el producto de este sitio no entendió por qué el sitio no se abrió, y hubo silencio en los chats de soporte y alertas urgentes en Slack. Tal error nos costó una suma de seis cifras, y este oficial de servicio funcionó.
La responsabilidad es una habilidad que es difícil de desarrollar. Una persona lo tiene o no. Por lo tanto, en las entrevistas, trato de identificar su presencia con varias preguntas que muestran indirectamente si una persona está acostumbrada a asumir la responsabilidad. Si una persona responde que eligió una universidad porque sus padres lo dijeron o cambia su trabajo porque su esposa dijo que no recibe mucho, entonces es mejor no involucrarse con esas personas.
Interacción con el equipo de desarrollo.
Cuando los usuarios experimentan problemas simples en el producto durante la operación, el soporte los resuelve por su cuenta. Intenta reproducir el problema, analiza los registros, etc. Pero, ¿qué hacer cuando aparece un error en el producto? En este caso, el soporte inicia la tarea para los desarrolladores, y aquí comienza la diversión.
Los desarrolladores están constantemente sobrecargados. Están creando nuevas características. Solucione errores con una lección de venta, digamos que no es lo más interesante. Los plazos para completar el próximo sprint están activados. Y luego la gente desagradable viene del apoyo y dice: "Urge dejarlo todo, 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 se ejecuta con ojos saltones y no escribe: "Urgente para llevar esta tarea a la próxima versión o revisión".
Las tareas con prioridad normal o baja van de una versión a otra. A la pregunta "¿Cuándo se completará la tarea?" Recibirá respuestas al estilo de: "Lo siento, ahora hay muchas tareas, pregunte a los líderes del equipo o al administrador de versiones".
Los problemas en el producto tienen mayor prioridad que la creación de nuevas funciones. Las malas críticas no lo harán esperar si los usuarios constantemente encuentran errores. Es difícil restaurar una reputación dañada.
DevOps resuelve los problemas de interacción entre el desarrollo y el soporte. Esta abreviatura se usa a menudo como una persona específica que ayuda a crear entornos de prueba para el desarrollo, crea canalizaciones de CI \ CD y muestra rápidamente el código probado en producción. DevOps es un enfoque para el desarrollo de software cuando 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.
El apoyo y el desarrollo en este enfoque no son departamentos diferentes con sus 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" no se ve tan a menudo en las salas de chat, y los usuarios finales se vuelven un poco más felices.