Agora sobre o tema do hype DevOps. O transportador de integração e entrega contínuas de CI / CD é implementado por todos que desejam. Mas a maioria nem sempre presta a devida atenção em garantir a confiabilidade dos sistemas de informação em vários estágios do pipeline de CI / CD. Neste artigo, gostaria de falar sobre minha experiência na automação de verificações de qualidade de software e na implementação de possíveis cenários para sua “autocorreção”.

Fonte

Trabalho como engenheiro no departamento de gerenciamento de serviços de TI da LANIT-Integration . Minha área principal é a implementação de vários sistemas para monitorar o desempenho e a disponibilidade dos aplicativos. Costumo me comunicar com clientes de TI de diferentes segmentos de mercado em questões de monitoramento da qualidade de seus serviços de TI. A principal tarefa é minimizar o tempo do ciclo de liberação e aumentar a frequência da liberação. Isso, é claro, é tudo de bom: mais lançamentos - mais novos recursos - usuários mais satisfeitos - mais lucro. Mas, na realidade, nem sempre tudo acaba bem. A 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 problemas é a transferência de serviços do teste para a produção, o que não afeta o tempo de atividade e a interação do usuário com o aplicativo.

Com base nos resultados de inúmeras conversas com clientes, posso dizer que o controle de qualidade dos lançamentos, o problema da confiabilidade do aplicativo e a possibilidade de sua "autocorreção" (por exemplo, reversão para uma versão estável) em vários estágios do pipeline de CI / CD estão entre os tópicos mais interessantes e relevantes.


Recentemente, eu mesmo trabalhei no lado do cliente - no serviço de suporte a aplicativos bancários online. A arquitetura do nosso aplicativo usou um grande número de microsserviços auto-escritos. O mais triste é que nem todos os desenvolvedores lidaram com o alto ritmo de desenvolvimento, a qualidade de alguns microsserviços sofridos, o que deu origem a apelidos ridículos para eles e seus criadores. Havia histórias sobre de quais materiais esses produtos são feitos.

"Declaração do problema"

A alta frequência de lançamentos e um grande número de microsserviços dificultam o entendimento do aplicativo como um todo, tanto no estágio de teste quanto no 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 em um barril de pólvora e esperam que nada se quebre, embora, na fase de testes, todas as verificações tenham sido bem-sucedidas.

Há mais um ponto. Na fase de teste, a operacionalidade do software é verificada: a implementação das principais funções do aplicativo e a ausência de erros. As estimativas qualitativas de desempenho estão ausentes ou não levam em consideração todos os aspectos do aplicativo e da camada de integração. Algumas métricas podem não ser verificadas. Como resultado, quando ocorre uma falha em um ambiente produtivo, o departamento de suporte técnico descobre apenas 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 controle de qualidade de software em vários estágios do Pipeline de CI / CD, adicionar vários scripts para restaurar o sistema em caso de acidente. Lembre-se também de 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 é dividida em dois componentes:

• controle de qualidade de montagens na fase de teste (para automatizar o processo de captura de montagens abaixo do padrão);
• controle de qualidade de software no ambiente de produção (mecanismos automáticos de detecção de problemas e possíveis cenários de autocorreção).

Ferramenta para monitorar e coletar métricas

Para realizar as tarefas definidas, é necessário um sistema de monitoramento que possa detectar problemas e transferi-los para os sistemas de automação em vários estágios do pipeline de CI / CD. Além disso, um ponto positivo será se este sistema fornecer métricas úteis para várias equipes: desenvolvimento, teste, operação. E maravilhoso, se for para negócios.

Para coletar métricas, você pode usar uma combinação de sistemas diferentes (Prometheus, ELK Stack, Zabbix, etc.), mas, na minha opinião, as soluções APM ( Application Performance Monitoring ) são mais adequadas para essas tarefas, o que pode simplificar bastante sua vida.

