Compartilhar via

Deslocar para a direita para testar em produção

Shift para a direita é a prática de mover alguns testes posteriormente no processo de DevOps para testar em produção. O teste em produção usa 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 . O shift para a esquerda pressiona a maioria dos testes anteriormente no pipeline de DevOps, para reduzir o tempo para que o novo código chegue à produção e opere de forma confiável.

Mas, embora muitos tipos de testes, como testes de unidade, possam 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 qa ou serviço de preparo pode simular um ambiente comparável, mas não há nenhum substituto completo para o ambiente de produção. As equipes acham que determinados tipos de teste precisam acontecer na produção.

O teste em produção fornece:

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

O ambiente de produção continua mudando. Mesmo que um aplicativo não mude, a infraestrutura que ele depende de alterações constantemente. O teste em produção valida a integridade e a qualidade de uma determinada implantação de produção e do ambiente de produção em constante alteração.

Mudar para a direita para testar em produção é especialmente importante para os seguintes cenários:

Implantações de microsserviços

Soluções baseadas em microsserviços podem ter um grande número de microsserviços desenvolvidos, implantados e gerenciados de forma independente. Mudar o teste para a direita é especialmente importante para esses projetos, pois diferentes versões e configurações podem alcançar a produção de várias maneiras. Independentemente da cobertura de teste de pré-produção, é necessário testar a compatibilidade na produção.

Garantindo a qualidade pós-implantação

A liberação para produção é apenas metade da entrega de software. A outra metade está garantindo a qualidade em escala com uma carga de trabalho real em produção. Como o ambiente continua mudando, uma equipe nunca é feita com testes em 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 falha. Esse teste rastreia falhas, exceções, métricas de desempenho e eventos de segurança. A telemetria de teste também ajuda a detectar 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 detectar um bug que impeça um comprador de concluir sua compra quando menos de 1% de clientes estiverem nessa camada de implantação do que depois de alternar todos os clientes de uma vez. O valor do recurso com falhas detectadas deve exceder as perdas líquidas dessas falhas, medidas de forma significativa para os negócios fornecidos.

A primeira camada 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 relação a 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 de afetarem os 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 bem, a implantação poderá progredir por outras camadas e testes até que todos estejam usando-a. A implantação completa não significa que o teste acabou. O acompanhamento da telemetria é extremamente importante para testes em produção.

Injeção de falha

As equipes geralmente empregam a injeção de falhas e a engenharia do caos para ver como um sistema se comporta em condições de falha. Essas 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 em cascata para produzir uma interrupção importante.
  • Prove que o trabalho de reparo de um incidente anterior tem o efeito desejado, sem precisar esperar que outro incidente ocorra.
  • Crie exercícios de treinamento mais realistas para engenheiros de site ao vivo para que eles possam se preparar melhor para lidar com incidentes.

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

A engenharia do Chaos 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 falha é o teste de failover para dar suporte à BCDR (continuidade dos negócios e recuperação de desastre). O Teams deve ter planos de failover para todos os serviços e subsistemas. Os planos devem incluir:

  • Uma explicação clara do impacto nos negócios do serviço que está caindo.
  • 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 desastre.
  • Uma cadência para executar regularmente os exercícios de recuperação de desastre.

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 fora de seus limites. Você pode disparar intencionalmente disjuntores para testar os seguintes cenários:

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

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

Exemplo: testando um disjuntor de cache Redis

O cache Redis melhora o desempenho do produto acelerando o acesso a dados comumente usados. Considere um cenário que usa uma dependência não crítica no Redis. Se o Redis falhar, o sistema deverá continuar funcionando, pois ele pode voltar a usar a fonte de dados original para solicitações. Para confirmar que uma falha do Redis dispara um disjuntor e que o fallback funciona em produção, execute periodicamente testes em relação a esses comportamentos.

O diagrama a seguir mostra testes para o comportamento de fallback do disjuntor redis. O objetivo é garantir que, quando o disjuntor for aberto, as chamadas finalmente vão para o SQL.

Diagrama mostrando testes para o disjuntor do Redis e o comportamento de fallback.

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

Esse teste valida se o comportamento de fallback funciona quando o disjuntor é aberto, mas não valida se 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.

Diagrama mostrando o teste do disjuntor redis com injeção de falha.

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

Outras etapas podem testar a sensibilidade do disjuntor, se o limite é 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 LSI (incidente de site dinâmico). Sem o teste de injeção de falha, o problema pode não ser detectado, pois é difícil fazer esse tipo de teste em um ambiente de laboratório.

Próximas etapas

  • Last updated on