🚨 Plano de Recuperação de Desastres (DR) - CSuite

Versão: 1.0
Última Atualização: 2025-01-02
Responsável: Equipe de Operações CSuite

📋 Índice

Visão Geral
Objetivos de Recuperação (RTO/RPO)
Cenários de Desastre
Procedimentos de Recuperação
Backup e Restore
Failover Procedures
Testes e Validação
Contatos de Emergência

🎯 Visão Geral

Este documento define os procedimentos para recuperação do ecossistema CSuite em caso de desastre que resulte em perda parcial ou total de serviços, dados ou infraestrutura.

Escopo

Infraestrutura: Docker Swarm, Traefik Gateway, Serviços FastAPI
Dados: Schemas MySQL (csuite_*, context_*, core)
Aplicações: 15+ serviços CSuite
Monitoramento: Grafana, Kibana, Prometheus

Princípios

Minimizar RTO (Recovery Time Objective): Tempo máximo para restaurar serviços
Minimizar RPO (Recovery Point Objective): Perda máxima de dados aceitável
Priorização: Serviços críticos primeiro (Gateway, Context, Executive)
Documentação: Todos os passos devem ser documentados durante a recuperação

⏱️ Objetivos de Recuperação (RTO/RPO)

Serviços Críticos (Tier 1)

Serviço	RTO	RPO	Prioridade
csuite-gateway	15 min	0 min	🔴 Crítico
csuite-context	30 min	5 min	🔴 Crítico
csuite-executive	30 min	5 min	🔴 Crítico
MySQL (core)	1 hora	15 min	🔴 Crítico
MySQL (csuite_context)	1 hora	15 min	🔴 Crítico

Serviços Importantes (Tier 2)

Serviço	RTO	RPO	Prioridade
csuite-cfo-ops	2 horas	30 min	🟡 Importante
csuite-operations	2 horas	30 min	🟡 Importante
csuite-sales-manager	2 horas	30 min	🟡 Importante
MySQL (outros schemas)	2 horas	30 min	🟡 Importante

Serviços de Suporte (Tier 3)

Serviço	RTO	RPO	Prioridade
Grafana	4 horas	1 hora	🟢 Suporte
Kibana	4 horas	1 hora	🟢 Suporte
Prometheus	4 horas	1 hora	🟢 Suporte

🌋 Cenários de Desastre

Cenário 1: Perda Total de Servidor Principal

Descrição: Servidor principal inacessível (hardware failure, rede, datacenter)

Impacto:
- Todos os serviços CSuite offline
- Dados podem estar comprometidos
- Gateway inacessível

Ação Imediata:
1. Verificar status do servidor (ping, SSH)
2. Tentar acesso via console/ILO
3. Se inacessível por > 5 min, iniciar DR

Procedimento: Ver Seção 4.1

Cenário 2: Corrupção de Banco de Dados

Descrição: Corrupção detectada em schemas críticos

Impacto:
- Serviços podem estar rodando mas com dados inconsistentes
- Erros em queries críticas
- Possível perda parcial de dados

Ação Imediata:
1. Isolar schema afetado (read-only se possível)
2. Verificar extensão da corrupção
3. Decidir: restore completo ou parcial

Procedimento: Ver Seção 4.2

Cenário 3: Perda de Rede/DNS

Descrição: Problema de conectividade ou DNS

Impacto:
- Serviços podem estar rodando mas inacessíveis
- Gateway não resolve domínios
- Usuários não conseguem acessar

Ação Imediata:
1. Verificar conectividade de rede
2. Testar resolução DNS
3. Verificar configuração Traefik

Procedimento: Ver Seção 4.3

Cenário 4: Ataque/Segurança

Descrição: Comprometimento de segurança detectado

Impacto:
- Dados podem estar comprometidos
- Serviços podem estar sob controle de atacante
- Necessário isolamento imediato

Ação Imediata:
1. ISOLAR serviços afetados
2. Notificar equipe de segurança
3. Preservar evidências (logs, snapshots)
4. Não restaurar até investigação completa

Procedimento: Ver SECURITY_INCIDENT_RESPONSE.md

🔧 Procedimentos de Recuperação

4.1 Perda Total de Servidor

Pré-requisitos

✅ Backup recente de todos os schemas MySQL
✅ Configurações Docker Stack em repositório Git
✅ Secrets do Docker Swarm em local seguro
✅ Acesso a servidor secundário ou novo servidor

Passo a Passo

1. Provisionar Novo Servidor (se necessário)