Como parte do meu trabalho no serviço de acompanhantes, comecei a fazer um projeto semelhante usando a solução de classe APM da Dynatrace. Agora, trabalhando como integrador, conheço muito bem o mercado de sistemas de monitoramento. Minha opinião subjetiva: Dynatrace é mais adequado para essas tarefas.
A solução Dynatrace fornece uma exibição horizontal de cada operação do usuário com um profundo grau de detalhe 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ções: dos níveis de front-end de aplicativos da web e móveis, servidores de aplicativos de back-end, barramento de integração a uma chamada específica ao banco de dados.

Fonte Construção automática de todas as dependências entre os componentes do sistema

Fonte Detecção e construção automáticas de um caminho para uma operação de serviço

Lembre-se também de que precisamos nos integrar com várias ferramentas de automação. Aqui, a solução possui uma API conveniente que permite enviar e receber várias métricas e eventos.

Em seguida, passaremos a uma discussão mais detalhada sobre como resolver tarefas usando o sistema Dynatrace.

Tarefa 1. Automação do controle de qualidade de montagens na fase de teste

A primeira tarefa é encontrar problemas o mais cedo possível nos estágios do pipeline de entrega de aplicativos. Somente construções "boas" de código devem atingir o ambiente de produção. Para fazer isso, monitores adicionais devem ser incluídos no seu pipeline no estágio de teste para verificar a qualidade de seus serviços.



Vamos dar uma olhada nas etapas de como implementar isso e automatizar esse processo:

Fonte

A figura mostra o fluxo das etapas automatizadas de controle de qualidade de software:

1. implantação de um sistema de monitoramento (instalação de agentes);
2. definição de eventos de avaliação da qualidade do seu software (métricas e valores-limite) e sua transferência para o sistema de monitoramento;
3. testes de geração e desempenho de carga;
4. coletando dados de desempenho e disponibilidade em um sistema de monitoramento;
5. transferência de dados de teste com base em eventos de avaliação de qualidade de software do sistema de monitoramento para o sistema de CI / CD. Análise de montagem automática.

Etapa 1. Implemente um sistema de monitoramento

Você deve primeiro 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, instalado na instância do sistema operacional (Windows, Linux, AIX), detecta automaticamente seus serviços e começa a coletar dados de monitoramento neles. Você não precisa configurar um agente separadamente para cada processo. Uma situação semelhante será para plataformas de nuvem e contêineres. Ao mesmo tempo, você também pode automatizar a instalação de agentes. O Dynatrace se encaixa perfeitamente no conceito de "infraestrutura como código" ( Infraestrutura como código ou IaC ): existem scripts e instruções prontas para todas as plataformas populares. Incorpore o agente na configuração do seu serviço e, ao implantá-lo, você imediatamente obtém um novo serviço com um agente já em execução.

Etapa 2. Identifique seus eventos de avaliação de qualidade de software

Agora você precisa determinar a lista de serviços e operações de negócios. É importante considerar exatamente as operações do usuário críticas aos negócios para o seu serviço. Aqui, recomendo a consultoria com analistas de negócios e sistemas.

Em seguida, é necessário determinar quais métricas você deseja incluir na verificação para cada um dos níveis. Por exemplo, pode ser tempo de execução (com separação por média, mediana, percentil etc.), erros (lógico, serviço, infraestrutura etc.) e várias métricas de infraestrutura (heap de memória, coletor de lixo, contagem de encadeamentos, etc.).

Para automação e facilidade de uso, a equipe do DevOps apresenta o conceito de "Monitoramento como código". O que quero dizer com isso é que um desenvolvedor / testador pode escrever um arquivo JSON simples que define os indicadores de controle de qualidade de software.

Vejamos um exemplo de um arquivo JSON. Objetos da API Dynatrace são usados ​​como um par de chave / valor (consulte a API Dynatrace para obter uma descrição da 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    }  ] } 

O arquivo é uma matriz de definições de séries temporais:

