# Testes caos microservices: guia passo a passo

> Testes de caos em microservices consistem em injetar falhas controladas para validar a resiliência do sistema antes que problemas atinjam o cliente. O processo envolve definir hipóteses, estabelecer limites de impacto e critérios de sucesso, permitindo identificar pontos fracos e corrigir falhas de forma proativa.

*Blog Sem Juízo · Novidades · 14 de setembro de 2026 · Zeca Maranhão*

Testes de caos em microservices não são sobre quebrar tudo, mas sobre descobrir o que quebra antes do cliente. Este guia mostra como estruturar o processo em etapas, com hipóteses, limites e critérios de sucesso.

Testes de caos em microservices não são sobre quebrar tudo, mas sobre descobrir o que quebra antes do cliente. A estrutura ideal combina hipóteses claras, ambiente controlado, injeção gradual de falhas e métricas de sucesso. Este guia apresenta um passo a passo para montar esse processo do zero, com pré-requisitos e armadilhas comuns.

Antes de começar, você precisa de: uma arquitetura de microservices minimamente observável (logs, métricas, traces), um ambiente de staging que replique produção em escala reduzida, e uma equipe com permissão para interromper o experimento a qualquer momento. Sem isso, o teste vira aposta.

## Passo 1: Defina a hipótese e o escopo do experimento

Toda experiência de caos começa com uma pergunta específica. Em vez de "vamos derrubar um pod e ver o que acontece", formule: "se o serviço de pagamento perder 30% dos pacotes de rede por 5 minutos, o checkout deve continuar respondendo em menos de 2 segundos e não deve perder transações".

A hipótese precisa ser falseável. Se o resultado for ambíguo, o teste não serve para nada. Escolha um único serviço ou um par de serviços interdependentes. O escopo inicial deve caber em uma reunião de 15 minutos para revisão.

**Dica:** escreva a hipótese em um documento compartilhado e cole o link no canal da equipe. Erro comum: testar o sistema inteiro na primeira rodada e não conseguir isolar a causa da falha.

## Passo 2: Escolha o ambiente e defina o raio de impacto

Produção é o ambiente mais realista, mas também o mais arriscado. Para a maioria das equipes, o caminho é começar em staging com dados sintéticos ou anonimizados. Só migre para produção depois de pelo menos três ciclos bem-sucedidos em staging.

O raio de impacto (blast radius) deve ser explícito: quantas instâncias, qual porcentagem de tráfego, qual região. Um bom ponto de partida é 1% do tráfego real ou um único pod em um cluster de teste. Aumente gradualmente, nunca dobre de uma vez.

**Erro comum:** esquecer de isolar o ambiente de caos do ambiente de desenvolvimento. Um experimento mal contido pode derrubar o CI/CD da equipe inteira.

## Passo 3: Prepare a instrumentação e as métricas de sucesso

Sem medição, o teste de caos é só um susto. Antes de injetar qualquer falha, defina as métricas que indicam sucesso: latência p95, taxa de erro, throughput, saturação de recursos. Elas devem estar visíveis em um dashboard em tempo real.

Use tracing distribuído para acompanhar a jornada de uma requisição entre serviços. Se o serviço A falha, você precisa saber se o serviço B degradou ou se recuperou sozinho. Em muitos casos, o teste revela que o circuito de fallback nunca foi acionado porque ninguém configurou o timeout corretamente.

**Dica:** crie um alerta específico para o experimento. Se a taxa de erro ultrapassar o limite definido, o teste deve ser abortado automaticamente. Erro comum: confiar apenas em métricas agregadas e perder o momento exato da falha.

## Passo 4: Injete a falha de forma controlada e gradual

Existem várias categorias de falha para testar em microservices: latência de rede, perda de pacotes, encerramento de pods, esgotamento de CPU ou memória, falha de DNS, indisponibilidade de um serviço externo. Comece pela mais simples e menos destrutiva: adicione 200 ms de latência entre dois serviços.

