Ahora en el tema de exageración DevOps. El transportador de integración y entrega continua de CI / CD es implementado por todos los que lo desean. Pero la mayoría no siempre presta la debida atención a garantizar la confiabilidad de los sistemas de información en varias etapas de la canalización de CI / CD. En este artículo, me gustaría hablar sobre mi experiencia en la automatización de los controles de calidad del software y la implementación de posibles escenarios para su "autocuración".

Fuente

Trabajo como ingeniero en el departamento de gestión de servicios de TI en LANIT-Integration . Mi área principal es la implementación de varios sistemas para monitorear el rendimiento y la disponibilidad de las aplicaciones. A menudo me comunico con clientes de TI de diferentes segmentos del mercado sobre cuestiones de actualidad relacionadas con la supervisión de la calidad de sus servicios de TI. La tarea principal es minimizar el tiempo del ciclo de lanzamiento y aumentar la frecuencia de su lanzamiento. Esto, por supuesto, es bueno: más lanzamientos, más funciones nuevas, más usuarios satisfechos, más ganancias. Pero en realidad, no siempre todo sale bien. A tasas de implementación muy altas, la pregunta surge inmediatamente sobre la calidad de nuestros lanzamientos. Incluso con una tubería totalmente automatizada, uno de los mayores problemas es la transferencia de servicios de prueba a producción, lo que no afecta el tiempo de actividad y la interacción del usuario con la aplicación.

Basado en los resultados de numerosas conversaciones con los clientes, puedo decir que el control de calidad de los lanzamientos, el problema de la confiabilidad de la aplicación y la posibilidad de su "autocuración" (por ejemplo, revertir a una versión estable) en varias etapas de la canalización de CI / CD se encuentran entre los temas más interesantes y relevantes.


Recientemente, yo mismo trabajé del lado del cliente, en el servicio de soporte de aplicaciones de banca en línea. La arquitectura de nuestra aplicación utilizaba una gran cantidad de microservicios autoescritos. Lo más triste es que no todos los desarrolladores hicieron frente al alto ritmo de desarrollo, la calidad de algunos microservicios sufrieron, lo que dio lugar a apodos ridículos para ellos y sus creadores. Hubo historias sobre de qué materiales están hechos estos productos.

"Declaración del problema"

La alta frecuencia de lanzamientos y una gran cantidad de microservicios dificultan la comprensión 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 monitoreo. A menudo, después de un lanzamiento nocturno por la mañana, los desarrolladores se sientan en un barril de pólvora y esperan que nada se rompa, aunque en la etapa de prueba todas las comprobaciones tuvieron éxito.

Hay un punto más. En la etapa de prueba, se verifica la operatividad del software: la implementación de las funciones principales de la aplicación y la ausencia de errores. Las estimaciones cualitativas del rendimiento están ausentes o no tienen en cuenta todos los aspectos de la aplicación y la capa de integración. Algunas métricas pueden no verificarse en absoluto. Como resultado, cuando se produce una falla en un entorno productivo, el departamento de soporte técnico solo se entera cuando los usuarios reales comienzan a quejarse. Me gustaría minimizar el impacto del software de baja calidad en los usuarios finales.

Una de las soluciones es implementar procesos de control de calidad de software en varias etapas de la canalización de CI / CD, agregar varios scripts para restaurar el sistema en caso de accidente. También recuerda que tenemos DevOps. Las empresas esperan recibir un nuevo producto lo más rápido posible. Por lo tanto, todos nuestros cheques y scripts deben ser automatizados.

La tarea se divide en dos componentes:

• control de calidad de conjuntos en la etapa de prueba (para automatizar el proceso de captura de conjuntos de calidad inferior);
• control de calidad del software en el entorno de producción (mecanismos automáticos de detección de problemas y posibles escenarios para la autocuración).

Herramienta para monitorear y recolectar métricas

Para realizar las tareas establecidas, se requiere un sistema de monitoreo que pueda detectar problemas y transferirlos a sistemas de automatización en varias etapas de la tubería de CI / CD. Además, un punto positivo será si este sistema proporciona métricas útiles para varios equipos: desarrollo, pruebas, operación. Y bastante maravilloso, si es por negocios.