• timeseriesId - métrica verificada, por exemplo, Tempo de resposta, Contagem de erros, Memória usada, etc;
• agregação - o nível de agregação de métricas, no nosso caso, méd, mas você pode usar o que precisar (méd, min, max, soma, contagem, percentil);
• tags - uma tag de objeto no sistema de monitoramento ou você pode especificar um identificador de objeto específico;
• grave e aviso - esses indicadores ajustam os valores limite de nossas métricas; se o valor dos testes exceder o limite grave, nossa montagem será marcada como sem êxito.

A figura a seguir mostra um exemplo do uso dessas lixeiras.

Fonte

Etapa 3. Geração de Carga

Depois de determinarmos os níveis de qualidade de nosso serviço, é necessário gerar uma carga de teste. Você pode usar qualquer uma das ferramentas de teste que são convenientes para você, por exemplo, Jmeter, Selenium, Neotys, Gatling, etc.

O sistema de monitoramento Dynatrace permite capturar vários metadados de seus testes e reconhecer qual teste está relacionado a qual ciclo de liberação e serviço. É recomendável adicionar cabeçalhos adicionais às solicitações HTTP de teste.

A figura a seguir mostra um exemplo em que, usando o cabeçalho opcional X-Dynatrace-Test, marcamos que esse teste se refere ao teste da operação de adição de um item ao carrinho.

Fonte

Ao executar cada teste de carga, você envia informações contextuais adicionais ao Dynatrace usando a API de eventos do servidor de CI / CD. Assim, o sistema pode distinguir entre diferentes testes entre si.

Fonte Evento no sistema de monitoramento sobre o lançamento do teste de carga

Etapa 4-5. Coletar dados de desempenho e transferir dados para um sistema de CI / CD

Juntamente com o teste gerado, um evento é transmitido ao sistema de monitoramento sobre a necessidade de coletar dados sobre a verificação de indicadores de qualidade de serviço. Nosso arquivo JSON também é indicado, no qual as principais métricas são definidas.

Um evento sobre a necessidade de verificar a qualidade do software gerado no servidor de CI / CD para enviar ao sistema de monitoramento

Em nosso exemplo, o evento de controle de qualidade é chamado perfSigDynatraceReport (Performance_Signature ) - este é um plug - in pronto para integração com o Jenkins, desenvolvido pelos profissionais da T-Systems Multimedia Solutions. Cada evento sobre o início do teste contém informações sobre o serviço, número da compilação e tempo de teste. O plug-in coleta valores de desempenho durante a montagem, avalia-os e compara o resultado com montagens anteriores e requisitos não funcionais.

Evento no sistema de monitoramento sobre o início do controle de qualidade da montagem. Fonte

Após a conclusão do teste, todas as métricas de avaliação da qualidade do software são transferidas de volta ao sistema de integração contínua, por exemplo, Jenkins, que gera um relatório sobre os resultados.

O resultado das estatísticas de montagem no servidor de CI / CD. Fonte

Para cada montagem individual, vemos estatísticas de cada métrica definida durante todo o teste. Também vemos se houve violações em determinados valores limite (avisos e limites severos). Com base nas métricas agregadas, toda a montagem é marcada como estável, instável ou com falha. Além disso, por conveniência, você pode adicionar indicadores para comparar a montagem atual com a anterior no relatório.

Visualize estatísticas detalhadas de montagem no servidor de CI / CD. Fonte

Comparação detalhada de duas montagens

Se necessário, você pode ir para a interface do Dynatrace, ver mais detalhadamente as estatísticas de cada uma de suas montagens e compará-las.

Comparação de estatísticas de montagem no Dynatrace. Fonte

Conclusões

Como resultado, obtemos o serviço "monitoramento como serviço", automatizado no pipeline de integração contínua. O desenvolvedor ou testador só precisa determinar a lista de métricas no arquivo JSON e tudo o mais acontece automaticamente. Temos 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 um ambiente de produção

