Seu sistema é resiliente até o dia em que o banco de dados pisca e o checkout inteiro cai. Chaos engineering testes existem exatamente para esse momento: em vez de esperar o acidente acontecer, você provoca a falha de propósito, com escopo controlado, e observa o que quebra. É como bater no painel do carro antes da viagem para ver se alguma peça solta. Só que o carro é sua arquitetura de microsserviços e o painel é o Kubernetes.
O que é chaos engineering, afinal?
A definição direta: chaos engineering é a prática de introduzir falhas controladas em um sistema para entender como ele se comporta sob estresse e revelar fraquezas antes que virem incidente em produção. A IBM descreve a engenharia do caos como a indução intencional e controlada de falhas no ambiente de produção ou pré-produção para entender o impacto real nos serviços. Não é sair derrubando servidor por esporte. É experimento com hipótese, métrica e rollback.
A diferença para um teste tradicional é o alvo. Teste unitário verifica se a função soma dois números. Chaos engineering verifica se o sistema inteiro sobrevive quando a rede fica lenta, o disco enche ou um nó do cluster morre no meio do pico de tráfego.
Por que testar falhas de propósito?
Porque falha silenciosa é pior que falha barulhenta. Um timeout mal configurado pode passar meses sem aparecer, até o dia em que a fila acumula, o retry vira avalanche e o sistema inteiro entra em colapso. Injetar a falha antes expõe esse comportamento com você olhando, não com o cliente reclamando no Twitter.
Tem um ganho secundário que quase ninguém menciona: chaos engineering força o time a documentar o que é "normal". Sem métrica de linha de base, você não sabe se o sistema está degradado ou apenas ocupado. O experimento obriga a definir o que é saúde.
Como começar sem quebrar tudo?
Comece pelo ambiente de staging, nunca pela produção no primeiro dia. Defina uma hipótese clara: "se eu derrubar uma instância do serviço de pagamento, o balanceador redireciona em menos de 5 segundos e nenhuma transação é perdida". Meça. Se a hipótese falhar, você achou um bug de graça.
Ferramentas como Chaos Monkey, Litmus e Gremlin automatizam a injeção de falhas, mas a ferramenta é o de menos. O que importa é o escopo: comece com uma instância, um serviço, um horário de baixo tráfego. Aumente o raio de ação só depois que o time souber reverter o experimento em segundos.
Chaos engineering só funciona em produção?
Não, mas é em produção que ele mostra o valor real. O ambiente de staging nunca replica fielmente o tráfego, a latência de rede ou o estado dos dados. A IBM cita justamente a indução em produção ou pré-produção como o cenário da engenharia do caos. A recomendação prática é: valide o experimento em staging, depois rode em produção com escopo reduzido e janela de observação.
O risco existe. Por isso todo experimento precisa de um botão de abortar. Se você não consegue parar a falha em menos de um minuto, o experimento é grande demais.
Quais falhas vale a pena injetar?
As que já aconteceram ou vão acontecer por estatística. Latência de rede, indisponibilidade de dependência externa, esgotamento de disco, queda de nó, erro de DNS, expiração de certificado. Cada uma dessas já derrubou alguma empresa grande, e provavelmente já roçou no seu sistema.
Um exemplo concreto: injetar 500ms de latência entre o frontend e a API de catálogo. Se a página trava, você tem um problema de timeout ou de carregamento síncrono. Se ela degrada com elegância, mostrando cache, você tem resiliência de verdade.
Chaos engineering é a mesma coisa que teste de carga?
Não. Teste de carga mede quanto tráfego o sistema aguenta antes de cair. Chaos engineering mede como o sistema se comporta quando uma peça falha, mesmo com tráfego normal. São perguntas diferentes. Você pode passar no teste de carga com mil usuários simultâneos e ainda assim cair porque o banco de dados perdeu a conexão por dois segundos.
Os dois se complementam. Carga estressa volume, caos estressa condição de falha.
Resumo em três linhas
Chaos engineering é injetar falhas controladas para descobrir fraquezas antes do cliente. Comece em staging, defina hipótese, meça e só depois vá para produção com escopo pequeno. O objetivo não é quebrar o sistema, é descobrir onde ele já está quebrado e ninguém percebeu.
FAQ
Chaos engineering pode ser feito em qualquer sistema?
Em teoria sim, mas faz mais sentido em sistemas distribuídos, com múltiplos serviços e dependências externas. Um monólito simples rodando em um servidor único tem pouco a ganhar. Quanto mais peças móveis, mais combinações de falha existem para testar.
Qual a diferença entre chaos engineering e teste de resiliência?
Teste de resiliência é o objetivo, chaos engineering é o método. Você quer saber se o sistema é resiliente, então injeta falhas para descobrir. Todo experimento de caos é um teste de resiliência, mas nem todo teste de resiliência usa injeção de falha.
Preciso de ferramenta paga para começar?
Não. Dá para começar com scripts simples que derrubam um container ou adicionam latência com tc no Linux. Ferramentas como Chaos Monkey e Litmus são open source. O que custa caro não é a ferramenta, é o tempo de engenharia para desenhar experimentos que façam sentido.
Chaos engineering substitui testes automatizados?
Não, e quem trata assim vai se arrepender. Teste unitário e de integração pegam erro de lógica. Chaos engineering pega erro de comportamento sob falha. São camadas diferentes. Pular os testes básicos para fazer caos é construir o terceiro andar sem alicerce.
Como convencer o time de que isso não é loucura?
Mostrando o primeiro bug que o experimento encontrou. Nada convence mais um tech lead do que descobrir, em staging, que o sistema perde transação quando uma instância cai. Depois disso, a discussão muda de "por que fazer" para "quando fazemos em produção".