10 min leitura • Guide 777 of 877
Planejamento de Recuperação de Desastre
Espere pelo melhor, planeje pelo pior. O GitScrum ajuda as equipes a documentar procedimentos de recuperação, rastrear testes de DR e garantir a continuidade dos negócios.
Fundamentos do DR
Objetivos de Recuperação
DEFININDO ALVOS DE RECUPERAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TERMOS CHAVE: │
│ │
│ RTO (Objetivo de Tempo de Recuperação): │
│ Tempo máximo aceitável de inatividade │
│ "Devemos estar online novamente dentro de X horas" │
│ │
│ RPO (Objetivo de Ponto de Recuperação): │
│ Perda máxima aceitável de dados │
│ "Podemos perder no máximo X horas de dados" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLASSIFICAÇÃO DE SERVIÇO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Serviço Nível RTO RPO ││
│ │ ─────────────── ───── ────── ────── ││
│ │ API de Pagamento 1 15 min 0 (nenhum) ││
│ │ Banco de Usuários 1 30 min 5 min ││
│ │ App Principal 1 1 hora 1 hora ││
│ │ Analytics 2 4 horas 24 horas ││
│ │ Ambiente Dev 3 24 horas 1 semana ││
│ │ Armazenamento 3 48 horas N/A ││
│ │ ││
│ │ Nível 1: Crítico (prioridade imediata) ││
│ │ Nível 2: Importante (restaurar após Nível 1) ││
│ │ Nível 3: Não crítico (pode esperar) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CUSTO vs RTO: │
│ RTO mais curto = Infraestrutura mais cara │
│ Equilibre necessidades de negócio com orçamento │
└─────────────────────────────────────────────────────────────┘
Cenários de Desastre
PLANEJAMENTO DE CENÁRIOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CENÁRIOS DE DESASTRE COMUNS: │
│ │
│ INFRAESTRUTURA: │
│ • Indisponibilidade de região na nuvem │
│ • Falha no servidor de banco de dados │
│ • Perda de conectividade de rede │
│ • Falha no DNS │
│ │
│ DADOS: │
│ • Corrupção de banco de dados │
│ • Criptografia por ransomware │
│ • Exclusão acidental de dados │
│ • Falha no backup │
│ │
│ APLICAÇÃO: │
│ • Implantação ruim │
│ • Erro de configuração │
│ • Falha de dependência │
│ • Esgotamento de recursos │
│ │
│ SEGURANÇA: │
│ • Comprometimento de conta │
│ • Ataque DDoS │
│ • Violação de dados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PARA CADA CENÁRIO: │
│ • Detecção: Como saberemos? │
│ • Resposta: O que fazemos imediatamente? │
│ • Recuperação: Como restauramos o serviço? │
│ • Comunicação: Quem notificamos? │
│ • Pós-incidente: Como prevenimos recorrência? │
└─────────────────────────────────────────────────────────────┘
Documentação DR
Runbooks de Recuperação
ESTRUTURA DO RUNBOOK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RUNBOOK DE RECUPERAÇÃO DE BANCO DE DADOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-RUN-001: Recuperação de Banco de Dados Primário ││
│ │ ││
│ │ CENÁRIO: ││
│ │ Servidor de banco de dados primário indisponível ││
│ │ ││
│ │ DETECÇÃO: ││
│ │ • Alerta de monitoramento: Falhas de conexão DB ││
│ │ • Picos de erros na aplicação ││
│ │ • Falhas nos health checks ││
│ │ ││
│ │ AÇÕES IMEDIATAS (< 5 min): ││
│ │ 1. Verificar se DB está realmente down (não alarme falso)│
│ │ 2. Verificar página de status da nuvem ││
│ │ 3. Declarar incidente, iniciar comunicações ││
│ │ ││
│ │ OPÇÕES DE RECUPERAÇÃO: ││
│ │ ││
│ │ OPÇÃO A: Failover para réplica (RTO: 15 min) ││
│ │ 1. Promover réplica de leitura para primária ││
│ │ aws rds promote-read-replica --db-id prod-replica ││
│ │ 2. Atualizar string de conexão nos secrets ││
│ │ 3. Implantar aplicação com nova conexão ││
│ │ 4. Verificar conectividade ││
│ │ ││
│ │ OPÇÃO B: Restaurar do backup (RTO: 2 horas) ││
│ │ 1. Identificar backup bom mais recente ││
│ │ 2. Restaurar para nova instância ││
│ │ aws rds restore-db-instance-to-point-in-time ... ││
│ │ 3. Atualizar string de conexão ││
│ │ 4. Verificar integridade dos dados ││
│ │ ││
│ │ VERIFICAÇÃO: ││
│ │ ☐ Health checks da aplicação passando ││
│ │ ☐ Transações críticas funcionando ││
│ │ ☐ Monitoramento mostrando saudável ││
│ │ ││
│ │ CONTATOS: ││
│ │ DBA: @db-team (Slack), +1-555-DB-TEAM ││
│ │ Plantão: Escalação PagerDuty ││
│ │ Suporte AWS: Caso prioridade Crítica ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Rastreamento de Tarefas DR
TAREFAS DE DOCUMENTAÇÃO DR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ÉPICO DR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-001: Documentação de Recuperação de Desastre ││
│ │ ││
│ │ Meta: Cobertura DR completa para todos os sistemas Nível 1│
│ │ Prazo: Fim do Q2 ││
│ │ ││
│ │ RUNBOOKS: ││
│ │ ├── DR-RUN-001: Recuperação de banco de dados ✅ ││
│ │ ├── DR-RUN-002: Failover de aplicação ✅ ││
│ │ ├── DR-RUN-003: Failover CDN/DNS ⏳ ││
│ │ ├── DR-RUN-004: Recuperação de cache ⏳ ││
│ │ ├── DR-RUN-005: Recuperação de fila ☐ ││
│ │ └── DR-RUN-006: Fallback de terceiros ☐ ││
│ │ ││
│ │ DOCUMENTOS DE SUPORTE: ││
│ │ ├── DR-DOC-001: Lista de contatos ✅ ││
│ │ ├── DR-DOC-002: Templates de comunicação ⏳ ││
│ │ ├── DR-DOC-003: Mapa de dependências de serviço ✅ ││
│ │ └── DR-DOC-004: Log de verificação de backup ✅ ││
│ │ ││
│ │ TESTES: ││
│ │ ├── DR-TEST-001: Teste de failover de banco ✅ ││
│ │ ├── DR-TEST-002: Simulação DR completa (trimestral) ☐ ││
│ │ └── DR-TEST-003: Exercício de mesa ⏳ ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Testando DR
Tipos de Teste
ABORDAGENS DE TESTE DR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROGRESSÃO DE TESTE: │
│ │
│ REVISÃO DE DOCUMENTAÇÃO (Semanal): │
│ Verificar se runbooks estão atualizados │
│ Verificar se informações de contato estão atuais │
│ Baixo risco, baixo esforço │
│ │
│ VERIFICAÇÃO DE BACKUP (Semanal): │
│ Verificar se backups foram concluídos com sucesso │
│ Testar restauração para ambiente não produtivo │
│ Verificar integridade dos dados │
│ │
│ TESTE DE COMPONENTE (Mensal): │
│ Testar procedimentos de recuperação individuais │
│ Failover de banco de dados │
│ Reinício de aplicação │
│ │
│ EXERCÍCIO DE MESA (Mensal): │
│ Percorrer cenário sem tomar ação │
│ Identificar lacunas nos procedimentos │
│ Equipe discute "o que faríamos se..." │
│ │
│ SIMULAÇÃO DR PARCIAL (Trimestral): │
│ Executar procedimentos de recuperação de fato │
│ Testar em ambiente similar à produção │
│ Medir tempo real de recuperação │
│ │
│ SIMULAÇÃO DR COMPLETA (Anual): │
│ Simular desastre maior │
│ Recuperar todos os sistemas │
│ Validação de continuidade dos negócios │
└─────────────────────────────────────────────────────────────┘
Tarefa de Teste DR
EXECUÇÃO DE TESTE DR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIMULAÇÃO DR TRIMESTRAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-TEST-Q2: Simulação de Recuperação de Desastre Q2 ││
│ │ ││
│ │ Data: 15 de abril de 2024 (sábado, 6h) ││
│ │ Cenário: Região primária indisponível ││
│ │ Escopo: Todos os serviços Nível 1 ││
│ │ ││
│ │ OBJETIVOS: ││
│ │ ☐ Validar failover para região secundária ││
│ │ ☐ Medir RTO real vs alvo ││
│ │ ☐ Verificar integridade dos dados pós-failover ││
│ │ ☐ Testar procedimentos de comunicação ││
│ │ ││
│ │ CRONOGRAMA: ││
│ │ 06:00 - Início da simulação, simular indisponibilidade ││
│ │ 06:05 - Detecção e declaração de incidente ││
│ │ 06:15 - Iniciar procedimentos de failover ││
│ │ 07:30 - Alvo: Todos os serviços restaurados ││
│ │ 08:00 - Verificação e encerramento ││
│ │ 08:30 - Fim da simulação, iniciar failback ││
│ │ ││
│ │ PARTICIPANTES: ││
│ │ • Equipe de plantão ││
│ │ • Líder SRE (observador) ││
│ │ • Gerenciamento (prática de comunicação) ││
│ │ ││
│ │ CRITÉRIOS DE SUCESSO: ││
│ │ • RTO cumprido para todos os serviços Nível 1 ││
│ │ • Sem perda de dados além do RPO ││
│ │ • Comunicação enviada dentro de 10 min ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PÓS-SIMULAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-TEST-Q2-RETRO: Retrospectiva da Simulação ││
│ │ ││
│ │ RESULTADOS: ││
│ │ RTO Alvo: 90 min | Real: 85 min ✅ ││
│ │ RPO Alvo: 5 min | Real: 3 min ✅ ││
│ │ ││
│ │ O QUE FOI BEM: ││
│ │ • Runbooks estavam precisos ││
│ │ • Coordenação da equipe foi suave ││
│ │ • Failover concluído mais rápido que o esperado ││
│ │ ││
│ │ O QUE PRECISA MELHORAR: ││
│ │ • Template de comunicação tinha canal Slack errado ││
│ │ • Aquecimento de cache levou mais tempo que documentado ││
│ │ ││
│ │ ITENS DE AÇÃO: ││
│ │ ☐ Atualizar template de comunicação ││
│ │ ☐ Adicionar pré-aquecimento de cache ao runbook ││
│ │ ☐ Agendar próxima simulação para Q3 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Comunicação
Comunicação de Incidente
COMUNICAÇÃO DE DESASTRE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANO DE COMUNICAÇÃO: │
│ │
│ INTERNA (Imediata): │
│ • Canal Slack #incident │
│ • Escalação PagerDuty │
│ • Email para liderança │
│ │
│ EXTERNA (Dentro de 15 min): │
│ • Atualização da página de status │
│ • Reconhecimento no Twitter/redes sociais │
│ • Reunião com suporte ao cliente │
│ │
│ CONTÍNUA (A cada 30 min durante incidente): │
│ • Atualizações da página de status │
│ • Atualizações Slack internas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TEMPLATES DE COMUNICAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ NOTIFICAÇÃO INICIAL: ││
│ │ ││
│ │ Assunto: [INCIDENTE] Interrupção de Serviço ││
│ │ ││
│ │ Estamos atualmente enfrentando problemas de serviço. ││
│ │ Impacto: [descrever impacto do usuário] ││
│ │ Status: Investigando ││
│ │ Próxima atualização: 30 minutos ││
│ │ ││
│ │ ───────────────────────────────────────────────────── ││
│ │ ││
│ │ ATUALIZAÇÃO: ││
│ │ ││
│ │ Identificamos o problema e estamos trabalhando na ││
│ │ restauração. ││
│ │ ETA: [estimativa de tempo] ││
│ │ Próxima atualização: 30 minutos ││
│ │ │
│ │ ───────────────────────────────────────────────────── ││
│ │ ││
│ │ RESOLUÇÃO: ││
│ │ ││
│ │ Serviço foi restaurado. Todos os sistemas operacionais.││
│ │ Duração: [X horas Y minutos] ││
│ │ Causa raiz: [breve descrição] ││
│ │ Post-mortem seguirá dentro de 48 horas. ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