Desastres e recuperação: planejamento de contingência

1. Fundamentos do planejamento de contingência

O planejamento de contingência é o processo estruturado de preparação para eventos inesperados que podem interromper as operações normais de uma organização. Seu objetivo principal é garantir que, diante de um desastre, a empresa consiga responder de forma rápida e eficaz, minimizando perdas financeiras, danos à reputação e impactos operacionais.

É fundamental distinguir dois conceitos frequentemente confundidos:

  • Continuidade de negócios (BC): foco em manter as operações essenciais durante e após um incidente, mesmo que em capacidade reduzida.
  • Recuperação de desastres (DR): foco específico na restauração de sistemas de TI e dados após um evento crítico.

Os principais frameworks que orientam essas práticas incluem:
- ISO 22301 — padrão internacional para sistemas de gestão de continuidade de negócios
- NIST SP 800-34 — guia do NIST para planejamento de contingência em sistemas de TI
- ITIL — boas práticas para gerenciamento de serviços de TI

2. Identificação e classificação de cenários de desastre

Para planejar adequadamente, é necessário mapear os cenários possíveis e classificá-los por probabilidade e impacto:

Desastres naturais:
- Incêndios que podem destruir datacenters físicos
- Enchentes que comprometem infraestrutura elétrica e de rede
- Terremotos que afetam a integridade de servidores e cabeamento

Desastres tecnológicos:
- Falhas de hardware (discos, fontes, controladoras RAID)
- Corrupção de dados por bugs de software ou falhas de gravação
- Ataques cibernéticos como ransomware que criptografam dados críticos

Desastres humanos:
- Erros operacionais como exclusão acidental de bancos de dados
- Sabotagem interna por funcionários insatisfeitos
- Greves que paralisam equipes de operação

3. Análise de impacto nos negócios (BIA)

A Business Impact Analysis (BIA) é o processo de identificar e avaliar os efeitos potenciais de interrupções. Ela define duas métricas críticas:

RTO (Recovery Time Objective): 4 horas
- Tempo máximo aceitável para restaurar o sistema de ERP após um desastre
- Impacto financeiro estimado por hora de inatividade: R$ 50.000

RPO (Recovery Point Objective): 1 hora
- Perda máxima aceitável de dados (janela de backup)
- Backup de banco de dados a cada 60 minutos

Priorização de sistemas:
1. CRM (RTO: 2h, RPO: 15min) - Crítico para vendas
2. ERP (RTO: 4h, RPO: 1h) - Crítico para finanças
3. E-mail corporativo (RTO: 8h, RPO: 4h) - Importante
4. Sistema de RH (RTO: 24h, RPO: 24h) - Não crítico

O mapeamento de dependências ajuda a identificar quais sistemas precisam ser recuperados primeiro, considerando as interconexões entre eles.

4. Estratégias de backup e replicação

A regra 3-2-1 é o padrão ouro para backups:
- 3 cópias dos dados
- 2 mídias diferentes (ex: disco local + nuvem)
- 1 cópia offsite (geograficamente distante)

Exemplo de política de backup:

Backup incremental (a cada 1 hora):
- Arquivos modificados desde o último backup completo
- Armazenamento: storage local + nuvem (AWS S3)

Backup diferencial (a cada 24 horas):
- Todos os arquivos modificados desde o último backup completo
- Armazenamento: fita LTO-9 + nuvem (Azure Blob)

Backup completo (semanal):
- Cópia integral de todos os sistemas
- Armazenamento: datacenter secundário + nuvem (Google Cloud)

Replicação síncrona vs. assíncrona:
- Síncrona: dados escritos simultaneamente em ambos os locais (RPO = 0, maior latência)
- Assíncrona: dados replicados após confirmação local (RPO de segundos a minutos, menor latência)

Snapshots permitem pontos de restauração rápidos, enquanto backups incrementais e diferenciais otimizam espaço de armazenamento.

5. Arquiteturas de alta disponibilidade e failover

Duas abordagens principais para alta disponibilidade:

Arquitetura Active-Passive (Standby):
- Servidor primário processa todas as requisições
- Servidor secundário aguarda em hot standby
- Failover manual ou automático em 30-60 segundos
- Custo: 2x infraestrutura, recursos ociosos

Arquitetura Active-Active:
- Ambos os servidores processam requisições simultaneamente
- Balanceamento de carga distribui tráfego
- Failover transparente em milissegundos
- Custo: 1.5x infraestrutura, recursos utilizados

Soluções modernas incluem Disaster Recovery as a Service (DRaaS):

Provedor: AWS com região primária em São Paulo (sa-east-1)
Região secundária: Virginia do Norte (us-east-1)
Replicação: Banco de dados RDS com Multi-AZ
Failover: Automático via Route 53 health checks
RTO: 5 minutos | RPO: 10 segundos

Clustering (ex: Windows Failover Cluster, Kubernetes) oferece failover automático entre nós, enquanto balanceamento de carga distribui tráfego para evitar sobrecarga.

6. Plano de resposta imediata e comunicação

Um plano de resposta deve definir claramente:

Cadeia de comando:
1. Líder de incidentes (CIO ou diretor de TI)
2. Coordenador técnico (gerente de infraestrutura)
3. Equipe de resposta (analistas de rede, DBA, segurança)

Acionamento:
- Alerta automático via PagerDuty/Opsgenie
- War room virtual no Microsoft Teams/Slack
- Notificação em até 5 minutos após detecção

Procedimentos de contenção:
- Isolar sistemas comprometidos da rede
- Desativar contas de usuário suspeitas
- Iniciar restore a partir de backup íntegro
- Documentar cada ação em log centralizado

Canais de comunicação de emergência devem incluir:
- SMS e ligações automáticas para equipe crítica
- Canais dedicados no Slack/Teams para war room
- Página de status pública (ex: status.company.com)
- Modelos de e-mail pré-aprovados para stakeholders

7. Testes, manutenção e melhoria contínua

Um plano sem testes é apenas uma intenção. Os principais tipos de teste:

Teste Tabletop (trimestral):
- Reunião de 2 horas com equipe simulando cenário
- Exemplo: "Servidor de banco de dados corrompido às 14h"
- Avaliar: decisões, comunicação, tempo de resposta

Simulação (semestral):
- Ambiente de staging replica produção
- Executar failover completo sem impacto real
- Medir RTO e RPO reais vs. planejados

Failover Real (anual):
- Failover completo para ambiente secundário
- Operar por 4 horas no DR
- Failback documentado e cronometrado

Após cada teste ou desastre real, realize uma reunião de lições aprendidas:

O que funcionou bem:
- Backup em nuvem restaurou em 3 horas (RTO planejado: 4h)
- Comunicação via Slack foi eficiente

O que precisa melhorar:
- Documentação de senhas desatualizada
- Tempo de restore de banco foi maior que o esperado

Ações corretivas:
- Atualizar cofre de senhas até 15/04
- Otimizar índices do banco para reduzir restore em 30%

A frequência de revisão do plano deve ser:
- Anual: revisão completa com stakeholders
- Trimestral: atualização de contatos e procedimentos
- Após cada incidente: incorporar lições aprendidas

Referências