Vire para a direita para testar na produção

Shift right é a prática de mover alguns testes mais tarde no processo de DevOps para testes em produção. Os testes em produção usam implantações reais para validar e medir o comportamento e o desempenho de um aplicativo no ambiente de produção.

Uma maneira de as equipes de DevOps melhorarem a velocidade é com uma estratégia de teste shift-left . Shift left empurra a maioria dos testes mais cedo no pipeline de DevOps, para reduzir a quantidade de tempo para que o novo código chegue à produção e opere de forma confiável.

Mas enquanto muitos tipos de testes, como testes de unidade, podem facilmente mudar para a esquerda, algumas classes de testes não podem ser executadas sem implantar parte ou toda uma solução. A implantação em um serviço de controle de qualidade ou de preparo pode simular um ambiente comparável, mas não há substituto completo para o ambiente de produção. As equipes descobrem que certos tipos de testes precisam acontecer na produção.

Os testes em produção fornecem:

• Toda a amplitude e diversidade do ambiente de produção.
• A carga de trabalho real do tráfego de clientes.
• Perfis e comportamentos à medida que a demanda de produção evolui ao longo do tempo.

O ambiente de produção continua a mudar. Mesmo que um aplicativo não mude, a infraestrutura na qual ele depende muda constantemente. Os testes em produção validam a integridade e a qualidade de uma determinada implantação de produção e do ambiente de produção em constante mudança.

Mudar o direito de testar na produção é especialmente importante para os seguintes cenários:

Implantações de microsserviços

As soluções baseadas em microsserviços podem ter um grande número de microsserviços que são desenvolvidos, implantados e gerenciados de forma independente. Mudar os testes para a direita é especialmente importante para esses projetos, porque diferentes versões e configurações podem chegar à produção de muitas maneiras. Independentemente da cobertura do teste de pré-produção, é necessário testar a compatibilidade na produção.

Garantir a qualidade pós-implantação

Liberar para produção é apenas metade da entrega de software. A outra metade é garantir qualidade em escala com uma carga de trabalho real na produção. Como o ambiente continua mudando, uma equipe nunca termina com testes na produção.

Os dados de teste da produção são literalmente os resultados do teste da carga de trabalho real do cliente. Os testes em produção incluem monitoramento, teste de failover e injeção de falhas. Esse teste rastreia falhas, exceções, métricas de desempenho e eventos de segurança. A telemetria de teste também ajuda a detetar anomalias.

Camadas de implantação

Para proteger o ambiente de produção, as equipes podem implementar alterações de forma progressiva e controlada usando implantações baseadas em camadas e sinalizadores de recursos. Por exemplo, é melhor detetar um bug que impeça um comprador de concluir sua compra quando menos de 1% dos clientes estiver nessa camada de implantação, do que depois de trocar todos os clientes de uma só vez. O valor do recurso com falhas detetadas deve exceder as perdas líquidas dessas falhas, medidas de forma significativa para o negócio em questão.

O primeiro nível deve ser o menor tamanho necessário para executar o pacote de integração padrão. Os testes podem ser semelhantes aos já executados anteriormente no pipeline em outros ambientes, mas o teste valida que o comportamento é o mesmo no ambiente de produção. Essa camada identifica erros óbvios, como configurações incorretas, antes que eles afetem quaisquer clientes.

Depois que a camada inicial for validada, a próxima camada poderá ser ampliada para incluir um subconjunto de usuários reais para a execução do teste. Se tudo parecer bom, a implantação poderá progredir por outras camadas e testes até que todos a estejam usando. A implantação completa não significa que os testes acabaram. A telemetria de rastreamento é extremamente importante para testes em produção.

Injeção por defeito

As equipes geralmente empregam injeção de falhas e engenharia de caos para ver como um sistema se comporta em condições de falha. Estas práticas ajudam a:

• Valide se os mecanismos de resiliência implementados realmente funcionam.
• Valide se uma falha em um subsistema está contida nesse subsistema e não ocorre em cascata para produzir uma grande interrupção.
• Prove que o trabalho de reparação de um incidente anterior tem o efeito desejado, sem ter que esperar que outro incidente ocorra.
• Crie exercícios de treinamento mais realistas para engenheiros de locais ao vivo, para que eles possam se preparar melhor para lidar com incidentes.