Para recopilar métricas, puede usar una combinación de diferentes sistemas (Prometheus, ELK Stack, Zabbix, etc.), pero, en mi opinión, las soluciones APM ( Application Performance Monitoring ) son las más adecuadas para estas tareas, lo que puede simplificar enormemente su vida.

Como parte de mi trabajo en el servicio de acompañantes, comencé a hacer un proyecto similar utilizando la solución de clase APM de Dynatrace. Ahora, trabajando como integrador, conozco bastante bien el mercado de los sistemas de monitoreo. Mi opinión subjetiva: Dynatrace es la más adecuada para tales tareas.
La solución Dynatrace proporciona una visualización horizontal de cada operación del usuario con un profundo grado de detalle hasta el nivel de ejecución del código. Puede realizar un seguimiento de toda la cadena de interacción entre varios servicios de información: desde niveles front-end de aplicaciones web y móviles, servidores de aplicaciones back-end, bus de integración hasta una llamada específica a la base de datos.

Fuente Construcción automática de todas las dependencias entre los componentes del sistema.

Fuente Detección automática y construcción de una ruta para una operación de servicio.

También recuerde que necesitamos integrarnos con varias herramientas de automatización. Aquí la solución tiene una API conveniente que le permite enviar y recibir varias métricas y eventos.

A continuación, pasaremos a una discusión más detallada sobre cómo resolver tareas utilizando el sistema Dynatrace.

Tarea 1. Automatización del control de calidad de ensamblajes en la etapa de prueba.

La primera tarea es encontrar los problemas lo antes posible en las etapas del proceso de entrega de la aplicación. Solo las compilaciones de código "buenas" deberían llegar al entorno de producción. Para hacer esto, se deben incluir monitores adicionales en su tubería en la etapa de prueba para verificar la calidad de sus servicios.



Veamos los pasos para implementar esto y automatizar este proceso:

Fuente

La figura muestra el flujo de los pasos de control de calidad del software automatizado:

1. despliegue de un sistema de monitoreo (instalación de agentes);
2. definición de eventos de evaluación de calidad de su software (métricas y valores umbral) y su transferencia al sistema de monitoreo;
3. generación de carga y pruebas de rendimiento;
4. recopilar datos de rendimiento y disponibilidad en un sistema de monitoreo;
5. transferir datos de prueba basados ​​en eventos de evaluación de calidad del software del sistema de monitoreo al sistema CI / CD. Análisis de montaje automático.

Paso 1. Implemente un sistema de monitoreo

Primero debe instalar los agentes en su entorno de prueba. Al mismo tiempo, la solución Dynatrace tiene una buena característica: utiliza el agente universal OneAgent, que se instala en la instancia del sistema operativo (Windows, Linux, AIX), detecta automáticamente sus servicios y comienza a recopilar datos de monitoreo sobre ellos. No necesita configurar un agente por separado para cada proceso. Una situación similar será para las plataformas de nube y contenedores. Al mismo tiempo, también puede automatizar la instalación de agentes. Dynatrace encaja perfectamente en el concepto de "infraestructura como código" ( Infraestructura como código o IaC ): hay scripts e instrucciones listos para todas las plataformas populares. Incruste el agente en la configuración de su servicio, y cuando lo implemente, inmediatamente obtendrá un nuevo servicio con un agente que ya se está ejecutando.

Paso 2. Identifique los eventos de evaluación de calidad de su software

Ahora debe determinar la lista de servicios y operaciones comerciales. Es importante tener en cuenta exactamente las operaciones de los usuarios que son críticas para su servicio. Aquí recomiendo consultar con analistas comerciales y de sistemas.

A continuación, debe determinar qué métricas desea incluir en la verificación para cada uno de los niveles. Por ejemplo, puede ser tiempo de ejecución (con separación por promedio, mediana, percentil, etc.), errores (lógico, servicio, infraestructura, etc.) y varias métricas de infraestructura (montón de memoria, recolector de basura, conteo de hilos, etc.).

