Agora o tema de DevOps está en bombo. Integración continua e canalización de entrega todo o mundo o está a implementar. Pero a maioría non sempre presta a debida atención a garantir a fiabilidade dos sistemas de información en varias etapas do Pipeline CI/CD. Neste artigo gustaríame falar da miña experiencia na automatización das comprobacións de calidade do software e na implementación de posibles escenarios para a súa "autocuración".
Traballo como enxeñeiro no departamento de xestión de servizos informáticos dunha empresa . A miña área principal de especialización é a implementación de varios sistemas de seguimento do rendemento e da dispoñibilidade de aplicacións. Adoita comunicarme con clientes de TI de diferentes segmentos de mercado sobre cuestións actuais relativas ao seguimento da calidade dos seus servizos de TI. O obxectivo principal é minimizar o tempo do ciclo de lanzamento e aumentar a frecuencia dos lanzamentos. Isto, por suposto, está ben: máis versións - máis novas funcións - máis usuarios satisfeitos - máis beneficios. Pero en realidade, as cousas non sempre saen ben. Con taxas de implantación moi altas, inmediatamente xorde a pregunta sobre a calidade dos nosos lanzamentos. Mesmo cunha canalización totalmente automatizada, un dos maiores desafíos é mover os servizos das probas á produción sen afectar o tempo de actividade das aplicacións e a experiencia do usuario.
En base aos resultados de numerosas conversacións cos clientes, podo dicir que liberar o control de calidade, o problema da fiabilidade da aplicación e a posibilidade da súa "autocuración" (por exemplo, volver a unha versión estable) en varias etapas do CI /CD pipeline están entre os temas máis interesantes e relevantes.
Recentemente, eu mesmo traballei no lado do cliente: no servizo de soporte de software de aplicacións bancarias en liña. A arquitectura da nosa aplicación utilizou un gran número de microservizos escritos por si mesmo. O máis triste é que non todos os desenvolvedores puideron soportar o alto ritmo de desenvolvemento; a calidade dalgúns microservizos sufriu, o que deu lugar a alcumes divertidos para eles e os seus creadores. Había historias sobre de que materiais estaban feitos estes produtos.
"Formulación do problema"
A alta frecuencia de lanzamentos e a gran cantidade de microservizos dificultan a comprensión do funcionamento da aplicación no seu conxunto, tanto na fase de proba como na fase operativa. Os cambios prodúcense constantemente e é moi difícil controlalos sen boas ferramentas de vixilancia. Moitas veces, despois dun lanzamento nocturno pola mañá, os desenvolvedores sentan como nun barril de pólvora e agardan a que nada se rompa, aínda que todas as comprobacións foron exitosas na fase de proba.
Hai un punto máis. Na fase de proba, compróbase a funcionalidade do software: a implementación das principais funcións da aplicación e a ausencia de erros. Faltan as avaliacións cualitativas do rendemento ou non teñen en conta todos os aspectos da aplicación e da capa de integración. É posible que algunhas métricas non se comproben en absoluto. Como resultado, cando se produce unha avaría nun ambiente de produción, o departamento de soporte técnico só se entera diso cando os usuarios reais comezan a queixarse. Gustaríame minimizar o impacto do software de baixa calidade nos usuarios finais.
Unha das solucións consiste en implementar procesos de comprobación da calidade do software en varias fases do Pipeline CI/CD, e engadir varios escenarios para restaurar o sistema en caso de emerxencia. Tamén lembramos que temos DevOps. As empresas esperan recibir un produto novo o máis rápido posible. Polo tanto, todas as nosas comprobacións e scripts deben estar automatizados.
A tarefa divídese en dous compoñentes:
- control de calidade dos conxuntos na fase de proba (para automatizar o proceso de captura de conxuntos de baixa calidade);
- control de calidade do software no contorno de produción (mecanismos de detección automática de problemas e posibles escenarios para a súa autocuración).
Ferramenta de seguimento e recollida de métricas
Para acadar os obxectivos marcados, é necesario un sistema de vixilancia que permita detectar problemas e transferilos a sistemas de automatización en varias etapas do pipeline CI/CD. Tamén será positivo que este sistema proporcione métricas útiles para varios equipos: desenvolvemento, probas, funcionamento. E é absolutamente marabilloso se tamén é para negocios.
Para recoller métricas, pode usar un conxunto de sistemas diferentes (Prometheus, ELK Stack, Zabbix, etc.), pero, na miña opinión, as solucións de clase APM son as máis adecuadas para estas tarefas (), que pode simplificar moito a súa vida.
Como parte do meu traballo no servizo de soporte, comecei a facer un proxecto similar usando unha solución de clase APM de Dynatrace. Agora, traballando para un integrador, coñezo bastante ben o mercado dos sistemas de monitorización. A miña opinión subxectiva: Dynatrace é o máis axeitado para resolver este tipo de problemas.
Dynatrace ofrece unha vista horizontal de cada operación do usuario a un nivel granular ata o nivel de execución de código. Podes rastrexar toda a cadea de interacción entre varios servizos de información: desde os niveis front-end de aplicacións web e móbiles, servidores de aplicacións back-end, bus de integración ata unha chamada específica á base de datos.
. Construción automática de todas as dependencias entre os compoñentes do sistema
. Detección automática e construción da ruta de operación do servizo
Tamén lembramos que debemos integrarnos con diversas ferramentas de automatización. Aquí a solución ten unha API conveniente que che permite enviar e recibir varias métricas e eventos.
A continuación, pasemos a unha ollada máis detallada sobre como resolver estes problemas usando o sistema Dynatrace.
Tarefa 1. Automatización do control de calidade dos conxuntos na fase de proba
O primeiro reto é atopar os problemas o antes posible no proceso de entrega da aplicación. Só as compilacións de código "boas" deberían chegar á produción. Para iso, o seu pipeline na fase de proba debería incluír monitores adicionais para comprobar a calidade dos seus servizos.
Vexamos paso a paso como implementar isto e automatizar este proceso:
A figura mostra o fluxo dos pasos automatizados das probas de calidade do software:
- implantación dun sistema de vixilancia (instalación de axentes);
- identificar eventos para avaliar a calidade do seu software (métricas e valores límite) e transferilos ao sistema de seguimento;
- xeración de probas de carga e rendemento;
- recollendo datos de rendemento e dispoñibilidade no sistema de seguimento;
- transferencia de datos de proba baseados en eventos de avaliación da calidade do software do sistema de seguimento ao sistema CI/CD. Análise automática de conxuntos.
Paso 1. Implantación do sistema de vixilancia
Primeiro cómpre instalar os axentes no seu ambiente de proba. Ao mesmo tempo, a solución Dynatrace ten unha característica agradable: usa o axente universal OneAgent, que está instalado nunha instancia de SO (Windows, Linux, AIX), detecta automaticamente os seus servizos e comeza a recoller datos de seguimento sobre eles. Non é necesario configurar un axente separado para cada proceso. A situación será similar para as plataformas cloud e de contedores. Ao mesmo tempo, tamén pode automatizar o proceso de instalación do axente. Dynatrace encaixa perfectamente no concepto de "infraestrutura como código" (): Hai guións e instrucións preparados para todas as plataformas populares. Incorporas o axente á configuración do teu servizo e, cando o implementas, recibe inmediatamente un novo servizo cun axente que xa funciona.
Paso 2: define os teus eventos de calidade do software
Agora cómpre decidir sobre a lista de servizos e operacións comerciais. É importante ter en conta exactamente aquelas operacións dos usuarios que son críticas para o seu servizo. Aquí recomendo consultar con analistas empresariais e de sistemas.
A continuación, debes determinar que métricas queres incluír na revisión para cada nivel. Por exemplo, este pode ser o tempo de execución (dividido en media, mediana, percentiles, etc.), erros (lóxicos, de servizo, de infraestrutura, etc.) e varias métricas de infraestrutura (heap de memoria, colector de lixo, conta de fíos, etc.).
Para a automatización e facilidade de uso polo equipo de DevOps, aparece o concepto de "Monitorización como código". O que quero dicir con isto é que un programador/probador pode escribir un ficheiro JSON sinxelo que defina as métricas de garantía de calidade do software.
Vexamos un exemplo deste ficheiro JSON. Os obxectos da API de Dynatrace úsanse como pares clave/valor (a descrición da API pódese atopar 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
}
]
}O ficheiro é unha matriz de definicións de series temporais:
- timeseriesId: a métrica que se está a comprobar, por exemplo, o tempo de resposta, o reconto de erros, a memoria utilizada, etc.;
- agregación: nivel de agregación de métricas, no noso caso, promedio, pero podes usar calquera que necesites (promedio, mínimo, máximo, suma, reconto, percentil);
- tags: etiqueta de obxecto no sistema de monitorización, ou pode especificar un identificador de obxecto específico;
- grave e aviso: estes indicadores regulan os valores límite das nosas métricas; se o valor da proba supera o limiar severo, a nosa compilación marcarase como non exitosa.
A seguinte figura mostra un exemplo do uso destes limiares.
Paso 3: Xeración de carga
Unha vez que determinamos os niveis de calidade do noso servizo, necesitamos xerar unha carga de proba. Podes usar calquera das ferramentas de proba coas que che guste, como Jmeter, Selenium, Neotys, Gatling, etc.
O sistema de seguimento de Dynatrace permítelle capturar varios metadatos das súas probas e recoñecer que probas pertencen a que ciclo de lanzamento e a que servizo. Recoméndase engadir cabeceiras adicionais ás solicitudes de proba HTTP.
Na seguinte figura móstrase un exemplo onde, mediante a cabeceira adicional X-Dynatrace-Test, indicamos que esta proba se refire a probar o funcionamento de engadir un artigo ao carro.
Cando executa cada proba de carga, envía información contextual adicional a Dynatrace mediante a API de eventos desde o servidor CI/CD. Deste xeito, o sistema pode diferenciar entre diferentes probas.
. Evento no sistema de vixilancia sobre o inicio da proba de carga
Paso 4-5. Recoller datos de rendemento e transferir datos ao sistema CI/CD
Xunto coa proba xerada, transmítese ao sistema de seguimento un evento sobre a necesidade de recoller datos sobre a comprobación dos indicadores de calidade do servizo. Tamén especifica o noso ficheiro JSON, que define as métricas clave.
Evento sobre a necesidade de comprobar a calidade do software xerado no servidor CI/CD para o seu envío ao sistema de monitorización
No noso exemplo, chámase o evento de comprobación de calidade perfSigDynatraceReport (Sinatura_Rendimento) - isto está listo para a integración con Jenkins, que foi desenvolvido polos mozos de T-Systems Multimedia Solutions. Cada evento de lanzamento de proba contén información sobre o servizo, o número de compilación e o tempo de proba. O complemento recolle valores de rendemento no momento da compilación, avalíaos e compara o resultado con compilacións anteriores e requisitos non funcionais.
Evento no sistema de seguimento sobre o inicio dun control de calidade de construción.
Despois de completar a proba, todas as métricas para avaliar a calidade do software transfírense de novo a un sistema de integración continua, por exemplo, Jenkins, que xera un informe sobre os resultados.
O resultado das estatísticas sobre as montaxes no servidor CI/CD.
Para cada compilación individual, vemos estatísticas para cada métrica que establecemos ao longo de toda a proba. Tamén vemos se houbo infraccións en determinados valores limiares (aviso e límites graves). En función das métricas agregadas, a compilación enteira márcase como estable, inestable ou fallida. Ademais, para maior comodidade, pode engadir indicadores ao informe que compare a construción actual coa anterior.
Consulta estatísticas detalladas sobre conxuntos no servidor CI/CD.
Comparación detallada de dous conxuntos
Se é necesario, podes ir á interface de Dynatrace e alí podes ver as estatísticas de cada unha das túas compilacións con máis detalle e comparalas entre elas.
Comparación de estatísticas de compilación en Dynatrace.
Descubrimentos
Como resultado, obtemos un servizo de "seguimento como servizo", automatizado no proceso de integración continua. O programador ou probador só precisa definir unha lista de métricas nun ficheiro JSON e todo o demais ocorre automaticamente. Recibimos un control de calidade transparente dos lanzamentos: todas as notificacións sobre rendemento, consumo de recursos ou regresións arquitectónicas.
Tarefa 2. Automatización do control de calidade do software nun contorno de produción
Entón, resolvemos o problema de como automatizar o proceso de seguimento na fase de proba en Pipeline. Deste xeito minimizamos a porcentaxe de conxuntos de baixa calidade que chegan ao entorno de produción.
Pero que facer se acaba vendendo software defectuoso ou se rompe algo. Por unha utopía, queriamos mecanismos para detectar automaticamente os problemas e, se é posible, o propio sistema para restaurar a súa funcionalidade, polo menos pola noite.
Para iso, necesitamos, por analoxía co apartado anterior, prever controis automáticos de calidade do software no contorno de produción e basealos en escenarios para a autocuración do sistema.
Corrección automática como código
A maioría das empresas xa teñen unha base de coñecemento acumulada de varios tipos de problemas comúns e unha lista de accións para solucionalos, por exemplo, reiniciar procesos, limpar recursos, restaurar versións, restaurar cambios de configuración non válidos, aumentar ou diminuír o número de compoñentes en o clúster, cambiando o contorno azul ou verde, etc.
Aínda que estes casos de uso son coñecidos desde hai anos por moitos dos equipos cos que falo, poucos pensaron ou investiron en automatizalos.
Se pensas niso, non hai nada demasiado complicado na implementación de procesos para o rendemento das aplicacións de autocuración; cómpre presentar os escenarios de traballo xa coñecidos dos teus administradores en forma de scripts de código (o concepto de "corrección automática como código"). , que escribiu previamente para cada caso concreto. Os scripts de reparación automática deben estar dirixidos a eliminar a causa raíz do problema. Vostede mesmo determina as accións correctas para responder a un incidente.
Calquera métrica do teu sistema de seguimento pode actuar como un disparador para lanzar o script, o principal é que estas métricas determinan con precisión que todo está mal, xa que non queres obter falsos positivos nun ambiente produtivo.
Podes usar calquera sistema ou conxunto de sistemas: Prometheus, ELK Stack, Zabbix, etc. Pero vou poñer algúns exemplos baseados nunha solución APM (Dynatrace será un exemplo de novo) que tamén axudará a facerche a vida máis fácil.
En primeiro lugar, hai todo o relacionado co rendemento en termos de funcionamento da aplicación. A solución ofrece centos de métricas en varios niveis que podes usar como disparadores:
- nivel de usuario (navegadores, aplicacións móbiles, dispositivos IoT, comportamento do usuario, conversión, etc.);
- nivel de servizo e operacións (rendemento, dispoñibilidade, erros, etc.);
- nivel de infraestrutura de aplicacións (métricas do sistema operativo host, JMX, MQ, servidor web, etc.);
- nivel de plataforma (virtualización, nube, contedor, etc.).
Monitorización dos niveis en Dynatrace.
En segundo lugar, como dixen anteriormente, Dynatrace ten unha API aberta, o que facilita a integración con varios sistemas de terceiros. Por exemplo, enviar unha notificación ao sistema de automatización cando se superan os parámetros de control.
A continuación móstrase un exemplo para interactuar con Ansible.
A continuación darei algúns exemplos de que tipo de automatización se pode facer. Esta é só unha parte dos casos; a súa lista no seu contorno só pode verse limitada pola súa imaxinación e as capacidades das súas ferramentas de seguimento.
1. Implementación incorrecta: reversión da versión
Aínda que probamos todo moi ben nun ambiente de proba, aínda existe a posibilidade de que unha nova versión poida matar a túa aplicación nun ambiente de produción. O mesmo factor humano non foi cancelado.
Na seguinte figura vemos que hai un salto brusco no tempo de execución das operacións no servizo. O inicio deste salto coincide co momento do despregue na aplicación. Transmitimos toda esta información como eventos ao sistema de automatización. Se o rendemento do servizo non volve á normalidade despois do tempo que fixamos, entón chámase automaticamente un script que fai retroceder a versión á antiga.
Degradación do rendemento das operacións despois da implantación.
2. Carga de recursos ao 100 %: engade un nodo ao enrutamento
No seguinte exemplo, o sistema de monitorización determina que un dos compoñentes está experimentando unha carga de CPU do 100%.
Carga da CPU 100%
Hai varios escenarios diferentes posibles para este evento. Por exemplo, o sistema de vixilancia comproba adicionalmente se a falta de recursos está asociada a un aumento da carga do servizo. Se é así, execútase un script que engade automaticamente un nodo ao enrutamento, restaurando así a funcionalidade do sistema no seu conxunto.
Escalado despois dun incidente
3. Falta de espazo no disco duro - limpeza do disco
Creo que moitas persoas xa automatizaron estes procesos. Usando APM, tamén pode supervisar o espazo libre no subsistema de disco. Se non hai espazo ou o disco funciona lentamente, chamamos a un script para limpalo ou engadir espazo.
Carga do disco 100%
4. Baixa actividade do usuario ou pouca conversión: cambio entre ramas azuis e verdes
Moitas veces vexo clientes usando dous bucles (implementación azul-verde) para aplicacións nun ambiente de produción. Isto permítelle cambiar rapidamente entre ramas ao entregar novos lanzamentos. Moitas veces, despois da implantación, pódense producir cambios dramáticos que non son inmediatamente perceptibles. Neste caso, é posible que non se observe unha degradación do rendemento e da dispoñibilidade. Para responder rapidamente a tales cambios, é mellor utilizar varias métricas que reflictan o comportamento do usuario (número de sesións e accións do usuario, conversión, taxa de rebote). A seguinte figura mostra un exemplo no que, cando as taxas de conversión baixan, prodúcese o cambio entre ramas de software.
A taxa de conversión cae despois de cambiar entre ramas de software.
Mecanismos para a detección automática de problemas
Para rematar, vouche dar un exemplo máis de por que me gusta máis Dynatrace.
Na parte da miña historia sobre a automatización das comprobacións de calidade dos conxuntos nun ambiente de proba, determinamos todos os valores límite manualmente. Isto é normal nun ambiente de proba; o propio probador determina os indicadores antes de cada proba dependendo da carga. Nun entorno de produción, é desexable que os problemas se detecten automaticamente, tendo en conta varios mecanismos de referencia.
Dynatrace dispón de interesantes ferramentas de intelixencia artificial incorporadas que, baseándose en mecanismos para determinar métricas anómalas (baselining) e construír un mapa de interacción entre todos os compoñentes, comparando e correlacionando eventos entre si, determinan anomalías no funcionamento do seu servizo e proporcionan información detallada. información sobre cada problema e causa raíz.
Ao analizar automaticamente as dependencias entre compoñentes, Dynatrace determina non só se o servizo problemático é a causa raíz, senón tamén a súa dependencia doutros servizos. No seguinte exemplo, Dynatrace supervisa e avalía automaticamente a saúde de cada servizo dentro da execución da transacción, identificando o servizo Golang como a causa raíz.
Un exemplo de determinación da causa raíz dun fallo.
A seguinte figura mostra o proceso de seguimento de problemas coa súa aplicación desde o inicio dunha incidencia.
Visualización dun problema emerxente con visualización de todos os compoñentes e eventos neles
O sistema de seguimento recolleu unha cronoloxía completa de acontecementos relacionados co problema xurdido. Na xanela debaixo da liña de tempo vemos todos os eventos clave de cada un dos compoñentes. En función destes eventos, pode establecer procedementos para a corrección automática en forma de scripts de código.
Ademais, recoméndoche que integres un sistema de monitorización con Service Desk ou un rastreador de erros. Cando se produce un problema, os desenvolvedores reciben rapidamente información completa para analizala a nivel de código no ambiente de produción.
Conclusión
Como resultado, acabamos cunha canalización CI/CD con comprobacións de calidade do software automatizadas integradas en Pipeline. Minimizamos o número de conxuntos de baixa calidade, aumentamos a fiabilidade do sistema no seu conxunto e, se o noso sistema aínda falla, lanzamos mecanismos para restauralo.
Definitivamente paga a pena investir esforzos na automatización do seguimento da calidade do software; non sempre é un proceso rápido, pero co paso do tempo dará os seus froitos. Recomendo que, despois de resolver un novo incidente no ambiente de produción, pense inmediatamente en que monitores engadir para as comprobacións no ambiente de proba para evitar que entre en produción unha mala compilación, e tamén cree un script para corrixir automaticamente estes problemas.
Espero que os meus exemplos che axuden nos teus esforzos. Tamén me interesará ver os teus exemplos de métricas utilizadas para implementar sistemas de autocuración.
Fonte: www.habr.com