Ahora el tema de DevOps está de moda. Canal de integración y entrega continua todos lo están implementando. Pero la mayoría no siempre presta la debida atención a garantizar la confiabilidad de los sistemas de información en las distintas etapas del proceso de CI/CD. En este artículo me gustaría hablar sobre mi experiencia en la automatización de controles de calidad de software y la implementación de posibles escenarios para su "autocuración".
Trabajo como ingeniero en el departamento de gestión de servicios TI de una empresa. . Mi área principal de especialización es la implementación de diversos sistemas de monitoreo de disponibilidad y rendimiento de aplicaciones. A menudo me comunico con clientes de TI de diferentes segmentos del mercado sobre temas actuales relacionados con el monitoreo de la calidad de sus servicios de TI. El objetivo principal es minimizar el tiempo del ciclo de lanzamiento y aumentar la frecuencia de los lanzamientos. Esto, por supuesto, está bien: más lanzamientos, más funciones nuevas, más usuarios satisfechos, más ganancias. Pero en realidad las cosas no siempre salen bien. Con tasas de implementación muy altas, inmediatamente surge la pregunta sobre la calidad de nuestras versiones. Incluso con una canalización totalmente automatizada, uno de los mayores desafíos es trasladar los servicios de prueba a producción sin afectar el tiempo de actividad de la aplicación y la experiencia del usuario.
Con base en los resultados de numerosas conversaciones con clientes, puedo decir que el control de calidad de la versión, el problema de la confiabilidad de la aplicación y la posibilidad de su "autocuración" (por ejemplo, volver a una versión estable) en varias etapas de la CI /CD pipeline se encuentran entre los temas más interesantes y relevantes.
Recientemente, yo mismo trabajé del lado del cliente, en el servicio de soporte de software de aplicaciones de banca en línea. La arquitectura de nuestra aplicación utilizó una gran cantidad de microservicios escritos por nosotros mismos. Lo más triste es que no todos los desarrolladores pudieron hacer frente al alto ritmo de desarrollo, la calidad de algunos microservicios se vio afectada, lo que dio lugar a apodos divertidos para ellos y sus creadores. Hubo historias sobre de qué materiales estaban hechos estos productos.
"Formulación del problema"
La alta frecuencia de lanzamientos y la gran cantidad de microservicios dificultan la comprensión del funcionamiento de la aplicación en su conjunto, tanto en la etapa de prueba como en la etapa operativa. Los cambios ocurren constantemente y es muy difícil controlarlos sin buenas herramientas de seguimiento. A menudo, después del lanzamiento nocturno por la mañana, los desarrolladores se sientan como en un barril de pólvora y esperan que nada se rompa, aunque todas las comprobaciones fueron exitosas en la etapa de prueba.
Hay un punto más. En la etapa de prueba se comprueba la funcionalidad del software: la implementación de las funciones principales de la aplicación y la ausencia de errores. Faltan evaluaciones cualitativas del desempeño o no tienen en cuenta todos los aspectos de la aplicación y la capa de integración. Es posible que algunas métricas no se verifiquen en absoluto. Como resultado, cuando se produce una avería en un entorno de producción, el departamento de soporte técnico sólo se entera cuando los usuarios reales empiezan a quejarse. Me gustaría minimizar el impacto del software de baja calidad en los usuarios finales.
Una de las soluciones es implementar procesos para verificar la calidad del software en varias etapas del proceso de CI/CD y agregar varios escenarios para restaurar el sistema en caso de una emergencia. También recordamos que contamos con DevOps. Las empresas esperan recibir un nuevo producto lo más rápido posible. Por lo tanto, todas nuestras comprobaciones y scripts deben estar automatizados.
La tarea se divide en dos componentes:
- control de calidad de los conjuntos en la etapa de prueba (para automatizar el proceso de detección de conjuntos de baja calidad);
- control de calidad del software en el entorno de producción (mecanismos de detección automática de problemas y posibles escenarios para su autocuración).
Herramienta de seguimiento y recopilación de métricas
Para lograr los objetivos establecidos, se requiere un sistema de monitoreo que pueda detectar problemas y transferirlos a sistemas de automatización en varias etapas del proceso de CI/CD. También será positivo que este sistema proporcione métricas útiles para varios equipos: desarrollo, pruebas, operación. Y es absolutamente maravilloso si también es para negocios.
Para recopilar métricas, puede utilizar un conjunto de sistemas diferentes (Prometheus, ELK Stack, Zabbix, etc.), pero, en mi opinión, las soluciones de clase APM son las más adecuadas para estas tareas (), lo que puede simplificar enormemente su vida.
Como parte de mi trabajo en el servicio de soporte, comencé a hacer un proyecto similar usando una solución clase APM de Dynatrace. Ahora, trabajando para un integrador, conozco bastante bien el mercado de los sistemas de monitorización. Mi opinión subjetiva: Dynatrace es el más adecuado para resolver este tipo de problemas.
Dynatrace proporciona una vista horizontal de cada operación del usuario a nivel granular hasta el nivel de ejecución del código. Puede rastrear toda la cadena de interacción entre varios servicios de información: desde los niveles front-end de las aplicaciones web y móviles, los servidores de aplicaciones back-end, el bus de integración hasta una llamada específica a la base de datos.
. Construcción automática de todas las dependencias entre los componentes del sistema.
. Detección automática y construcción de la ruta de operación del servicio.
También recordamos que necesitamos integrarnos con varias herramientas de automatización. Aquí la solución tiene una API conveniente que le permite enviar y recibir diversas métricas y eventos.
A continuación, pasemos a un vistazo más detallado a cómo resolver estos problemas utilizando el sistema Dynatrace.
Tarea 1. Automatización del control de calidad de conjuntos en la etapa de prueba.
El primer desafío es encontrar problemas lo antes posible en el proceso de entrega de aplicaciones. Sólo las compilaciones de código "buenas" deberían llegar a producción. Para hacer esto, su canal en la etapa de prueba debe incluir monitores adicionales para verificar la calidad de sus servicios.
Veamos paso a paso cómo implementar esto y automatizar este proceso:
La figura muestra el flujo de pasos de prueba de calidad de software automatizados:
- despliegue de un sistema de seguimiento (instalación de agentes);
- identificar eventos para evaluar la calidad de su software (métricas y valores umbral) y transferirlos al sistema de monitoreo;
- generación de pruebas de carga y rendimiento;
- recopilar datos de rendimiento y disponibilidad en el sistema de seguimiento;
- transferencia de datos de prueba basados en eventos de evaluación de la calidad del software desde el sistema de monitoreo al sistema CI/CD. Análisis automático de montajes.
Paso 1. Despliegue del sistema de seguimiento
Primero necesita instalar los agentes en su entorno de prueba. Al mismo tiempo, la solución Dynatrace tiene una característica interesante: utiliza el agente universal OneAgent, que se instala en una instancia del sistema operativo (Windows, Linux, AIX), detecta automáticamente sus servicios y comienza a recopilar datos de seguimiento sobre ellos. No es necesario configurar un agente independiente para cada proceso. La situación será similar para las plataformas de nube y de contenedores. Al mismo tiempo, también puedes automatizar el proceso de instalación del agente. Dynatrace encaja perfectamente en el concepto de "infraestructura como código" (): Hay scripts e instrucciones ya preparados para todas las plataformas populares. Usted integra el agente en la configuración de su servicio y, cuando lo implementa, recibe inmediatamente un nuevo servicio con un agente que ya está en funcionamiento.
Paso 2: Defina los eventos de calidad de su software
Ahora debe decidir la lista de servicios y operaciones comerciales. Es importante tener en cuenta exactamente aquellas operaciones de usuario que son críticas para el negocio de su servicio. Aquí recomiendo consultar con analistas de negocios y de sistemas.
A continuación, debe determinar qué métricas desea incluir en la revisión para cada nivel. Por ejemplo, esto podría ser el tiempo de ejecución (dividido en promedio, mediana, percentiles, etc.), errores (lógicos, de servicio, de infraestructura, etc.) y varias métricas de infraestructura (montón de memoria, recolector de basura, recuento de subprocesos, etc.).
Para la automatización y facilidad de uso por parte del equipo de DevOps, aparece el concepto de “Monitoreo como código”. Lo que quiero decir con esto es que un desarrollador/probador puede escribir un archivo JSON simple que defina las métricas de control de calidad del software.
Veamos un ejemplo de un archivo JSON de este tipo. Los objetos de la API de Dynatrace se utilizan como pares clave/valor (la descripción de la API se puede encontrar aquí ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}El archivo es una serie de definiciones de series temporales:
- timeseriesId: la métrica que se está verificando, por ejemplo, tiempo de respuesta, recuento de errores, memoria utilizada, etc.;
- agregación: nivel de agregación de métricas, en nuestro caso promedio, pero puede usar cualquiera que necesite (promedio, mínimo, máximo, suma, recuento, percentil);
- etiquetas: etiqueta de objeto en el sistema de monitoreo, o puede especificar un identificador de objeto específico;
- Severo y Advertencia: estos indicadores regulan los valores umbral de nuestras métricas; si el valor de la prueba excede el umbral severo, entonces nuestra compilación se marca como no exitosa.
La siguiente figura muestra un ejemplo del uso de dichos umbrales.
Paso 3: Generación de carga
Una vez que hayamos determinado los niveles de calidad de nuestro servicio, necesitamos generar una carga de prueba. Puede utilizar cualquiera de las herramientas de prueba con las que se sienta cómodo, como Jmeter, Selenium, Neotys, Gatling, etc.
El sistema de monitoreo de Dynatrace le permite capturar varios metadatos de sus pruebas y reconocer qué pruebas pertenecen a qué ciclo de lanzamiento y qué servicio. Se recomienda agregar encabezados adicionales a las solicitudes de prueba HTTP.
La siguiente figura muestra un ejemplo donde, utilizando el encabezado adicional X-Dynatrace-Test, indicamos que esta prueba se relaciona con probar la operación de agregar un artículo al carrito.
Cuando ejecuta cada prueba de carga, envía información contextual adicional a Dynatrace utilizando la API de eventos desde el servidor CI/CD. De esta forma, el sistema puede diferenciar entre diferentes pruebas.
. Evento en el sistema de monitoreo sobre el inicio de las pruebas de carga.
Paso 4-5. Recopile datos de rendimiento y transfiera datos al sistema CI/CD
Junto con la prueba generada, se transmite al sistema de monitoreo un evento sobre la necesidad de recopilar datos para verificar los indicadores de calidad del servicio. También especifica nuestro archivo JSON, que define las métricas clave.
Evento sobre la necesidad de verificar la calidad del software generado en el servidor CI/CD para su envío al sistema de monitoreo
En nuestro ejemplo, el evento de control de calidad se llama informe perfSigDynatrace (Rendimiento_Firma) - esto está listo para la integración con Jenkins, que fue desarrollado por los chicos de T-Systems Multimedia Solutions. Cada evento de lanzamiento de prueba contiene información sobre el servicio, el número de compilación y el tiempo de prueba. El complemento recopila valores de rendimiento en el momento de la compilación, los evalúa y compara el resultado con compilaciones anteriores y requisitos no funcionales.
Evento en el sistema de seguimiento sobre el inicio de un control de calidad de construcción.
Una vez completada la prueba, todas las métricas para evaluar la calidad del software se transfieren nuevamente a un sistema de integración continua, por ejemplo, Jenkins, que genera un informe sobre los resultados.
El resultado de las estadísticas sobre ensamblajes en el servidor CI/CD.
Para cada compilación individual, vemos estadísticas para cada métrica que configuramos durante toda la prueba. También vemos si hubo violaciones en ciertos valores de umbral (advertencia y umbrales severos). Según las métricas agregadas, toda la compilación se marca como estable, inestable o fallida. Además, para mayor comodidad, puede agregar indicadores al informe que comparen la compilación actual con la anterior.
Vea estadísticas detalladas sobre ensamblajes en el servidor CI/CD.
Comparación detallada de dos ensamblajes.
Si es necesario, puedes ir a la interfaz de Dynatrace y allí podrás ver las estadísticas de cada una de tus compilaciones con más detalle y compararlas entre sí.
Comparación de estadísticas de compilación en Dynatrace.
Hallazgos
Como resultado, obtenemos un servicio de “monitoreo como servicio”, automatizado en el proceso de integración continua. El desarrollador o evaluador sólo necesita definir una lista de métricas en un archivo JSON y todo lo demás sucede automáticamente. Recibimos un control de calidad transparente de las versiones: todas las notificaciones sobre rendimiento, consumo de recursos o regresiones arquitectónicas.
Tarea 2. Automatización del control de calidad del software en un entorno de producción.
Entonces, hemos resuelto el problema de cómo automatizar el proceso de monitoreo en la etapa de prueba en Pipeline. De esta forma minimizamos el porcentaje de ensamblajes de baja calidad que llegan al entorno de producción.
Pero, ¿qué hacer si se acaba vendiendo software defectuoso o si algo simplemente se estropea? Para una utopía, queríamos mecanismos que detectaran automáticamente los problemas y, si era posible, que el propio sistema restaurara su funcionalidad, al menos por la noche.
Para hacer esto, necesitamos, por analogía con la sección anterior, prever controles automáticos de calidad del software en el entorno de producción y basarlos en escenarios para la autorreparación del sistema.
Autocorrección como código
La mayoría de las empresas ya tienen una base de conocimientos acumulada sobre varios tipos de problemas comunes y una lista de acciones para solucionarlos, por ejemplo, reiniciar procesos, limpiar recursos, revertir versiones, restaurar cambios de configuración no válidos, aumentar o disminuir la cantidad de componentes en el grupo, cambiando el contorno azul o verde, etc.
Si bien muchos de los equipos con los que hablo conocen estos casos de uso desde hace años, pocos han pensado en automatizarlos o han invertido en ellos.
Si lo piensas bien, no hay nada demasiado complicado en la implementación de procesos para el rendimiento de aplicaciones de autorreparación; debes presentar los escenarios de trabajo ya conocidos de tus administradores en forma de scripts de código (el concepto de "reparación automática como código"). , que escribiste con anticipación para cada caso específico. Los scripts de reparación automática deben tener como objetivo eliminar la causa raíz del problema. Usted mismo determina las acciones correctas para responder a un incidente.
Cualquier métrica de tu sistema de seguimiento puede actuar como disparador para iniciar el script, lo principal es que estas métricas determinen con precisión que todo está mal, ya que no querrás obtener falsos positivos en un entorno productivo.
Puede utilizar cualquier sistema o conjunto de sistemas: Prometheus, ELK Stack, Zabbix, etc. Pero daré algunos ejemplos basados en una solución APM (Dynatrace volverá a ser un ejemplo) que también te ayudarán a hacerte la vida más fácil.
En primer lugar está todo lo relacionado con el rendimiento en cuanto al funcionamiento de la aplicación. La solución proporciona cientos de métricas en varios niveles que puede utilizar como desencadenantes:
- nivel de usuario (navegadores, aplicaciones móviles, dispositivos IoT, comportamiento del usuario, conversión, etc.);
- nivel de servicio y operaciones (rendimiento, disponibilidad, errores, etc.);
- nivel de infraestructura de la aplicación (métricas del sistema operativo host, JMX, MQ, servidor web, etc.);
- nivel de plataforma (virtualización, nube, contenedor, etc.).
Monitoreo de niveles en Dynatrace.
En segundo lugar, como dije antes, Dynatrace tiene una API abierta, lo que hace que sea muy fácil de integrar con varios sistemas de terceros. Por ejemplo, enviar una notificación al sistema de automatización cuando se exceden los parámetros de control.
A continuación se muestra un ejemplo para interactuar con Ansible.
A continuación daré algunos ejemplos de qué tipo de automatización se puede realizar. Esto es sólo una parte de los casos; su lista en su entorno sólo puede estar limitada por su imaginación y las capacidades de sus herramientas de monitoreo.
1. Implementación incorrecta: reversión de la versión
Incluso si probamos todo muy bien en un entorno de prueba, todavía existe la posibilidad de que una nueva versión elimine su aplicación en un entorno de producción. El mismo factor humano no ha sido cancelado.
En la siguiente figura vemos que hay un fuerte salto en el tiempo de ejecución de las operaciones en el servicio. El inicio de este salto coincide con el momento del despliegue de la aplicación. Toda esta información la transmitimos como eventos al sistema de automatización. Si el rendimiento del servicio no vuelve a la normalidad después del tiempo que configuramos, se llama automáticamente a un script que revierte la versión a la anterior.
Degradación del rendimiento de las operaciones después del despliegue.
2. Carga de recursos al 100%: agregue un nodo al enrutamiento
En el siguiente ejemplo, el sistema de monitoreo determina que uno de los componentes está experimentando una carga de CPU del 100%.
Carga de CPU 100%
Hay varios escenarios diferentes posibles para este evento. Por ejemplo, el sistema de seguimiento comprueba además si la falta de recursos está asociada a un aumento de la carga del servicio. Si es así, se ejecuta un script que agrega automáticamente un nodo al enrutamiento, restaurando así la funcionalidad del sistema en su conjunto.
Escalado después de un incidente
3. Falta de espacio en el disco duro - limpieza del disco
Creo que mucha gente ya ha automatizado estos procesos. Con APM, también puede monitorear el espacio libre en el subsistema de disco. Si no hay espacio o el disco funciona lentamente, llamamos a un script para limpiarlo o agregar espacio.
Carga del disco 100%
4. Baja actividad de usuario o baja conversión: cambio entre ramas azul y verde
A menudo veo clientes que utilizan dos bucles (implementación azul-verde) para aplicaciones en un entorno de producción. Esto le permite cambiar rápidamente entre sucursales al entregar nuevos lanzamientos. A menudo, después del despliegue, pueden ocurrir cambios dramáticos que no se notan de inmediato. En este caso, es posible que no se observe una degradación del rendimiento y la disponibilidad. Para responder rápidamente a tales cambios, es mejor utilizar varias métricas que reflejen el comportamiento del usuario (número de sesiones y acciones del usuario, conversión, tasa de rebote). La siguiente figura muestra un ejemplo en el que, cuando las tasas de conversión caen, se produce un cambio entre ramas de software.
La tasa de conversión cae después de cambiar entre ramas de software.
Mecanismos de detección automática de problemas.
Finalmente, les daré un ejemplo más de por qué me gusta más Dynatrace.
En la parte de mi historia sobre la automatización de controles de calidad de ensamblajes en un entorno de prueba, determinamos todos los valores umbral manualmente. Esto es normal en un entorno de prueba; el propio evaluador determina los indicadores antes de cada prueba dependiendo de la carga. En un entorno de producción, es deseable que los problemas se detecten automáticamente, teniendo en cuenta varios mecanismos básicos.
Dynatrace cuenta con interesantes herramientas de inteligencia artificial integradas que, basándose en mecanismos para determinar métricas anómalas (línea de base) y construir un mapa de interacción entre todos los componentes, comparando y correlacionando eventos entre sí, determinan anomalías en el funcionamiento de su servicio y brindan información detallada. información sobre cada problema y causa raíz.
Al analizar automáticamente las dependencias entre componentes, Dynatrace determina no solo si el servicio problemático es la causa raíz, sino también su dependencia de otros servicios. En el siguiente ejemplo, Dynatrace monitorea y evalúa automáticamente el estado de cada servicio dentro de la ejecución de la transacción, identificando el servicio Golang como la causa raíz.
Un ejemplo de cómo determinar la causa raíz de una falla.
La siguiente figura muestra el proceso de monitoreo de problemas con su aplicación desde el inicio de un incidente.
Visualización de un problema emergente con visualización de todos los componentes y eventos en ellos.
El sistema de seguimiento recopiló una cronología completa de los acontecimientos relacionados con el problema surgido. En la ventana debajo de la línea de tiempo vemos todos los eventos clave de cada uno de los componentes. En función de estos eventos, puede establecer procedimientos para la corrección automática en forma de secuencias de comandos de código.
Además, te aconsejo que integres un sistema de seguimiento con Service Desk o un rastreador de errores. Cuando ocurre un problema, los desarrolladores reciben rápidamente información completa para analizarla a nivel de código en el entorno de producción.
Conclusión
Como resultado, terminamos con un proceso de CI/CD con controles de calidad de software automatizados integrados en Pipeline. Minimizamos la cantidad de ensamblajes de baja calidad, aumentamos la confiabilidad del sistema en su conjunto y, si nuestro sistema aún falla, lanzamos mecanismos para restaurarlo.
Definitivamente vale la pena invertir esfuerzos en automatizar el monitoreo de la calidad del software; no siempre es un proceso rápido, pero con el tiempo dará frutos. Recomiendo que después de resolver un nuevo incidente en el entorno de producción, piense inmediatamente qué monitores agregar para realizar comprobaciones en el entorno de prueba para evitar que una compilación incorrecta entre en producción y también cree un script para corregir automáticamente estos problemas.
Espero que mis ejemplos le ayuden en sus esfuerzos. También me interesará ver sus ejemplos de métricas utilizadas para implementar sistemas de autorreparación.
Fuente: habr.com