Portanto, resolvemos o problema de como automatizar o processo de monitoramento no estágio de teste no Pipeline. Assim, minimizamos a porcentagem de montagens de baixa qualidade que atingem o ambiente alimentar.

Mas o que fazer se um software ruim ainda chegar ao ponto de venda, ou apenas algo quebrar. Para a utopia, queríamos ter mecanismos para detectar automaticamente problemas e, se possível, o próprio sistema restauraria sua capacidade de trabalho, pelo menos à noite.

Para fazer isso, por analogia com a seção anterior, fornecemos verificações automáticas de qualidade de software no ambiente de produção e criamos scripts para autocorreção do sistema sob eles.


Correção automática como código

A maioria das empresas já possui uma base de conhecimento acumulada em vários tipos de problemas comuns e uma lista de ações para corrigi-los, por exemplo, reiniciando processos, limpando recursos, revertendo versões, restaurando alterações incorretas na configuração, aumentando ou diminuindo o número de componentes em um cluster, alternando um contorno azul ou verde e outro

Apesar do fato de que muitas das equipes com as quais me comunico conhecem esses casos de uso há muitos anos, apenas algumas pensaram e investiram em sua automação.

Se você pensar bem, na implementação de processos para autocorreção da saúde do aplicativo, não há nada super complicado, você precisará apresentar os cenários de trabalho conhecidos de seus administradores na forma de scripts de código (o conceito de "autocorreção como código") que você escreveu previamente para cada caso específico. Os cenários de reparo automático devem abordar a causa raiz do problema. Você mesmo define as ações corretas de resposta a incidentes.

Qualquer métrica do seu sistema de monitoramento pode atuar como um gatilho para a execução de um script, o principal é que essas métricas determinem com precisão que tudo está ruim, já que eu 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 vou dar alguns exemplos baseados na solução APM (Dynatrace será novamente um exemplo), o que também ajudará a tornar sua vida mais fácil.

Em primeiro lugar, há tudo relacionado à operacionalidade em termos de aplicação. A solução fornece centenas de métricas em vários níveis que você pode usar como gatilhos:

• nível de usuário (navegadores, aplicativos móveis, dispositivos de 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 da web etc.);
• nível da plataforma (virtualização, nuvem, contêiner etc.).

Monitorando os níveis no Dynatrace. Fonte

Em segundo lugar, como eu disse anteriormente, o Dynatrace possui uma API aberta, o que torna muito conveniente integrá-lo a vários sistemas de terceiros. Por exemplo, enviando uma notificação ao sistema de automação quando os parâmetros de controle são excedidos.

Abaixo está um exemplo para interagir com o Ansible.

Fonte

Abaixo, darei alguns exemplos de exatamente qual automação pode ser feita. Isso é apenas parte dos casos; listá-los em seu ambiente pode ser limitado apenas pela sua imaginação e pelos recursos de suas ferramentas de monitoramento.

1. Implementação incorreta - reversão de versão

Mesmo que todos testemos muito bem em um ambiente de teste, ainda há uma chance de que uma nova versão possa matar seu aplicativo no ambiente de prod. O mesmo fator humano não foi cancelado.

Na próxima figura, vemos que há um salto acentuado no tempo de execução das operações no serviço. O início desse salto coincide com o tempo de implantação do aplicativo. Transferimos todas essas informações como eventos para o sistema de automação. Se a capacidade de manutenção do serviço não normalizar após o tempo especificado por nós expirar, um script será chamado automaticamente que reverte a versão para a versão anterior.

Degradação do desempenho após a implantação. Fonte

2. Recurso carregando em 100% - adicione um nó ao roteamento

No exemplo a seguir, o sistema de monitoramento determina que um dos componentes possui 100% de utilização da CPU.

Utilização da CPU 100%

