Chaos engineering: como Netflix quebra coisas de propósito para ficar de pé

1. O que é Chaos Engineering e por que ele existe?

Chaos Engineering é a disciplina de experimentar em um sistema distribuído para construir confiança na sua capacidade de resistir a condições turbulentas em produção. Diferente de testes tradicionais que verificam se o sistema funciona quando tudo está certo, o chaos engineering testa o comportamento quando tudo dá errado.

A Netflix, pioneira nessa prática, percebeu que em uma arquitetura de microsserviços com milhões de requisições por segundo, falhas não são exceção — são regra. Servidores falham, redes congestionam, discos enchem, dependências externas caem. Em vez de tentar evitar todas as falhas (impossível), a Netflix decidiu antecipá-las de forma controlada.

A diferença fundamental entre teste de estresse tradicional e chaos engineering está na abordagem: testes tradicionais são reativos (esperam o sistema quebrar para consertar), enquanto chaos engineering é proativo (quebra o sistema intencionalmente para validar resiliência).

2. O princípio fundamental: quebrar antes de quebrar

O chaos engineering opera sobre três pilares:

Hipótese do estado estável: Antes de qualquer experimento, mede-se o comportamento normal do sistema — latência média, taxa de erros, throughput. A hipótese é que, mesmo com falhas injetadas, o sistema mantenha essas métricas dentro de limites aceitáveis.

Redução do raio de explosão: Experimentos são projetados com limites claros de impacto. Se algo der errado, o dano é contido. Por exemplo, derrubar uma instância de um serviço, não o serviço inteiro.

Cultura de blameless postmortem: Quando um experimento revela uma falha, a pergunta não é "quem causou isso?", mas "o que no sistema permitiu que isso acontecesse?". Isso incentiva times a experimentarem sem medo de retaliação.

3. Ferramentas e práticas da Netflix: o ecossistema Simian Army

A Netflix desenvolveu um conjunto de ferramentas conhecido como Simian Army, cada uma especializada em um tipo de falha:

  • Chaos Monkey: Desliga instâncias aleatórias em produção durante o horário comercial. Força o sistema a redistribuir carga sem impacto ao usuário.
  • Chaos Gorilla: Simula a falha completa de uma zona de disponibilidade da AWS.
  • Chaos Kong: Simula a falha de uma região inteira da AWS.
  • Latency Monkey: Injeta latência artificial nas chamadas entre serviços para testar timeouts e circuit breakers.
  • Conformity Monkey: Encontra instâncias que não seguem as melhores práticas de configuração e as desliga.
  • Security Monkey: Identifica vulnerabilidades de segurança e violações de política.

4. Como projetar experimentos de caos seguros e eficazes

Um experimento de chaos engineering segue etapas específicas:

Definição de hipóteses claras: A hipótese deve ser mensurável. Exemplo: "Se o serviço de recomendação falhar, o sistema deve continuar servindo vídeos em menos de 2 segundos, com taxa de erro inferior a 0,1%."

Estabelecimento do steady state: Coleta-se métricas de linha de base por pelo menos 15 minutos antes do experimento.

Execução controlada: Começa-se em ambientes não produtivos (staging, canary). Após validação, avança-se para produção com janelas de tempo restritas (ex: 10 minutos, 1% do tráfego).

Exemplo de hipótese documentada:

Experimento: Chaos Monkey no serviço de autenticação
Hipótese: Com 2 instâncias do serviço auth derrubadas aleatoriamente,
o sistema deve manter latência abaixo de 500ms e 0% de erro em
requisições de login.
Steady state: latência média 120ms, erro 0.02%
Duração: 10 minutos em produção (horário de baixo tráfego)
Rollback: parar experimento se latência ultrapassar 2s ou erro > 1%

5. Padrões de resiliência validados pelo Chaos Engineering

O chaos engineering expõe gaps em padrões de resiliência que muitas vezes existem apenas no papel:

Circuit breaker: Quando o Chaos Monkey derruba um serviço, o circuit breaker deve abrir e redirecionar requisições para um fallback. Sem chaos engineering, times descobrem que o circuit breaker estava mal configurado ou nem implementado.

