Capítulo 47 — Continuidade de Negócio e Recuperação de Desastre

47.1 Objetivo do Capítulo

Este capítulo estabelece as diretrizes técnicas e operacionais para garantir a continuidade de operação da Plataforma de Relacionamento Digital com o Cidadão em cenários de falha, desastre ou indisponibilidade.

A continuidade de negócio não é um requisito técnico isolado — é a responsabilidade integrada de infraestrutura, backup, replicação, failover, disaster recovery plan, teste periódico e operação.

47.2 Conceitos Fundamentais

47.2.1 RTO — Recovery Time Objective

Tempo máximo aceitável entre a ocorrência de falha e a retomada de operação normal.

Exemplos:

• Portal web: RTO = 30 minutos (falha em uma AZ, failover automático)
• Processamento batch: RTO = 4 horas (reinício do job)
• Backup restauração: RTO = 24 horas (corrupção de dados)

RTO zero é impossível na prática. O objetivo é definir um RTO realista por serviço e dimensionar infraestrutura para atingi-lo.

47.2.2 RPO — Recovery Point Objective

Volume máximo de dados aceitável perder em caso de desastre.

Exemplos:

• Transações operacionais: RPO = 5 minutos (backup incremental a cada 5 min)
• Solicitações de cidadão: RPO = 1 minuto (replicação síncrona)
• Logs analíticos: RPO = 1 dia (batch diário tolerável)

RPO = 0 exige replicação síncrona com custo operacional alto. RPO deve ser definido por tipo de dado, não globalmente.

47.2.3 RTA — Recovery Time Actual

Tempo real gasto em uma restauração. Monitora se o RTO está sendo atingido.

47.2.4 MTTR — Mean Time To Repair

Tempo médio histórico para restaurar serviço após falha detectada.

47.2.5 MTBF — Mean Time Between Failures

Tempo médio entre falhas sucessivas. Quanto maior, melhor.

47.3 Princípios de Continuidade

1. RTO/RPO definido por domínio — não há valor único para toda plataforma
2. Falha é esperada — arquitetura assume que componentes falham
3. Resiliência local — cada serviço trata falhas dentro de seu escopo
4. Replicação e redundância — dados e workloads em múltiplas localizações
5. Automatização de failover — sem intervenção manual quando possível
6. Teste periódico — plano de DR testado a cada trimestre
7. Documentação atualizada — runbooks operacionais válidos e testados
8. Observabilidade — detecção rápida de falhas e degradação

47.4 Estratégias de Alta Disponibilidade

47.4.1 Multi-AZ (Availability Zone)

Distribuição de workloads entre múltiplas zonas de disponibilidade da cloud:

AZ-1 (us-east-1a)
├── Master DB
├── API Pod 1
└── Cache Pod 1

AZ-2 (us-east-1b)
├── Replica DB
├── API Pod 2
└── Cache Pod 2

AZ-3 (us-east-1c)
├── Replica DB
├── API Pod 3
└── Cache Pod 3

Falha de uma AZ não derruba plataforma. Load balancer automaticamente roteia tráfego para AZs saudáveis.

47.4.2 Replicação Síncrona vs. Assíncrona

Síncrona (RPO = 0):

• Escrita confirmada apenas após replicação em múltiplos nós
• Latência aumentada
• Garantia de zero perda de dados
• Usado para dados críticos (solicitações, documentos)

Assíncrona (RPO > 0):

• Escrita confirmada localmente; replicação em background
• Latência baixa
• Risco de perda de dados na janela de replicação
• Usado para dados toleráveis a perda (cache, logs analíticos)

47.4.3 Failover Automático

Health Check falha em Master
    │
    ├─ Detectado por Prometheus
    │
    ├─ AlertManager dispara alerta
    │
    ├─ Kubernetes reinicia pod (se nó saudável) ou provisiona em novo nó
    │
    ├─ Se nó inteiro falha: StatefulSet promove replica
    │
    └─ Tráfego automaticamente roteado

Failover automático reduz MTTR significativamente.

47.5 Estratégias de Disaster Recovery

47.5.1 Backup + Restore

Estratégia: Backup regular em local geográfico distante, testado mensalmente.

RTO: 4-24 horas (tempo para provisionar infraestrutura e restaurar dados) RPO: 6-24 horas (frequência de backup)

Custo: Baixo — apropriado para dados com tolerância a indisponibilidade

Casos de uso: Logs históricos, analytics, arquivos inativos

47.5.2 Ativo-Ativo (Multi-Region)

Estratégia: Dois clusters em regiões geográficas diferentes, ambos recebendo tráfego.

us-east-1 (ATIVO)        eu-west-1 (ATIVO)
├── API Instâncias       ├── API Instâncias
├── DB Primário          ├── DB Primário
└── Cache               └── Cache

         ↓              ↓
   Replicação Bidirecional
   (latência < 100ms)

RTO: <1 minuto (DNS failover automático) RPO: < 1 segundo (replicação síncrona)

Custo: Alto — mantém infraestrutura duplicada

Casos de uso: Serviços críticos com SLA 99.99%+

47.5.3 Ativo-Passivo (Standby)

Estratégia: Cluster primário ativo, cluster standby em espera aguardando ativação manual ou automática.

us-east-1 (ATIVO)
├── API Instâncias
├── DB Primário
└── Cache

         ↓ (replicação assíncrona)

eu-west-1 (STANDBY)
├── EC2 desligados
├── DB Replica read-only
└── Storage snapshot

RTO: 10-30 minutos (tempo para provisionar e promover replica) RPO: 5-15 minutos (lag de replicação)

Custo: Médio — infrastructure standby em espera (lower cost instances possível)

