Chaos engineering: testando resiliência em produção controlada

1. Fundamentos do Chaos Engineering

1.1 Definição e princípios: do caos controlado à resiliência sistêmica

Chaos Engineering é a disciplina de experimentar em um sistema de software para construir confiança na capacidade do sistema de suportar condições turbulentas em produção. Diferentemente de testes convencionais, que verificam funcionalidades esperadas, o Chaos Engineering introduz intencionalmente falhas controladas para observar como o sistema se comporta sob estresse.

Os princípios fundamentais incluem:

  • Hipótese de resiliência: assumir que o sistema falhará de maneiras inesperadas
  • Experimentos em produção: testar no ambiente real, não em simulações
  • Minimização de impacto: controlar o "blast radius" para evitar danos generalizados
  • Automação e repetibilidade: experimentos devem ser reproduzíveis e auditáveis

1.2 Diferença entre testes tradicionais e experimentos de caos

Testes unitários e de integração verificam se o código funciona conforme especificado. Chaos Engineering testa se o sistema continua funcionando quando componentes falham.

Teste tradicional:
- Entrada: requisição HTTP válida
- Saída esperada: resposta 200 OK
- Ambiente: staging isolado

Experimento de caos:
- Entrada: derrubar 3 pods do serviço X
- Saída esperada: sistema mantém 99.9% de disponibilidade
- Ambiente: produção, com 1% do tráfego

1.3 O estado de hipótese

Todo experimento de caos começa com uma hipótese explícita:

"O sistema se comporta corretamente mesmo sob a falha de dois nós do cluster Kubernetes."

Essa hipótese define o "steady state" — o comportamento normal do sistema medido por métricas como latência, throughput e taxa de erros.

2. Planejamento de Experimentos de Caos

2.1 Definição de "steady state"

Antes de qualquer experimento, é necessário estabelecer uma linha de base:

Métricas de steady state (últimos 7 dias):
- Latência média: 45ms (p95: 120ms)
- Throughput: 2.500 req/s
- Taxa de erro: 0.02%
- Disponibilidade: 99.95%

2.2 Escolha de hipóteses e métricas de sucesso

Exemplo de hipótese bem definida:

Hipótese: "O serviço de pagamento mantém latência abaixo de 200ms
quando o banco de dados principal sofre latência adicional de 500ms"

Métricas de sucesso:
- Latência p95 do serviço de pagamento <= 200ms
- Taxa de erro do serviço <= 0.5%
- Nenhum timeout em cascata para serviços downstream

2.3 Zoneamento de impacto

O blast radius deve ser controlado rigorosamente:

Estratégia de zoneamento:
- Fase 1: 1% das requisições de teste
- Fase 2: 5% das requisições de um tenant específico
- Fase 3: 10% do tráfego total (após aprovação)
- Rollback automático se métricas de erro ultrapassarem 1%

3. Tipos de Falhas e Cenários Comuns

3.1 Falhas de infraestrutura

Cenário: "Derrubar um nó do cluster Kubernetes"
Comando (Litmus):
  - experimento: pod-delete
  - alvo: app=payment-service
  - duração: 60 segundos
  - intervalo: 30 segundos entre execuções

Observação esperada:
  - Kubernetes reschedule o pod em 15-20 segundos
  - Serviço mantém disponibilidade via outros réplicas
  - Conexões em andamento são redirecionadas

3.2 Falhas de rede

Cenário: "Injetar latência de 2000ms no serviço de autenticação"
Ferramenta: Chaos Mesh
Configuração:
  - target: auth-service:8080
  - latency: 2000ms
  - jitter: 100ms
  - duration: 120 segundos
  - correlation: 50%

Impacto esperado:
  - Timeout configurado em 1500ms deve falhar rapidamente
  - Circuit breaker deve abrir após 5 falhas consecutivas
  - Fallback para cache local deve ser ativado

3.3 Falhas de aplicação

Cenário: "Simular falha do banco de dados PostgreSQL"
Comando:
  - desconectar pool de conexões do serviço de catálogo
  - duração: 45 segundos
  - porcentagem de conexões afetadas: 30%

Comportamento esperado:
  - Pool de conexões deve esgotar
  - Retry com backoff exponencial deve ser ativado
  - Cache Redis deve servir dados em modo leitura
  - Logs de erro devem ser gerados com correlation ID

4. Ferramentas e Plataformas de Chaos Engineering

4.1 Ferramentas open-source

Chaos Monkey (Netflix):
  - Foco: instâncias EC2
  - Integração: Spinnaker
  - Uso: derrubar instâncias aleatórias em horário comercial

Litmus (OpenEBS/CNCF):
  - Foco: Kubernetes
  - Workflows: CRDs do Kubernetes
  - Exemplo: pod-delete, node-cpu-hog, network-loss

Chaos Mesh (PingCAP):
  - Foco: Kubernetes
  - Tipos: DNS error, HTTP fault, IO fault
  - Dashboard: UI para gerenciamento de experimentos

4.2 Plataformas gerenciadas

Gremlin:
  - Ataques: CPU, memória, blackhole, DNS, latency
  - Recursos: blast radius, halt on failure, scheduling
  - Integração: PagerDuty, Datadog, Slack

AWS Fault Injection Simulator (FIS):
  - Foco: AWS services (EC2, RDS, ECS, EKS)
  - Templates: pré-definidos para cenários comuns
  - Controle: IAM roles, CloudWatch alarms, SNS notifications

4.3 Integração com CI/CD