Retry com backoff e jitter: Sem chaos, retries parecem funcionar. Com caos, descobre-se que todas as instâncias reiniciam ao mesmo tempo, criando uma tempestade de retry que derruba o banco de dados.

Bulkheads: Isolar recursos (como conexões de banco, threads, memória) por serviço. O caos revela quando um serviço problemático consome todos os recursos do pool compartilhado.

6. Estudo de caso real: Netflix e a falha do AWS S3 em 2017

Em 28 de fevereiro de 2017, o Amazon S3 na região US-EAST-1 sofreu uma degradação severa que afetou milhares de serviços. A Netflix, que dependia fortemente do S3 para armazenamento de ativos de streaming, foi impactada — mas não parou.

Graças ao Chaos Engineering, a Netflix já havia testado cenários de falha de região com o Chaos Kong. Quando o S3 começou a falhar, os sistemas automaticamente redirecionaram o tráfego para réplicas em outras regiões (US-WEST-2, EU-WEST-1). O failover foi transparente para a maioria dos usuários.

A lição aprendida foi dupla: primeiro, testar dependências externas (não apenas código próprio) é crucial. Segundo, a redundância geográfica precisa ser testada regularmente, não apenas documentada.

7. Implementando Chaos Engineering na sua organização (sem ser Netflix)

Você não precisa do orçamento da Netflix para começar. Ferramentas open source permitem implementar chaos engineering progressivamente:

  • Chaos Toolkit: Framework open source para definir experimentos como código. Suporta Kubernetes, AWS, Azure, GCP.
  • Litmus: Focado em Kubernetes, permite injetar falhas em pods, nós e clusters.
  • Gremlin: Plataforma comercial com free tier para experimentos básicos.

Passos iniciais práticos:

  1. Identifique serviços críticos: Qual serviço, se cair, derruba o sistema? Comece por ele.
  2. Defina hipóteses simples: "Se o banco de dados principal falhar, o cache Redis deve servir dados com latência < 100ms."
  3. Agende experimentos em horários de baixo tráfego: 3h da manhã de domingo é um bom começo.
  4. Automatize rollbacks: Todo experimento deve ter um kill switch.

Exemplo de experimento mínimo com Chaos Toolkit:

# experimento.yaml
steady-state-hypothesis:
  title: "Serviço responde em menos de 500ms"
  probes:
    - type: probe
      name: "latencia-normal"
      provider:
        type: http
        url: "https://api.minhaempresa.com/health"
      tolerance:
        - type: mean
          value: 500
method:
  - type: action
    name: "derrubar-instancia"
    provider:
      type: python
      module: chaosaws.ec2.actions
      func: stop_instance
      arguments:
        instance_ids: ["i-12345"]
        region: "us-east-1"
rollbacks:
  - type: action
    name: "restaurar-instancia"
    provider:
      type: python
      module: chaosaws.ec2.actions
      func: start_instance
      arguments:
        instance_ids: ["i-12345"]
        region: "us-east-1"

8. Limitações, riscos e o futuro da disciplina

Chaos Engineering não é bala de prata. Riscos reais incluem:

  • Experimentação mal projetada: Pode causar incidentes reais se o raio de explosão não for contido.
  • Sistemas sem redundância: Se você tem um único banco de dados sem réplica, caos vai quebrar tudo de verdade.
  • Custo operacional: Manter infraestrutura para experimentos e monitoramento requer investimento.

Quando não aplicar: sistemas com estado crítico sem replicação, sistemas legados sem documentação de dependências, ou organizações sem cultura de blameless postmortem.

O futuro do chaos engineering aponta para edge computing (testar falhas em dispositivos IoT com conectividade intermitente), sistemas serverless (como funções Lambda se comportam quando o provedor de nuvem tem latência) e machine learning (experimentos automatizados que aprendem quais falhas injetar baseados em incidentes passados).

A Netflix provou que quebrar coisas de propósito, de forma controlada e científica, é a melhor maneira de garantir que elas não quebrem quando realmente importa. Chaos Engineering não é sobre criar caos — é sobre domar o caos inevitável dos sistemas distribuídos.

Referências