É uma boa prática automatizar experimentos de injeção de falhas, porque são testes caros que devem ser executados em sistemas em constante mudança.

A engenharia do caos pode ser uma ferramenta eficaz, mas deve ser limitada a ambientes canários que têm pouco ou nenhum impacto no cliente.

Teste de failover

Uma forma de injeção de falhas é o teste de failover para dar suporte à continuidade de negócios e à recuperação de desastres (BCDR). As equipes devem ter planos de failover para todos os serviços e subsistemas. Os planos devem incluir:

• Uma explicação clara do impacto comercial da queda do serviço.
• Um mapa de todas as dependências em termos de plataforma, tecnologia e pessoas que elaboram os planos BCDR.
• Documentação formal dos procedimentos de recuperação de desastres.
• Uma cadência para executar regularmente exercícios de recuperação de desastres.

Teste de falha do disjuntor

Um mecanismo de disjuntor corta um determinado componente de um sistema maior, geralmente para evitar que falhas nesse componente se espalhem para fora de seus limites. Você pode acionar intencionalmente disjuntores para testar os seguintes cenários:

• Se um fallback funciona quando o disjuntor abre. O fallback pode funcionar com testes de unidade, mas a única maneira de saber se ele se comportará como esperado na produção é injetar uma falha para acioná-lo.

• Se o disjuntor tem o limiar de sensibilidade certo para abrir quando necessário. A injeção de falhas pode forçar a latência ou desconectar dependências para observar a capacidade de resposta do disjuntor. É importante verificar não só se o comportamento correto ocorre, mas que ele acontece rapidamente o suficiente.

Exemplo: testando um disjuntor de cache Redis

O cache Redis melhora o desempenho do produto acelerando o acesso aos dados comumente usados. Considere um cenário que tenha uma dependência não crítica do Redis. Se o Redis ficar inativo, o sistema deve continuar a funcionar, porque pode voltar a usar a fonte de dados original para solicitações. Para confirmar se uma falha do Redis aciona um disjuntor e se o fallback funciona na produção, execute periodicamente testes contra esses comportamentos.

O diagrama a seguir mostra testes para o comportamento de fallback do disjuntor Redis. O objetivo é garantir que, quando o disjuntor abrir, as chamadas acabem indo para o SQL.

O diagrama anterior mostra três ATs, com os disjuntores na frente das chamadas para Redis. Um teste força o disjuntor a abrir através de uma alteração de configuração e, em seguida, observa se as chamadas vão para SQL. Outro teste então verifica a mudança de configuração oposta, fechando o disjuntor para confirmar que as chamadas retornam ao Redis.

Este teste valida que o comportamento de fallback funciona quando o disjuntor abre, mas não valida que a configuração do disjuntor abre o disjuntor quando deveria. Testar esse comportamento requer simular falhas reais.

Um agente de falha pode introduzir falhas em chamadas que vão para Redis. O diagrama a seguir mostra o teste com injeção de falha.

1. O injetor de falha bloqueia as solicitações Redis.
2. O disjuntor se abre e o teste pode observar se o fallback funciona.
3. A falha é removida e o disjuntor envia uma solicitação de teste para Redis.
4. Se a solicitação for bem-sucedida, as chamadas serão revertidas para Redis.

Outras etapas podem testar a sensibilidade do disjuntor, se o limiar é muito alto ou muito baixo, e se outros tempos limite do sistema interferem no comportamento do disjuntor.

Neste exemplo, se o disjuntor não abrir ou fechar conforme o esperado, poderá causar um incidente de site ativo (LSI). Sem o teste de injeção de falha, o problema pode passar despercebido, pois é difícil fazer esse tipo de teste em um ambiente de laboratório.

Próximos passos

• [Teste de deslocamento para a esquerda com testes de unidade]deslocar-esquerda
• O que são microsserviços?
• Executar um failover de teste (drill de recuperação de desastre) para o Azure
• Práticas de implantação seguras
• O que é a monitorização?
• O que é engenharia de plataformas?