# Configurar servidor com mesmo OS (Amazon Linux 2023)
# Instalar Docker e Docker Swarm
sudo yum install -y docker
sudo systemctl enable docker
sudo systemctl start docker
sudo docker swarm init

2. Restaurar Secrets do Docker Swarm

# Restaurar secrets de backup seguro
# Exemplo: mysql_password, jwt_secret, etc.
echo "SECRET_VALUE" | docker secret create mysql_password -

3. Restaurar Configurações

# Clonar repositório com docker-stack.yml
git clone <repo>
cd c-suite

# Verificar configurações
cat docker-stack.yml

4. Restaurar Bancos de Dados

# Ver seção 5.2 - Restore de Banco de Dados
# Restaurar schemas na ordem:
# 1. core
# 2. csuite_context
# 3. csuite_executive
# 4. Outros schemas

5. Deploy dos Serviços

# Deploy do stack
docker stack deploy -c docker-stack.yml csuite

# Verificar status
docker service ls
docker service ps csuite-gateway_csuite-gateway

6. Validação

# Testar gateway
curl https://csuite.internut.com.br/health

# Testar serviços críticos
curl https://csuite.internut.com.br/context/api/health
curl https://csuite.internut.com.br/executive/api/health

7. Atualizar DNS (se necessário)

# Se IP mudou, atualizar registros DNS
# Verificar propagação
dig csuite.internut.com.br

4.2 Corrupção de Banco de Dados

Detecção

Sintomas:
- Erros "Table is marked as crashed"
- Inconsistências em queries
- Checksum failures
- Serviços retornando erros 500

Verificação:

-- Verificar integridade de tabelas críticas
CHECK TABLE core_companies;
CHECK TABLE csuite_context.ctx_events;
CHECK TABLE csuite_executive.pg_decision_log;

-- Verificar logs de erro MySQL
SHOW ENGINE INNODB STATUS;

Procedimento de Restore

1. Isolar Schema Afetado

-- Se possível, tornar read-only
ALTER DATABASE csuite_context READ ONLY;

-- Ou parar serviços que usam o schema
docker service scale csuite-context_csuite-context=0

2. Identificar Último Backup Válido

# Listar backups disponíveis
ls -lh /backup/mysql/
# Verificar timestamp do backup
stat /backup/mysql/csuite_context_20250102_0300.sql.gz

3. Restaurar Schema

# Ver seção 5.2 - Restore de Banco de Dados
# Restaurar schema específico
mysql -u root -p csuite_context < /backup/mysql/csuite_context_20250102_0300.sql

4. Verificar Integridade

-- Verificar tabelas críticas
SELECT COUNT(*) FROM ctx_events;
SELECT COUNT(*) FROM ctx_policy_outcomes;

-- Verificar foreign keys
SELECT * FROM information_schema.TABLE_CONSTRAINTS 
WHERE TABLE_SCHEMA = 'csuite_context';

5. Reativar Serviços

docker service scale csuite-context_csuite-context=1

4.3 Perda de Rede/DNS

Verificação de Conectividade

# Testar conectividade básica
ping 8.8.8.8
ping csuite.internut.com.br

# Verificar DNS
nslookup csuite.internut.com.br
dig csuite.internut.com.br

# Verificar roteamento
traceroute csuite.internut.com.br

Procedimento

1. Verificar Status dos Serviços

# Serviços podem estar rodando
docker service ls
docker service ps csuite-gateway_csuite-gateway

2. Verificar Configuração Traefik

# Verificar labels do gateway
docker service inspect csuite-gateway_csuite-gateway | grep -A 10 Labels

# Verificar certificados SSL
docker secret ls | grep tls

3. Verificar Firewall/Security Groups

# Verificar regras de firewall
sudo iptables -L -n
# Verificar security groups (AWS)
aws ec2 describe-security-groups

4. Testar Acesso Interno

# Testar acesso direto ao container
docker exec -it $(docker ps -q -f name=csuite-gateway) curl localhost:8000/health

5. Restaurar Conectividade
- Atualizar DNS se necessário
- Ajustar firewall/security groups
- Verificar roteamento de rede
- Reiniciar Traefik se necessário

💾 Backup e Restore

5.1 Estratégia de Backup

MySQL - Backups Automáticos

Frequência:
- Schemas Críticos (core, csuite_context, csuite_executive): Diário às 03:00
- Outros Schemas: Diário às 04:00
- Retenção: 30 dias diários + 12 mensais

Script de Backup:

#!/bin/bash
# /usr/local/bin/backup_mysql.sh

DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/backup/mysql"
SCHEMA=$1