Pipeline de experimento automatizado:
1. Build da aplicação
2. Deploy em staging
3. Executar experimento de caos (Litmus)
4. Coletar métricas (Prometheus)
5. Validar hipótese (Grafana + alertas)
6. Se aprovado: deploy em produção
7. Em produção: experimento com 1% do tráfego
8. Monitorar por 15 minutos
9. Rollback automático se anomalias detectadas

5. Execução Controlada em Produção

5.1 Estratégias de rollout gradual

Fase 1 - Staging:
  - Ambiente isolado, dados sintéticos
  - Executar experimentos destrutivos (derrubar banco inteiro)
  - Validar circuit breakers e retries

Fase 2 - Produção (1%):
  - Apenas tráfego de teste ou usuários internos
  - Falhas leves: latência de 100ms, perda de 5% dos pacotes
  - Monitoramento em tempo real com alertas

Fase 3 - Produção (10%):
  - Usuários reais, mas com feature flags
  - Falhas moderadas: derrubar 2 pods, latência de 500ms
  - Kill switch automático se métricas de erro > 1%

Fase 4 - Produção (100%):
  - Cenários completos de falha
  - Duração limitada (60 segundos máx)
  - Aprovação de SRE e gerência de produto

5.2 Mecanismos de rollback automático

Kill switch implementado:
if (error_rate > 1.0) {
    halt_experiment()
    send_alert("Chaos experiment halted: error rate exceeded")
    restore_steady_state()
    log_experiment_result("FAILED")
}

Rollback automático:
- CloudWatch Alarm dispara
- Lambda function executa rollback
- Experimentos são interrompidos imediatamente
- Sistema retorna à configuração anterior

5.3 Monitoramento em tempo real

Dashboard de experimento:
- Latência p50, p95, p99
- Throughput (req/s)
- Taxa de erro (4xx, 5xx)
- Uso de CPU/memória dos serviços afetados
- Estado dos circuit breakers (aberto/fechado)
- Logs de erro em tempo real

Alertas configurados:
- Se latência > 2x steady state → warning
- Se taxa de erro > 0.5% → critical
- Se disponibilidade < 99.9% → halt experiment

6. Análise de Resultados e Ciclo de Melhoria

6.1 Coleta de evidências

Evidências coletadas após experimento:
1. Logs estruturados (JSON) com correlation ID
2. Métricas do Prometheus (latência, erros, throughput)
3. Traces distribuídos (Jaeger/Zipkin)
4. Eventos do Kubernetes (pod evictions, reschedules)
5. Estado dos circuit breakers antes/durante/depois

Relatório gerado:
- Hipótese testada
- Duração do experimento
- Métricas observadas vs esperadas
- Ações corretivas recomendadas
- Aprovação/liberação para produção

6.2 Validação da hipótese

Resultado do experimento "latência no banco de dados":

Hipótese: "Sistema mantém latência < 200ms com 500ms de latência no DB"

Métricas observadas:
- Latência média: 180ms ✓
- Taxa de erro: 0.3% ✓
- Throughput: 2.300 req/s (redução de 8%) ⚠️
- Circuit breaker: abriu 3 vezes, fechou após 2 segundos ✓

Conclusão: Hipótese validada, mas throughput precisa de ajuste

6.3 Ações corretivas

Ações recomendadas baseadas no experimento:

1. Ajustar timeouts:
   - Timeout do banco: 1500ms → 1000ms (fail fast)
   - Retry: 3 tentativas → 2 tentativas (evitar sobrecarga)

2. Melhorar circuit breaker:
   - Threshold de falhas: 5 → 3
   - Half-open timeout: 5s → 2s
   - Fallback: cache local com TTL de 30s

3. Escalar horizontalmente:
   - Mínimo de pods: 3 → 5
   - HPA: CPU 70% → 50%

4. Adicionar cache:
   - Cache Redis para consultas frequentes
   - TTL: 60 segundos
   - Invalidação por evento

7. Cultura Organizacional e Governança

7.1 Estabelecimento de cultura "fail fast, learn faster"

Práticas culturais:
- Experimentos são revisados por pares (SRE + dev)
- Resultados são compartilhados em reuniões semanais
- "Blame-free" post-mortems
- Gamificação: times que executam mais experimentos ganham reconhecimento

Métricas de maturidade:
- Número de experimentos por mês
- Tempo médio de recuperação (MTTR)
- Redução de incidentes em produção
- Cobertura de experimentos por serviço

7.2 Políticas de segurança e compliance

Políticas obrigatórias:
1. Aprovação de segurança para experimentos em produção
2. Dados sensíveis nunca são expostos em logs
3. Experimentos não afetam dados de usuários
4. Compliance com SOC2, GDPR, PCI-DSS
5. Auditoria de todos os experimentos executados

Checklist pré-experimento:
- [ ] Aprovação do time de segurança
- [ ] Dados anonimizados ou sintéticos
- [ ] Blast radius definido e aprovado
- [ ] Kill switch testado em staging
- [ ] Monitoramento configurado
- [ ] Equipe de plantão notificada

7.3 Integração com SRE e observabilidade

Fluxo de trabalho SRE:

1. Planejamento:
   - Revisão de incidentes recentes
   - Identificação de pontos fracos na arquitetura
   - Priorização de experimentos

2. Execução:
   - Experimentos durante horário de baixo tráfego
   - SRE de plantão acompanha em tempo real
   - Comunicação via Slack/PagerDuty

3. Análise:
   - Post-mortem com time de desenvolvimento
   - Atualização de runbooks
   - Melhoria de dashboards e alertas

4. Iteração:
   - Experimentos repetidos após correções
   - Métricas comparadas mês a mês
   - Relatório trimestral de resiliência

Referências