Resiliência Operacional

Chaos engineering, disaster recovery, backups, runbooks e práticas para manter o sistema funcionando diante de falhas.

O que é resiliência operacional?

A resiliência operacional é a capacidade de um sistema de continuar funcionando (ou se recuperar rapidamente) diante de falhas, erros e situações inesperadas. Não se trata de evitar as falhas — em sistemas distribuídos, as falhas são inevitáveis — mas de projetar o sistema para que as tolere.

A resiliência operacional abrange:

• Prevenção de falhas por meio de um design robusto
• Detecção rápida de problemas
• Recuperação automática ou assistida
• Aprendizado contínuo a partir dos incidentes

Chaos engineering

O chaos engineering é a prática de injetar falhas deliberadamente no sistema para verificar se ele consegue lidar com elas. A premissa é simples: se você não testa as falhas em um ambiente controlado, vai descobri-las em produção.

Princípios

1. Definir o estado estável: como o sistema se comporta quando funciona bem? (métricas, latência, error rate)
2. Formular uma hipótese: “Se o serviço X falhar, o sistema deveria se degradar de forma graciosa”
3. Injetar a falha: simular a condição de falha
4. Observar o impacto: o sistema se comportou como esperávamos?
5. Aprender e melhorar: documentar as descobertas e corrigir as fragilidades

Tipos de experimentos

• Encerrar instâncias: o que acontece se um pod morre repentinamente?
• Injetar latência: o que acontece se um serviço downstream responde lentamente?
• Simular erros de rede: o que acontece se a conexão entre serviços é perdida?
• Encher o disco: o que acontece se o armazenamento se esgota?
• Saturar CPU/memória: o que acontece sob pressão extrema de recursos?

Ferramentas

• Chaos Monkey (Netflix): encerra instâncias aleatoriamente em produção
• Litmus Chaos: framework de chaos engineering para Kubernetes
• Gremlin: plataforma comercial de chaos engineering
• Chaos Mesh: ferramenta open source para Kubernetes
• Toxiproxy: proxy para simular condições de rede adversas

Boas práticas

• Começar em ambientes de staging antes de produção
• Iniciar com experimentos pequenos e controlados
• Ter sempre um plano de rollback
• Envolver a equipe — o chaos engineering é um exercício de equipe
• Documentar cada experimento e seus resultados

Disaster recovery

O disaster recovery (DR) é o plano para recuperar o sistema diante de uma falha catastrófica: perda de um datacenter, corrupção massiva de dados ou um ataque de segurança.

Métricas-chave

• RTO (Recovery Time Objective): tempo máximo aceitável para restaurar o serviço
• RPO (Recovery Point Objective): quantidade máxima de dados que se pode perder (medida em tempo)

Plano de disaster recovery

1. Identificar sistemas críticos: quais serviços são essenciais para o negócio?
2. Definir RTO e RPO: para cada sistema crítico
3. Projetar a estratégia: backups, replicação, multirregião
4. Documentar o processo: passo a passo para a recuperação
5. Testar regularmente: um plano não testado é um plano que não funciona
6. Atualizar o plano: cada mudança na arquitetura pode afetar o DR

Backups

Os backups são a última linha de defesa contra a perda de dados.

Tipos de backup

• Full backup: cópia completa de todos os dados
• Incremental backup: apenas os dados que mudaram desde o último backup
• Differential backup: os dados que mudaram desde o último full backup

Regra 3-2-1

• 3 cópias dos dados
• 2 tipos de armazenamento diferentes
• 1 cópia offsite (em outra localização geográfica)

Boas práticas

• Automatizar: os backups manuais são esquecidos
• Verificar: testar regularmente se os backups podem ser restaurados
• Criptografar: os backups contêm dados sensíveis
• Retenção: definir políticas claras de por quanto tempo são conservados
• Monitorar: alertar se um backup falha

Exemplo de política de backups

Banco de dados principal:
- Full backup: diário às 02:00 UTC
- Incremental: a cada 1 hora
- Retenção: 30 dias para diários, 7 dias para incrementais
- Armazenamento: S3 com replicação cross-region
- Verificação: restauração automática semanal em ambiente de teste

Runbooks

Um runbook é um documento que descreve passo a passo como responder a um incidente ou realizar uma operação. É a diferença entre uma resposta caótica e uma resposta ordenada.

Estrutura de um runbook

1. Título e descrição: qual incidente ou operação cobre
2. Sintomas: como o problema é detectado (alertas, métricas, logs)
3. Impacto: o que é afetado e quão grave é
4. Diagnóstico: passos para confirmar a causa raiz
5. Resolução: passos exatos para resolver o problema
6. Verificação: como confirmar que o problema foi resolvido
7. Post-mortem: o que documentar após o incidente

Exemplo: runbook para alta latência em API

## Alta latência em API Gateway

### Síntomas
- Alerta: p99 latência > 2s durante 5 minutos
- Dashboard: gráfico de latência em vermelho

### Diagnóstico
1. Verificar métricas de CPU/memória dos pods
2. Revisar logs de erros recentes
3. Verificar latência de serviços downstream
4. Verificar conexões ao banco de dados

### Resolução
Se CPU > 90%:
  → Escalar horizontalmente: kubectl scale deployment api --replicas=X

Se DB connections saturadas:
  → Verificar connection pool settings
  → Reiniciar pods se houver connection leaks

Se serviço downstream lento:
  → Verificar health do serviço
  → Ativar circuit breaker se necessário

### Verificação
- Confirmar que p99 latência < 500ms
- Verificar que error rate < 0.1%
- Monitorar durante 15 minutos

Incident management

Processo de resposta a incidentes

1. Detecção: alertas automáticos ou report manual
2. Triagem: avaliar severidade e impacto
3. Comunicação: notificar os stakeholders
4. Investigação: diagnosticar a causa raiz
5. Mitigação: restaurar o serviço o quanto antes
6. Resolução: aplicar a correção definitiva
7. Post-mortem: documentar o que aconteceu, por quê e como preveni-lo

Níveis de severidade

Post-mortem blameless

Após cada incidente significativo, realizar um post-mortem sem culpados:

• O que aconteceu: cronologia detalhada do incidente
• Por que aconteceu: análise de causa raiz (5 whys)
• O que fizemos bem: o que funcionou na resposta
• O que podemos melhorar: ações concretas para prevenir a recorrência
• Action items: tarefas atribuídas com responsáveis e datas

Resumo

A resiliência operacional não é opcional em sistemas distribuídos. O chaos engineering valida que o sistema tolera falhas, o disaster recovery prepara para o pior, os backups protegem os dados, os runbooks guiam a resposta a incidentes e o incident management organiza a recuperação. A chave é praticar, documentar e melhorar continuamente.