# Backup schema específico
mysqldump -u backup_user -p$BACKUP_PASSWORD \
  --single-transaction \
  --routines \
  --triggers \
  $SCHEMA | gzip > $BACKUP_DIR/${SCHEMA}_${DATE}.sql.gz

# Remover backups antigos (>30 dias)
find $BACKUP_DIR -name "${SCHEMA}_*.sql.gz" -mtime +30 -delete

Cron:

# Backup diário às 03:00
0 3 * * * /usr/local/bin/backup_mysql.sh core
0 3 * * * /usr/local/bin/backup_mysql.sh csuite_context
0 3 * * * /usr/local/bin/backup_mysql.sh csuite_executive

Docker Secrets

Backup:

# Exportar secrets (cuidado com segurança!)
docker secret ls
# Secrets devem estar em repositório seguro (Vault, AWS Secrets Manager)

Configurações Docker Stack

Backup:

# Configurações em Git
git add docker-stack.yml
git commit -m "Backup configuração $(date)"
git push

5.2 Restore de Banco de Dados

Restore Completo de Schema

# 1. Parar serviços que usam o schema
docker service scale csuite-context_csuite-context=0

# 2. Fazer backup atual (se possível)
mysqldump -u root -p csuite_context > /tmp/csuite_context_before_restore.sql

# 3. Dropar schema (CUIDADO!)
mysql -u root -p -e "DROP DATABASE IF EXISTS csuite_context;"

# 4. Recriar schema
mysql -u root -p -e "CREATE DATABASE csuite_context CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# 5. Restaurar backup
gunzip < /backup/mysql/csuite_context_20250102_0300.sql.gz | mysql -u root -p csuite_context

# 6. Verificar integridade
mysql -u root -p csuite_context -e "SHOW TABLES;"
mysql -u root -p csuite_context -e "SELECT COUNT(*) FROM ctx_events;"

# 7. Reativar serviços
docker service scale csuite-context_csuite-context=1

Restore Parcial (Tabela Específica)

# Extrair apenas tabela específica do backup
gunzip < /backup/mysql/csuite_context_20250102_0300.sql.gz | \
  sed -n '/^-- Table structure for table `ctx_events`/,/^-- Table structure for table/p' | \
  mysql -u root -p csuite_context

🔄 Failover Procedures

Failover de Servidor Principal

Quando usar:
- Servidor principal inacessível por > 15 minutos
- Hardware failure confirmado
- Manutenção planejada

Procedimento:
1. Provisionar servidor secundário (se não existir)
2. Restaurar backups
3. Atualizar DNS para apontar para novo servidor
4. Deploy dos serviços
5. Validação completa
6. Comunicar mudança aos stakeholders

✅ Testes e Validação

Teste de DR - Trimestral

Objetivo: Validar procedimentos e identificar gaps

Cenário de Teste:
1. Simular perda de servidor principal
2. Executar procedimento de DR
3. Medir RTO real vs. RTO objetivo
4. Validar integridade de dados (RPO)
5. Documentar lições aprendidas

Checklist de Validação:
- [ ] Gateway acessível
- [ ] Serviços críticos respondendo
- [ ] Dados consistentes
- [ ] Logs sendo gerados
- [ ] Monitoramento funcionando
- [ ] SSL/TLS válidos
- [ ] Autenticação funcionando

📞 Contatos de Emergência

Equipe de Operações

Função	Nome	Contato	Disponibilidade
On-Call Principal	-	-	24/7
Backup On-Call	-	-	24/7
DBA	-	-	Horário comercial
DevOps Lead	-	-	Horário comercial

Escalation Path

Nível 1: On-Call Principal (15 min)
Nível 2: DevOps Lead + DBA (30 min)
Nível 3: CTO/CIO (1 hora)

Canais de Comunicação

Slack: #csuite-ops-emergency
Email: ops-emergency@internut.com.br
Telefone: (verificar com equipe)

📝 Notas Importantes

Lições Aprendidas

Data: YYYY-MM-DD
Incidente: Descrição breve
Ações tomadas: Passos executados
Tempo de recuperação: RTO real
Melhorias identificadas: O que pode ser melhorado

Atualizações do Plano

Data: YYYY-MM-DD
Versão: X.X
Mudanças: Descrição das alterações
Aprovado por: Nome

🔗 Documentos Relacionados

BACKUP_DR.md - Detalhes de backup
SECURITY_INCIDENT_RESPONSE.md - Resposta a incidentes de segurança
RUNBOOKS_OPERACIONAIS.md - Runbooks operacionais
TROUBLESHOOTING.md - Guia de troubleshooting

Última Revisão: 2025-01-02
Próxima Revisão: 2025-04-02 (trimestral)