Para automatización y facilidad de uso, el equipo de DevOps presenta el concepto de "Monitoreo como código". Lo que quiero decir con esto es que un desarrollador / evaluador puede escribir un archivo JSON simple que defina los indicadores de control de calidad del software.

Veamos un ejemplo de tal archivo JSON. Los objetos de la API de Dynatrace se utilizan como un par clave / valor (consulte la API de Dynatrace para obtener una descripción de la API ).

{    "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 de tiempo:

• timeseriesId: métrica verificada, por ejemplo, Tiempo de respuesta, Conteo de errores, Memoria utilizada, etc.
• agregación: el nivel de agregación de métricas, en nuestro caso promedio, pero puede usar lo que necesite (promedio, mínimo, máximo, suma, conteo, percentil);
• etiquetas: una etiqueta de objeto en el sistema de monitoreo, o puede especificar un identificador de objeto específico;
• severa y de advertencia: estos indicadores ajustan los valores de umbral de nuestras métricas, si el valor de las pruebas excede el umbral severo, entonces nuestro ensamblaje se marca como no exitoso.

La siguiente figura muestra un ejemplo del uso de dichos contenedores.

Fuente

Paso 3. Generación de carga

Después de determinar los niveles de calidad de nuestro servicio, es necesario generar una carga de prueba. Puede usar cualquiera de las herramientas de prueba que le resulten convenientes, por ejemplo, Jmeter, Selenium, Neotys, Gatling, etc.

El sistema de monitoreo Dynatrace le permite capturar varios metadatos de sus pruebas y reconocer qué prueba se relaciona con qué ciclo de lanzamiento y servicio. Se recomienda que agregue encabezados adicionales a las solicitudes HTTP de prueba.

La siguiente figura muestra un ejemplo en el que, utilizando el encabezado opcional X-Dynatrace-Test, marcamos que esta prueba se refiere a probar la operación de agregar un artículo a la cesta.

Fuente

Cuando ejecuta cada prueba de carga, envía información contextual adicional a Dynatrace utilizando la API de eventos desde el servidor CI / CD. Por lo tanto, el sistema puede distinguir entre diferentes pruebas entre sí.

Fuente Evento en el sistema de monitoreo sobre el lanzamiento de pruebas de carga

Paso 4-5. Recopile datos de rendimiento y transfiera datos a un sistema CI / CD

Junto con la prueba generada, se transmite un evento al sistema de monitoreo sobre la necesidad de recopilar datos para verificar los indicadores de calidad del servicio. También se indica nuestro archivo JSON, en el que se definen las métricas clave.

Un evento sobre la necesidad de verificar la calidad del software generado en el servidor CI / CD para enviarlo al sistema de monitoreo

En nuestro ejemplo, el evento de control de calidad se llama perfSigDynatraceReport (Performance_Signature ) ; este es un complemento listo para integrarse con Jenkins, que fue desarrollado por los chicos de T-Systems Multimedia Solutions. Cada evento sobre el lanzamiento de la prueba contiene información sobre el servicio, el número de compilación y el tiempo de prueba. El complemento recopila valores de rendimiento durante el ensamblaje, los evalúa y compara el resultado con ensamblajes anteriores y requisitos no funcionales.

Evento en el sistema de monitoreo sobre el inicio del control de calidad del ensamblaje. Fuente

Una vez completada la prueba, todas las métricas de evaluación de la calidad del software se transfieren al sistema de integración continua, por ejemplo, Jenkins, que genera un informe sobre los resultados.

El resultado de las estadísticas de ensamblaje en el servidor CI / CD. Fuente

Para cada ensamblaje individual, vemos estadísticas para cada métrica que establecemos durante toda la prueba. También vemos si hubo violaciones en ciertos valores de umbral (advertencia y trabas severas). Según las métricas agregadas, todo el ensamblaje se marca como estable, inestable o fallido. Además, para mayor comodidad, puede agregar indicadores para comparar el ensamblaje actual con el anterior en el informe.

Ver estadísticas detalladas de ensamblaje en el servidor CI / CD. Fuente

Comparación detallada de dos conjuntos

Si es necesario, puede ir a la interfaz de Dynatrace y ver con más detalle las estadísticas de cada uno de sus ensamblajes y compararlos entre sí.

Comparación de estadísticas de ensamblaje en Dynatrace. Fuente

Conclusiones

Como resultado, obtenemos el servicio "monitoreo como servicio", automatizado en la tubería de integración continua. El desarrollador o probador solo necesita determinar la lista de métricas en el archivo JSON, y todo lo demás sucede automáticamente. Obtenemos 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, resolvimos el problema de cómo automatizar el proceso de monitoreo en la etapa de prueba en Pipeline. Por lo tanto, minimizamos el porcentaje de ensamblajes de baja calidad que llegan al entorno alimentario.

Pero qué hacer si el software defectuoso aún llega al punto de venta, bueno, o simplemente se rompe algo. Para la utopía, queríamos tener mecanismos para detectar problemas automáticamente y, si es posible, el sistema en sí mismo restablecería su capacidad de trabajo, al menos de noche.

Para hacer esto, nosotros, por analogía con la sección anterior, proporcionamos controles automáticos de calidad del software en el entorno de producción y colocamos scripts para la autocuración del sistema bajo ellos.


Corrección automática como código

La mayoría de las empresas ya tienen una base de conocimiento 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 incorrectos, aumentar o disminuir el número de componentes en un clúster, cambiar el contorno azul o verde y otro

A pesar del hecho de que estos casos de uso se conocen desde hace muchos años para muchos equipos con los que me comunico, solo unos pocos pensaron e invirtieron en su automatización.

Si lo piensa, entonces, en la implementación de procesos para autorreparar la salud de la aplicación, no hay nada súper complicado, debe presentar los escenarios de trabajo bien conocidos de sus administradores en forma de scripts de código (el concepto de "autocorrección como código") que escribió de antemano para cada caso específico. Los escenarios de reparación automática deben abordar la causa raíz del problema. Usted mismo establece las acciones correctas de respuesta a incidentes.

Cualquier métrica de su sistema de monitoreo puede actuar como un disparador para ejecutar un script, lo principal es que estas métricas determinan con precisión que todo es malo, ya que no me gustaría obtener falsos positivos en un entorno productivo.

Puede usar cualquier sistema o conjunto de sistemas: Prometheus, ELK Stack, Zabbix, etc. Pero daré algunos ejemplos basados ​​en la solución APM (Dynatrace volverá a ser un ejemplo), que también ayudarán a facilitarle la vida.

En primer lugar, hay todo lo relacionado con la operabilidad en términos de la aplicación. La solución proporciona cientos de métricas en varios niveles que puede usar 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. Fuente

En segundo lugar, como dije antes, Dynatrace tiene una API abierta, lo que hace que sea muy conveniente integrarlo 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.

Fuente

A continuación daré algunos ejemplos de exactamente qué automatización se puede hacer. Esto es solo una parte de los casos; enumerarlos en su entorno puede estar limitado solo por su imaginación y las capacidades de sus herramientas de monitoreo.

1. Implementación incorrecta: reversión de la versión

Incluso si todos probamos muy bien en un entorno de prueba, todavía existe la posibilidad de que una nueva versión pueda matar su aplicación en el entorno de producción. El mismo factor humano no ha sido cancelado.

En la siguiente figura, vemos que hay un salto brusco en el tiempo de ejecución de las operaciones en el servicio. El comienzo de este salto coincide con el tiempo de implementación de la aplicación. Transferimos toda esta información como eventos al sistema de automatización. Si la capacidad de servicio del servicio no se normaliza después de que expire el tiempo especificado por nosotros, se llama automáticamente a un script que revierte la versión a la anterior.

Degradación del rendimiento después del despliegue. Fuente

2. Carga de recursos al 100%: agregue un nodo a la ruta

En el siguiente ejemplo, el sistema de monitoreo determina que uno de los componentes tiene un 100% de utilización de la CPU.

Utilización de CPU 100%

Varios escenarios diferentes son posibles para este evento. Por ejemplo, el sistema de monitoreo además verifica si la falta de recursos está asociada con un aumento en la carga del servicio. Si, sí, se ejecuta un script que agrega automáticamente el nodo al enrutamiento, restaurando así el sistema como un todo.

Escalando nodos después de un incidente

3. Falta de espacio en el disco duro: limpieza del disco

Creo que muchos de estos procesos ya están automatizados. Usando APM, también puede monitorear el espacio libre en el subsistema de disco. En ausencia de espacio u operación lenta del disco, llamamos al script para limpiar o agregar espacio.


Disco de carga 100%

4. Baja actividad del usuario o baja conversión: cambie entre las ramas azul y verde

A menudo me encuentro con clientes que usan dos circuitos (despliegue azul-verde) para aplicaciones en el entorno de producción. Esto le permite cambiar rápidamente entre sucursales al entregar nuevas versiones. A menudo, después del despliegue, pueden ocurrir cambios cardinales que no se notan de inmediato. Sin embargo, es posible que no se observe degradación en el rendimiento y la disponibilidad. Para responder rápidamente a dichos cambios, es mejor usar varias métricas que reflejen el comportamiento del usuario (número de sesiones y acciones del usuario, conversión, porcentaje de rebote). La siguiente figura muestra un ejemplo en el que cuando cae la conversión, se produce el cambio entre las ramas de software.

Caída de conversión después de cambiar entre ramas de software. Fuente

Mecanismos automáticos de determinación de problemas

Al final daré un ejemplo más, por lo que me gusta más Dynatrace.

En parte de mi historia sobre la automatización del control de calidad del ensamblaje en un entorno de prueba, determinamos todos los valores de umbral en modo manual. Esto es normal para un entorno de prueba, el probador mismo determina los indicadores antes de cada prueba, dependiendo de la carga. En el entorno de producción, es deseable que los problemas se detecten automáticamente, teniendo en cuenta los diversos mecanismos de referencia.

Dynatrace tiene interesantes herramientas integradas de inteligencia artificial que, basadas en los mecanismos para determinar métricas anómalas (línea de base) y construir un mapa de interacción entre todos los componentes, comparar y correlacionar eventos entre sí, determinar anomalías en el trabajo de su servicio y proporcionar información detallada sobre cada problema y causa raíz.

Al analizar automáticamente las dependencias entre los componentes, Dynatrace determina no solo si el servicio problemático es la causa principal, sino también su dependencia de otros servicios. En el siguiente ejemplo, Dynatrace monitorea y evalúa automáticamente el estado de cada servicio como parte de una transacción, identifica el servicio de Golang como la razón principal.

Un ejemplo de determinación de la causa raíz de una falla. Fuente

La siguiente figura muestra el proceso de monitoreo de problemas con su aplicación desde el inicio del incidente.

Visualización de un problema emergente con la visualización de todos los componentes y eventos en ellos.

El sistema de monitoreo ha compilado una cronología completa de eventos sobre el problema. En la ventana debajo de la línea de tiempo, vemos todos los eventos clave en cada uno de los componentes. En función de estos eventos, puede especificar procedimientos para la corrección automática en forma de scripts de código.

Además, le aconsejo que integre el sistema de monitoreo con Service Desk o un rastreador de errores. Si se produce un problema, los desarrolladores reciben rápidamente información completa para su análisis a nivel de código en el entorno de producción.

Conclusión

Como resultado, terminamos con un transportador 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 aún interrumpimos el rendimiento del sistema, lanzamos mecanismos para restaurarlo.


Definitivamente vale la pena el esfuerzo para automatizar el monitoreo de la calidad del software, no siempre es un proceso rápido, pero con el tiempo dará sus frutos. Recomiendo que después de resolver un nuevo incidente en el entorno de producción, piense inmediatamente qué monitores agregar para las comprobaciones en el entorno de prueba a fin de evitar una compilación incorrecta en la producción, y también cree un script para solucionar automáticamente estos problemas.

Espero que mis ejemplos te ayuden en tus esfuerzos. También será interesante para mí ver sus ejemplos de métricas usadas para la implementación de sistemas de autocuración.

Fuente