Vários cenários diferentes são possíveis para este evento. Por exemplo, o sistema de monitoramento verifica adicionalmente se a falta de recursos está associada a um aumento na carga no serviço. Se sim, é executado um script que adiciona automaticamente o nó ao roteamento, restaurando assim o sistema como um todo.

Escalando nós após um incidente

3. Falta de espaço no disco rígido - Limpeza de disco

Eu acho que muitos desses processos já estão automatizados. Usando o APM, você também pode monitorar o espaço livre no subsistema de disco. Na ausência de espaço ou operação lenta do disco, chamamos o script para limpar ou adicionar espaço.


Carregamento de disco 100%

4. Baixa atividade do usuário ou baixa conversão - alterne entre os ramos azul e verde

Costumo encontrar clientes usando dois circuitos (implantação azul-verde) para aplicativos no 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 alterações importantes que não são percebidas imediatamente. No entanto, a degradação no desempenho e disponibilidade pode não ser observada. Para responder rapidamente a essas alterações, é melhor usar várias métricas que refletem 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 no qual, quando a conversão cai, ocorre a alternância entre ramificações de software.

Queda de conversão após alternar entre ramificações de software. Fonte

Mecanismos automáticos de determinação de problemas

No final, darei mais um exemplo, do qual gosto mais no Dynatrace.

Em parte da minha história sobre a automação do controle de qualidade da montagem em um ambiente de teste, determinamos todos os valores limite no modo manual. Isso é normal para um ambiente de teste, o próprio testador determina os indicadores antes de cada teste, dependendo da carga. No ambiente de produção, é desejável que os problemas sejam detectados automaticamente, levando em consideração os vários mecanismos da linha de base.

O Dynatrace possui interessantes ferramentas de inteligência artificial incorporadas que, baseadas nos mecanismos para determinar métricas anômalas (linha de base) e construir um mapa de interação entre todos os componentes, comparando e correlacionando eventos entre si, determinam anomalias no trabalho do seu serviço e fornecem informações detalhadas sobre cada problema e causa raiz.

Ao analisar automaticamente as dependências entre os componentes, o Dynatrace determina não apenas se o serviço problemático é a principal causa, mas também sua dependência de outros serviços. No exemplo abaixo, o Dynatrace monitora e avalia automaticamente a integridade de cada serviço como parte de uma transação, identifica o serviço Golang como o principal motivo.

Um exemplo de determinação da causa raiz de uma falha. Fonte

A figura a seguir mostra o processo de monitoramento de problemas com seu aplicativo desde o início do incidente.

Visualização de um problema emergente com a exibição de todos os componentes e eventos neles

O sistema de monitoramento compilou uma cronologia completa dos eventos sobre o problema. Na janela abaixo da linha do tempo, vemos todos os principais eventos em cada um dos componentes. Com base nesses eventos, você pode especificar procedimentos para correção automática na forma de scripts de código.

Além disso, aconselho a integrar o sistema de monitoramento ao Service Desk ou a um rastreador de erros. Se ocorrer um problema, os desenvolvedores recebem rapidamente informações completas para sua análise 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 de qualidade de software automatizadas integradas no Pipeline. Minimizamos o número de montagens de baixa qualidade, aumentamos a confiabilidade do sistema como um todo e, se ainda prejudicarmos o desempenho do sistema, lançamos mecanismos para restaurá-lo.


Definitivamente, vale a pena o esforço para automatizar o monitoramento da qualidade do software, nem sempre é um processo rápido, mas com o tempo ele dará frutos. Eu recomendo que, depois de resolver um novo incidente no ambiente do prod, pense imediatamente em quais monitores adicionar para verificações no ambiente de teste, a fim de evitar uma má construção no prod, e também crie um script para corrigir automaticamente esses problemas.

Espero que meus exemplos o ajudem em seus empreendimentos. Também será interessante para mim ver seus exemplos de métricas usadas para a implementação de sistemas de autocorreção.

Fonte