Agora o tópico DevOps está em alta. Integração contínua e pipeline de entrega todo mundo está implementando isso. Mas a maioria nem sempre presta a devida atenção à garantia da fiabilidade dos sistemas de informação nas várias fases do pipeline de CI/CD. Neste artigo gostaria de falar sobre minha experiência na automatização de verificações de qualidade de software e na implementação de possíveis cenários para sua “autocura”.
Trabalho como engenheiro no departamento de gerenciamento de serviços de TI de uma empresa . Minha principal área de especialização é a implementação de diversos sistemas de monitoramento de desempenho e disponibilidade de aplicativos. Comunico-me frequentemente com clientes de TI de diferentes segmentos de mercado sobre questões atuais relacionadas ao monitoramento da qualidade de seus serviços de TI. O objetivo principal é minimizar o tempo do ciclo de lançamento e aumentar a frequência dos lançamentos. É claro que tudo isso é bom: mais lançamentos - mais novos recursos - mais usuários satisfeitos - mais lucro. Mas, na realidade, as coisas nem sempre funcionam bem. Com taxas de implantação muito altas, surge imediatamente a questão sobre a qualidade de nossos lançamentos. Mesmo com um pipeline totalmente automatizado, um dos maiores desafios é passar os serviços dos testes para a produção sem afetar o tempo de atividade dos aplicativos e a experiência do usuário.
Com base nos resultados de inúmeras conversas com clientes, posso dizer que o controle de qualidade da versão, o problema de confiabilidade do aplicativo e a possibilidade de sua “autocorreção” (por exemplo, reverter para uma versão estável) em vários estágios do CI O pipeline de /CD está entre os tópicos mais interessantes e relevantes.
Recentemente, eu próprio trabalhei no lado do cliente - no serviço de suporte de software de aplicativos bancários on-line. A arquitetura do nosso aplicativo utilizou um grande número de microsserviços autoescritos. O mais triste é que nem todos os desenvolvedores conseguiram lidar com o alto ritmo de desenvolvimento, a qualidade de alguns microsserviços foi prejudicada, o que deu origem a apelidos engraçados para eles e seus criadores. Havia histórias sobre de que materiais esses produtos eram feitos.
"Formulação do problema"
A alta frequência de lançamentos e a grande quantidade de microsserviços dificultam o entendimento do funcionamento da aplicação como um todo, tanto na fase de testes quanto na fase operacional. As mudanças ocorrem constantemente e é muito difícil controlá-las sem boas ferramentas de monitoramento. Muitas vezes, após um lançamento noturno pela manhã, os desenvolvedores sentam-se como um barril de pólvora e esperam que nada quebre, embora todas as verificações tenham sido bem-sucedidas na fase de testes.
Há mais um ponto. Na fase de testes, é verificada a funcionalidade do software: a implementação das principais funções da aplicação e a ausência de erros. As avaliações qualitativas de desempenho estão faltando ou não levam em consideração todos os aspectos da aplicação e da camada de integração. Algumas métricas podem nem ser verificadas. Como resultado, quando ocorre uma falha em um ambiente de produção, o departamento de suporte técnico só fica sabendo quando usuários reais começam a reclamar. Gostaria de minimizar o impacto do software de baixa qualidade nos usuários finais.
Uma das soluções é implementar processos de verificação da qualidade do software nas diversas etapas do Pipeline CI/CD, e adicionar diversos cenários para restauração do sistema em caso de emergência. Lembramos também que temos DevOps. As empresas esperam receber um novo produto o mais rápido possível. Portanto, todas as nossas verificações e scripts devem ser automatizados.
A tarefa está dividida em dois componentes:
- controle de qualidade de montagens em fase de testes (para automatizar o processo de detecção de montagens de baixa qualidade);
- controle de qualidade de software no ambiente de produção (mecanismos de detecção automática de problemas e possíveis cenários para sua autocura).
Ferramenta para monitoramento e coleta de métricas
Para atingir os objetivos definidos, é necessário um sistema de monitoramento que possa detectar problemas e transferi-los para sistemas de automação em vários estágios do pipeline de CI/CD. Também será positivo se este sistema fornecer métricas úteis para várias equipes: desenvolvimento, teste, operação. E é absolutamente maravilhoso se for também para negócios.
Para coletar métricas, você pode usar um conjunto de sistemas diferentes (Prometheus, ELK Stack, Zabbix, etc.), mas, na minha opinião, as soluções da classe APM são mais adequadas para essas tarefas (), o que pode simplificar muito a sua vida.
Como parte do meu trabalho no serviço de suporte, comecei a fazer um projeto semelhante usando uma solução de classe APM da Dynatrace. Agora, trabalhando para um integrador, conheço bastante bem o mercado de sistemas de monitoramento. Minha opinião subjetiva: Dynatrace é mais adequado para resolver esses problemas.
Dynatrace fornece uma visão horizontal de cada operação do usuário em um nível granular até o nível de execução do código. Você pode rastrear toda a cadeia de interação entre vários serviços de informação: desde os níveis front-end de aplicativos web e móveis, servidores de aplicativos back-end, barramento de integração até uma chamada específica ao banco de dados.
. Construção automática de todas as dependências entre componentes do sistema
. Detecção automática e construção do caminho de operação do serviço
Lembramos também que precisamos integrar com diversas ferramentas de automação. Aqui a solução possui uma API conveniente que permite enviar e receber diversas métricas e eventos.
A seguir, vamos dar uma olhada mais detalhada em como resolver esses problemas usando o sistema Dynatrace.
Tarefa 1. Automação do controle de qualidade de montagens na fase de testes
O primeiro desafio é encontrar problemas o mais cedo possível no pipeline de entrega de aplicativos. Somente construções de código “boas” devem chegar à produção. Para fazer isso, seu pipeline em fase de teste deve incluir monitores adicionais para verificar a qualidade de seus serviços.
Vamos dar uma olhada passo a passo em como implementar isso e automatizar esse processo:
A figura mostra o fluxo das etapas automatizadas de teste de qualidade de software:
- implantação de sistema de monitoramento (instalação de agentes);
- identificar eventos para avaliar a qualidade do seu software (métricas e valores limite) e transferi-los para o sistema de monitoramento;
- geração de testes de carga e desempenho;
- coletar dados de desempenho e disponibilidade no sistema de monitoramento;
- transferência de dados de teste com base em eventos de avaliação de qualidade de software do sistema de monitoramento para o sistema CI/CD. Análise automática de montagens.
Passo 1. Implantação do sistema de monitoramento
Primeiro você precisa instalar os agentes em seu ambiente de teste. Ao mesmo tempo, a solução Dynatrace possui um recurso interessante - ela usa o agente universal OneAgent, que é instalado em uma instância do sistema operacional (Windows, Linux, AIX), detecta automaticamente seus serviços e começa a coletar dados de monitoramento sobre eles. Não é necessário configurar um agente separado para cada processo. A situação será semelhante para plataformas de nuvem e contêineres. Ao mesmo tempo, você também pode automatizar o processo de instalação do agente. Dynatrace se encaixa perfeitamente no conceito de “infraestrutura como código” (): Existem scripts e instruções prontos para todas as plataformas populares. Você incorpora o agente na configuração do seu serviço e, ao implantá-lo, recebe imediatamente um novo serviço com um agente já em funcionamento.
Etapa 2: Defina seus eventos de qualidade de software
Agora você precisa decidir sobre a lista de serviços e operações comerciais. É importante levar em consideração exatamente as operações do usuário que são críticas para o negócio do seu serviço. Aqui recomendo consultar analistas de negócios e sistemas.
Em seguida, você precisa determinar quais métricas deseja incluir na revisão de cada nível. Por exemplo, pode ser o tempo de execução (dividido em média, mediana, percentis etc.), erros (lógicos, de serviço, infraestrutura etc.) e diversas métricas de infraestrutura (pilha de memória, coletor de lixo, contagem de threads etc.).
Para automação e facilidade de uso pela equipe DevOps, surge o conceito de “Monitoramento como Código”. O que quero dizer com isso é que um desenvolvedor/testador pode escrever um arquivo JSON simples que defina métricas de garantia de qualidade de software.
Vejamos um exemplo desse arquivo JSON. Objetos da API Dynatrace são usados como pares chave/valor (a descrição da API pode ser encontrada aqui ).
{
"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 arquivo é uma matriz de definições de série temporal:
- timeseriesId – a métrica que está sendo verificada, por exemplo, Tempo de Resposta, Contagem de erros, Memória utilizada, etc.;
- agregação - nível de agregação de métricas, no nosso caso média, mas você pode usar qualquer uma que precisar (média, mínimo, máximo, soma, contagem, percentil);
- tags – tag do objeto no sistema de monitoramento, ou você pode especificar um identificador de objeto específico;
- grave e aviso – esses indicadores regulam os valores limite de nossas métricas; se o valor do teste exceder o limite severo, nossa construção será marcada como malsucedida.
A figura a seguir mostra um exemplo do uso de tais limites.
Etapa 3: Geração de Carga
Depois de determinarmos os níveis de qualidade do nosso serviço, precisamos gerar uma carga de teste. Você pode usar qualquer uma das ferramentas de teste com as quais se sinta confortável, como Jmeter, Selenium, Neotys, Gatling, etc.
O sistema de monitoramento da Dynatrace permite capturar vários metadados de seus testes e reconhecer quais testes pertencem a qual ciclo de lançamento e qual serviço. Recomenda-se adicionar cabeçalhos adicionais às solicitações de teste HTTP.
A figura a seguir mostra um exemplo onde, utilizando o cabeçalho adicional X-Dynatrace-Test, indicamos que este teste se refere a testar a operação de adição de um item ao carrinho.
Ao executar cada teste de carga, você envia informações contextuais adicionais para Dynatrace usando a API de eventos do servidor CI/CD. Desta forma, o sistema pode diferenciar entre diferentes testes.
. Evento no sistema de monitoramento sobre o início do teste de carga
Etapa 4-5. Colete dados de desempenho e transfira dados para o sistema CI/CD
Juntamente com o teste gerado, é transmitido ao sistema de monitoramento um evento sobre a necessidade de coleta de dados para verificação dos indicadores de qualidade do serviço. Ele também especifica nosso arquivo JSON, que define as principais métricas.
Evento sobre necessidade de verificação da qualidade do software gerado no servidor CI/CD para envio ao sistema de monitoramento
Em nosso exemplo, o evento de verificação de qualidade é chamado perfSigDynatraceReport (Desempenho_Assinatura) - isso está pronto para integração com Jenkins, que foi desenvolvido pela equipe da T-Systems Multimedia Solutions. Cada evento de lançamento de teste contém informações sobre o serviço, número de compilação e tempo de teste. O plugin coleta valores de desempenho no momento da construção, avalia-os e compara o resultado com compilações anteriores e requisitos não funcionais.
Evento no sistema de monitoramento sobre o início de uma verificação de qualidade de construção.
Após a conclusão do teste, todas as métricas de avaliação da qualidade do software são transferidas de volta para um sistema de integração contínua, por exemplo, Jenkins, que gera um relatório sobre os resultados.
O resultado das estatísticas sobre assemblies no servidor de CI/CD.
Para cada construção individual, vemos estatísticas para cada métrica que definimos durante todo o teste. Também vemos se houve violações em determinados valores de limite (aviso e thrashholds severos). Com base em métricas agregadas, todo o build é marcado como estável, instável ou com falha. Além disso, por conveniência, você pode adicionar indicadores ao relatório comparando a construção atual com a anterior.
Visualize estatísticas detalhadas sobre assemblies no servidor CI/CD.
Comparação detalhada de duas montagens
Se necessário, você pode acessar a interface do Dynatrace e visualizar as estatísticas de cada uma de suas construções com mais detalhes e compará-las entre si.
Comparação de estatísticas de construção no Dynatrace.
Descobertas
Como resultado, obtemos um serviço de “monitoramento como serviço”, automatizado no pipeline de integração contínua. O desenvolvedor ou testador só precisa definir uma lista de métricas em um arquivo JSON e todo o resto acontece automaticamente. Recebemos controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquiteturais.
Tarefa 2. Automação do controle de qualidade de software em ambiente de produção
Assim, resolvemos o problema de como automatizar o processo de monitoramento na fase de testes no Pipeline. Desta forma minimizamos a percentagem de montagens de baixa qualidade que chegam ao ambiente de produção.
Mas o que fazer se um software ruim acabar sendo vendido ou se algo quebrar. Para uma utopia, queríamos mecanismos que detectassem automaticamente os problemas e, se possível, que o próprio sistema restaurasse a sua funcionalidade, pelo menos à noite.
Para fazer isso, precisamos, por analogia com a seção anterior, fornecer verificações automáticas de qualidade de software no ambiente de produção e baseá-las em cenários de autocorreção do sistema.
Correção automática como código
A maioria das empresas já possui uma base de conhecimento acumulada de vários tipos de problemas comuns e uma lista de ações para corrigi-los, por exemplo, reiniciar processos, limpar recursos, reverter versões, restaurar alterações de configuração inválidas, aumentar ou diminuir o número de componentes em o cluster, trocando o contorno azul ou verde e etc.
Embora esses casos de uso sejam conhecidos há anos por muitas das equipes com quem converso, poucos pensaram ou investiram em automatizá-los.
Se você pensar bem, não há nada muito complicado na implementação de processos para autocorreção do desempenho de aplicativos; você precisa apresentar os cenários de trabalho já conhecidos de seus administradores na forma de scripts de código (o conceito de “correção automática como código”). , que você escreveu antecipadamente para cada caso específico. Os scripts de reparo automático devem ter como objetivo eliminar a causa raiz do problema. Você mesmo determina as ações corretas para responder a um incidente.
Qualquer métrica do seu sistema de monitoramento pode funcionar como um gatilho para lançar o script, o principal é que essas métricas determinem com precisão que tudo está ruim, já que você não gostaria de obter falsos positivos em um ambiente produtivo.
Você pode usar qualquer sistema ou conjunto de sistemas: Prometheus, ELK Stack, Zabbix, etc. Mas darei alguns exemplos baseados em uma solução APM (o Dynatrace será novamente um exemplo) que também ajudarão a facilitar sua vida.
Em primeiro lugar, há tudo relacionado ao desempenho em termos de funcionamento da aplicação. A solução fornece centenas de métricas em vários níveis que você pode usar como gatilhos:
- nível do usuário (navegadores, aplicativos móveis, dispositivos IoT, comportamento do usuário, conversão, etc.);
- nível de serviço e operações (desempenho, disponibilidade, erros, etc.);
- nível de infraestrutura do aplicativo (métricas do sistema operacional host, JMX, MQ, servidor web, etc.);
- nível de plataforma (virtualização, nuvem, contêiner, etc.).
Monitorando níveis no Dynatrace.
Em segundo lugar, como disse anteriormente, o Dynatrace possui uma API aberta, o que facilita muito a integração com diversos sistemas de terceiros. Por exemplo, enviar uma notificação ao sistema de automação quando os parâmetros de controle forem excedidos.
Abaixo está um exemplo de interação com Ansible.
Abaixo darei alguns exemplos de que tipo de automação pode ser feita. Isso é apenas uma parte dos casos; a lista deles no seu ambiente pode ser limitada apenas pela sua imaginação e pelos recursos das suas ferramentas de monitoramento.
1. Implantação incorreta – reversão de versão
Mesmo que testemos tudo muito bem em um ambiente de teste, ainda há uma chance de que uma nova versão possa matar sua aplicação em um ambiente de produção. O mesmo fator humano não foi cancelado.
Na figura a seguir vemos que há um salto acentuado no tempo de execução das operações no serviço. O início deste salto coincide com o momento de implantação na aplicação. Transmitimos todas essas informações como eventos para o sistema de automação. Se o desempenho do serviço não voltar ao normal após o tempo que definimos, é chamado automaticamente um script que reverte a versão para a antiga.
Degradação do desempenho das operações após a implantação.
2. Carregamento de recursos em 100% - adicione um nó ao roteamento
No exemplo a seguir, o sistema de monitoramento determina que um dos componentes está com 100% de carga da CPU.
Carga da CPU 100%
Existem vários cenários diferentes possíveis para este evento. Por exemplo, o sistema de monitoramento verifica adicionalmente se a falta de recursos está associada ao aumento da carga do serviço. Nesse caso, é executado um script que adiciona automaticamente um nó ao roteamento, restaurando assim a funcionalidade do sistema como um todo.
Dimensionamento após um incidente
3. Falta de espaço no disco rígido - limpeza de disco
Acho que muita gente já automatizou esses processos. Usando o APM, você também pode monitorar o espaço livre no subsistema de disco. Se não houver espaço ou o disco estiver lento, chamamos um script para limpá-lo ou adicionar espaço.
Carga do disco 100%
4. Baixa atividade do usuário ou baixa conversão – alternar entre ramos azul e verde
Muitas vezes vejo clientes usando dois loops (implantação azul-verde) para aplicativos em um ambiente de produção. Isso permite que você alterne rapidamente entre filiais ao entregar novos lançamentos. Muitas vezes, após a implantação, podem ocorrer mudanças drásticas que não são imediatamente perceptíveis. Neste caso, a degradação no desempenho e na disponibilidade pode não ser observada. Para responder rapidamente a essas mudanças, é melhor usar várias métricas que reflitam o comportamento do usuário (número de sessões e ações do usuário, conversão, taxa de rejeição). A figura a seguir mostra um exemplo em que, quando as taxas de conversão caem, ocorre a alternância entre ramificações de software.
A taxa de conversão cai após alternar entre filiais de software.
Mecanismos para detecção automática de problemas
Por fim, darei mais um exemplo de porque gosto mais do Dynatrace.
Na parte da minha história sobre como automatizar verificações de qualidade de montagens em um ambiente de teste, determinamos todos os valores limite manualmente. Isso é normal para um ambiente de teste; o próprio testador determina os indicadores antes de cada teste, dependendo da carga. Num ambiente de produção, é desejável que os problemas sejam detectados automaticamente, tendo em conta vários mecanismos de base.
Dynatrace possui interessantes ferramentas de inteligência artificial integradas que, com base em mecanismos de determinação de métricas anômalas (baselining) e construção de um mapa de interação entre todos os componentes, comparando e correlacionando eventos entre si, determinam anomalias no funcionamento do seu serviço e fornecem informações detalhadas informações sobre cada problema e causa raiz.
Ao analisar automaticamente as dependências entre componentes, o Dynatrace determina não apenas se o serviço problemático é a causa raiz, mas também sua dependência de outros serviços. No exemplo abaixo, a Dynatrace monitora e avalia automaticamente a integridade de cada serviço na execução da transação, identificando o serviço Golang como a causa raiz.
Um exemplo de determinação da causa raiz de uma falha.
A figura a seguir mostra o processo de monitoramento de problemas com seu aplicativo desde o início de um incidente.
Visualização de um problema emergente com exibição de todos os componentes e eventos neles
O sistema de monitoramento coletou uma cronologia completa dos acontecimentos relacionados ao problema surgido. Na janela abaixo da linha do tempo vemos todos os principais eventos de cada um dos componentes. Com base nesses eventos, você pode definir procedimentos para correção automática na forma de scripts de código.
Além disso, aconselho a integrar um sistema de monitoramento com Service Desk ou um bug tracker. Quando ocorre um problema, os desenvolvedores recebem rapidamente informações completas para analisá-las no nível do código no ambiente de produção.
Conclusão
Como resultado, acabamos com um pipeline de CI/CD com verificações automatizadas de qualidade de software integradas no Pipeline. Minimizamos o número de montagens de baixa qualidade, aumentamos a confiabilidade do sistema como um todo e, se nosso sistema ainda falhar, lançamos mecanismos para restaurá-lo.
Definitivamente, vale a pena investir esforços para automatizar o monitoramento da qualidade do software; nem sempre é um processo rápido, mas com o tempo dará frutos. Recomendo que após resolver um novo incidente no ambiente de produção, você pense imediatamente em quais monitores adicionar para verificações no ambiente de teste, a fim de evitar que uma construção ruim entre em produção, e também crie um script para corrigir automaticamente esses problemas.
Espero que meus exemplos o ajudem em seus empreendimentos. Também terei interesse em ver seus exemplos de métricas usadas para implementar sistemas de autocura.
Fonte: habr.com