Ferramentas como Chaos Mesh, Litmus ou Gremlin permitem orquestrar esses cenários. A escolha depende do seu stack. O importante é que a injeção seja reversível e tenha um botão de pânico. Programe a duração do experimento (por exemplo, 5 minutos) e o tempo de recuperação.

**Erro comum:** injetar múltiplas falhas simultâneas na primeira rodada. Isso dificulta a análise e pode mascarar qual falha realmente derrubou o sistema. Uma falha por vez, sempre.

## Passo 5: Monitore, colete evidências e decida o próximo passo

Durante o experimento, acompanhe os dashboards e anote o comportamento observado. O sistema se recuperou sozinho? O tempo de resposta ficou dentro do aceitável? Houve perda de dados? A hipótese foi confirmada ou refutada?

Ao final, faça uma análise pós-experimento em até 24 horas. Registre o que funcionou, o que falhou e quais ajustes são necessários. Se a hipótese foi refutada, isso não é fracasso: é a descoberta de uma vulnerabilidade que você pode corrigir antes que um incidente real aconteça.

**Dica:** documente o experimento em um repositório versionado. Isso permite repetir o teste após correções e comparar resultados. Erro comum: não registrar as condições exatas (versão do serviço, configuração de rede) e não conseguir reproduzir o cenário depois.

## Passo 6: Automatize e integre ao ciclo de desenvolvimento

Depois de validar o processo manualmente, automatize os cenários mais críticos. Integre os testes de caos ao pipeline de CI/CD, mas com cuidado: eles não devem rodar em todo commit. Uma frequência semanal ou por release é suficiente para a maioria dos times.

Automatize também a coleta de métricas e a geração de relatórios. O objetivo é que qualquer engenheiro possa rodar um experimento sem depender de um especialista. Com o tempo, os testes de caos se tornam parte da cultura de resiliência, não um evento isolado.

**Erro comum:** automatizar antes de estabilizar o processo manual. Primeiro prove que o experimento faz sentido, depois escale.

## Checklist rápido do que foi feito

- Hipótese clara e falseável definida
- Ambiente controlado (staging ou produção com blast radius mínimo)
- Métricas de sucesso e alertas configurados
- Falha injetada de forma gradual e reversível
- Análise pós-experimento documentada
- Automação planejada para cenários críticos

## FAQ

### O que são testes de caos em microservices?

São experimentos que injetam falhas controladas (latência, erros, indisponibilidade) em serviços específicos para validar se o sistema como um todo mantém a resiliência. O foco não é quebrar, mas descobrir pontos fracos antes que usuários reais sejam afetados.

### Qual a diferença entre teste de caos e teste de carga?

Teste de carga mede o comportamento sob volume esperado ou pico de tráfego. Teste de caos mede a reação a falhas inesperadas, como um serviço fora do ar. Os dois se complementam: carga testa capacidade, caos testa resiliência.

### Posso fazer testes de caos em produção?

Sim, mas apenas após validar o processo em staging e com raio de impacto controlado. Comece com 1% do tráfego ou um único pod. Tenha um plano de aborto imediato e monitore métricas em tempo real. Produção é o ambiente mais realista, porém o mais arriscado.

### Quais ferramentas são usadas para testes de caos?

As mais citadas incluem Chaos Mesh, Litmus, Gremlin e AWS Fault Injection Simulator. A escolha depende do seu stack e do nível de automação desejado. Muitas equipes começam com scripts simples de latência antes de adotar uma plataforma completa.

### Com que frequência devo rodar testes de caos?

Não há um número universal. Para a maioria dos times, uma vez por semana ou a cada release é suficiente. O importante é que os experimentos sejam repetíveis e que os resultados alimentem melhorias contínuas na arquitetura.

### O que fazer se o teste de caos derrubar o sistema?

Isso é um resultado valioso: você encontrou uma falha antes do cliente. Aborte o experimento, colete evidências e priorize a correção. Depois, repita o teste para confirmar que a resiliência foi restaurada. O fracasso controlado é o objetivo.

---

Fonte (canonical): https://blogsemjuizo.com.br/novidades/testes-caos-microservices-guia-passo-a-passo/