Casos de uso: Serviços com SLA 99.9%

47.6 Backup Strategy

47.6.1 3-2-1 Rule

• 3 cópias de dados (original + 2 backups)
• 2 tipos de mídia (storage em disco + fita/archive)
• 1 cópia offsite (geográficamente distante)

47.6.2 Frequência de Backup

47.6.3 Backup em Camadas

Database
    │
    ├─ WAL (Write-Ahead Log) → S3 a cada 15 segundos
    │
    ├─ Backup incremental → S3 a cada 6 horas
    │
    ├─ Backup full → S3 daily
    │
    └─ Archive → Glacier monthly

Camadas diferentes balanceiam RTO/RPO/custo.

47.6.4 Encriptação de Backup

Backups são encriptados com KMS key específica de backup. A chave é armazenada separadamente da chave de produção — garante que comprometimento da chave prod não compromete backups históricos.

47.7 Teste de Disaster Recovery

47.7.1 Cadência de Teste

• Failover automático: Testado continuamente via chaos engineering
• Restore de backup: Testado mensalmente em ambiente clone
• Full DR drill: Testado a cada trimestre com todas as partes interessadas

47.7.2 Teste de Restore

# 1. Provisionar VM clone
aws ec2 run-instances --image-id ami-xxx --instance-type m5.large

# 2. Restaurar backup do dia anterior
pg_restore /backups/platform-2026-07-16.dump

# 3. Validar dados (sample queries, checksums)
SELECT COUNT(*) FROM requests WHERE created_at > NOW() - INTERVAL '1 day'

# 4. Validar APIs (health check, sample requests)
curl https://clone.platform.example.com/health

# 5. Registrar RTA
echo "RTA: 45 minutes" >> /var/log/dr-test-2026-07-16.log

RTA é métrica crítica — se RTA > RTO, plano de recovery não é viável.

47.7.3 Chaos Engineering

Injetar falhas intencionais em produção para validar resiliência:

# Chaosmonkey config
experiments:
  - name: TerminateRandomNode
    probability: 0.1  # 10% chance por hora
    excludeGroups:
      - "etcd"  # nunca matar nós críticos sem plano
      
  - name: InjectLatency
    probability: 0.05
    latencyMs: 500
    services:
      - "api-solicitacoes"
      - "document-service"

Falhas intencionais detectam pontos cegos na resiliência.

47.8 Disaster Recovery Plan (DRP)

47.8.1 Conteúdo do DRP

47.8.2 Exemplo: Runbook — Falha de AZ

SCENARIO: us-east-1a falha completa

1. DETECT (automático)
   - Alertas disparam para on-call
   - PagerDuty notifica equipe

2. COMMUNICATE
   - Incident commander abre Slack channel
   - Notifica stakeholders de status.prodemge.gov.br

3. ASSESS (5 min)
   - Verificar quais serviços afetados
   - Verificar quais AZs saudáveis
   - Conferir replicação lag

4. FAILOVER (10 min)
   - Kubernetes drain nodes em 1a
   - Pods reschedule em 1b, 1c
   - Load balancer remove 1a do pool (automático)

5. VALIDATE (5 min)
   - Health check em todas as AZs
   - Amostra de requests em produção
   - Verificar taxa de erro < 0.1%

6. COMMUNICATE
   - Status verde em status.prodemge.gov.br
   - Post-mortem agendado para amanhã

7. POST-MORTEM (next day)
   - O que funcionou bem
   - O que falhou ou foi lento
   - Ações para melhorar

Runbook claro reduz MTTR significativamente.

47.9 Replicação de Dados

47.9.1 PostgreSQL Replication

Master-Replica síncrono com quorum commit:

# postgresql.conf
wal_level = replica
max_wal_senders = 10
synchronous_commit = on  # espera confirmação de replica
synchronous_standby_names = 'standby1, standby2'

Alternativamente, configurar 2 replicas sincronas (quorum 2 de 3).

47.9.2 Replicação Cross-Region

us-east-1 (Primary)
    │
    └─ WAL streaming com lag < 10 segundos
    │
    └─ eu-west-1 (Standby)
    │
    └─ ap-south-1 (Archive)

Lag de replicação monitorado continuamente — alertar se lag > 1 minuto.

47.10 Comunicação e Stakeholders

47.10.1 Status Page

status.prodemge.gov.br com:

• Status de cada serviço (green/yellow/red)
• Histórico de incidents
• Tempo estimado de resolução
• Atualizações a cada 15 minutos durante incident

47.10.2 Notification Chain

Falha detectada
    │
    ├─ PagerDuty (on-call)
    │
    ├─ Slack #incidents
    │
    ├─ Status page (clientes)
    │
    └─ Email stakeholders (se crítico)

Comunicação rápida reduz pânico e coordena resposta.

47.11 Métricas de DR

47.12 Rastreabilidade com o Anexo V

47.13 Decisões Arquiteturais

47.14 Próximo Capítulo

O Capítulo 48 detalha Gestão de Incidentes e Response, completando a PARTE VI — Segurança e Conformidade.

47.15 Controle de Versão

47.16 Rastreabilidade PRODEMGE

• [ANX-V] Item 2.4 — Continuidade de negócio: RTO/RPO definidos por domínio, backup testado, replicação multi-AZ, disaster recovery plan com runbooks operacionais.
• [PNR] — Plataforma recuperável em cenários de falha com RTO < 30 min para serviços críticos e RPO < 5 min para dados transacionais.
• [EDITAL] — Edital CP001/2026: plataforma com alta disponibilidade em múltiplas AZs e disaster recovery plan testado trimestralmente.