Cenários de recuperação de emergência

1) Para quê o DR. e qual o objetivo

O Disaster Recovery (DR.) é um conjunto de arquiteturas, processos e treinamentos para restaurar serviços após desastres (falha no datacentro/região, perda de dados, erros de configuração em massa). O objetivo do DR. é cumprir RTO/RPO com um custo e risco controlados, mantendo a confiança dos clientes e adequação à regulação.

RTO (Recovery Time Objective): tempo de inatividade permitido.
RPO (Recovery Point Objective): perda de dados válida (tempo a partir do último ponto de consistência).
RLO (Recovery Level Objectiva): Nível de funcionalidade que deve voltar primeiro (serviço minimamente viável).

2) Classificação de sistemas por criticidade

Tier 0 (vital): pagamentos, login, KYC, núcleo de transações - RTO ≤ 15 min, RPO ≤ 1-5 min

Tier 1 (alto): painéis operacionais, relatórios D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min

Tier 2 (médio): back office, analista near-real-time - RTO ≤ 4-8 h, RPO ≤ 4-8 h.
Tier 3 (baixa): auxiliares não críticos - RTO ≤ 24-72 h, RPO ≤ 24 h.

A cada serviço atribuir o Tier + RTO/RPO de destino no catálogo de serviços; as decisões e os orçamentos são eles.

3) Modelo de ameaças e cenários

Tecnologia: falha da AZ/região/provedor, degradação da rede/DNS, falha do banco de dados/armazenamento, falha de lançamento em massa.
Fator humano: configs errados/IaC, remoção de dados, comprometimento de chaves.
Natural/exterior: incêndio/inundação, interrupções de energia, bloqueios legais.
Para cada um, avaliar a probabilidade/impacto, vinculá-lo a um cenário DR. e playbook.

4) Pattern de arquitetura DR

1. Ativo-ativo (Multi-Region): As duas regiões servem o tráfego.

Benefícios: RTO/RPO mínimo, alta resistência.
Contras: complexidade de dados/consistência, alto preço.
Onde: leitura-pesada, cargas de armazenamento, serviços stateless, multi-master DB (regras de conflito rigorosas).

2. Ative-Passive (Hot Standby): Um passivo «quente» mantém uma cópia completamente aquecida.

RTO: minutos; RPO: minutos. Exige failover automatizado e replicação.

3. Warm Standby: parte dos recursos de aquecimento, escala no acidente.

RTO: Dezenas de minutos; RPO: 15-60 min Mais econômico, mas mais longo.

4. Pilot Light: «faísca» mínima (metadados/imagens/script) + espelhamento rápido.

RTO: relógio; RPO: relógio. Barato, adequado para Tier 2-3.

5. Backup & Restore: backps off-line + aquecimento manual.

RTO/RPO: relógio-dia. Apenas para baixa criticidade e arquivos.

5) Dados e coerência

• Sincronizada é RPO quase zero, mas ↑latentnost/stoimost.
• Asincrona - melhor desempenho, RPO> 0 (cauda de revistas).
• Coerência: selecione o modelo (strong/eventual/causal). Para pagamentos, rigorosamente, para analistas, eventual.
• Cortes (snapshots): crie regularmente pontos consistentes + guarde registros (WAL/redo).
• Transações cruzadas: evite 2PC; use operações idênticas, deli-e-repita (retry com dedução), event surcing.
• Filas/pneus: replicação/espelhamento, DLQ, encomenda e idempotação dos consoadores.

6) Rede, tráfego e DNS

GSLB/Anycast/DNS: políticas failover/failback, TTL baixo (mas não muito), health-checks de várias regiões.
L7-Roading: mapas regionais, bandeiras de degradação de fiho (limitação de funções).
Private-links/VPN: canais de reserva para provedores (PSP/KYC/CDN).
Rate limiting: proteção contra tempestade em recuperação.

7) Stateful vs Stateless

O Stateless é movido por um script/skate automático; O stateful requer uma estratégia de dados alinhada (replicação, esmalte, promoção de réplica, quórum).
Cash/sessão: externo (Redis/Memcached) com replicação cruzada ou re-seed em revistas; manter as sessões em tokens (JWT) ou armazenamento compartilhado.

8) Desencadeadores e automação de DR

Guardrelas SLO e quórum de sondas → region-failover runbook automático.
Mudança freeze em caso de acidente: bloqueamos lançamentos/migrações não recorrentes.
Infraestrutura as Code: Implantação de stand-buy por manifesto, verificação da deriva.
Promoção do papel: frases automáticas promote BD + vendagem writers/segredos.

9) Comunicação e Complacência

War-room: IC/TL/Comms/Scribe; espaçamento de update em SEV.
Status - Geografia de influência, ETA, caminhos contornados.
Regulação: datas de notificação, segurança de dados, armazenamento de evidence imutável.
Parceiros/provedores: contatos confirmados, canal dedicado.

10) Testes e exercícios DR

Tabletop: discutindo cenários e soluções.
Game Day (stage/prod-light): simulação de falha AZ/região, desativação do provedor, reinstalação do DNS.
Testes de restore, restabelecendo os bacapes periodicamente e validando a integridade.
Chaos/Failure inhation: falhas controladas de rede/nós/dependências.
Ensinamentos KPI: alcançados RTO/RPO, defeitos de playbooks, CAPA.

11) Finanças e escolhas de estratégia (FinOps)

Conte $ por RPO/RTO reduzido: quanto mais baixo for o objetivo - mais caro são os canais, licenças, reservas.
Híbrido: Tier 0 - ativo-ativo/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
Os dados são caros: use camadas frias (arquivo/S3/GLACIER), snapshots incorporados, dedução.
Reversão periódica de custos e certificados/licenças de DR. infra.

12) Métricas de maturidade DR

RTO (fato) e RPO (fato) para cada Tier.
DR. Coverage:% dos serviços com cenário/playbook/teste.
Backup Sucess & Restore Sucess: sucesso diário de backups e restaurações testadas.
Time-to-Declare Disaster: velocidade de decisão do failover.
Failback Time: retorno à topologia normal.
Defect Rate Exercícios: espaços/ensinamentos encontrados.
Compliance Evidence Completeness: totalidade dos artefatos.

13) Folhas de cheque

Antes de implantar o DR

• O diretório de serviços contém Tier, RTO/RPO, dependentes e proprietários.
• O pattern (AA/AP/WS/PL/BR) foi selecionado por Tier e orçamento.
• Os acordos de consistência e replicação estão documentados.
• GSLB/DNS/Rotation e health-checks foram configurados e testados.
• Backups, snapshots, registros de alterações - incluídos, testados em restore.
• Playbooks de DR. e contatos de provedores atualizados.

Na hora do acidente (breve)

• Anunciar o SEV e montar o war-room; congelar os lançamentos.
• Verificar quórum das sondas; fixar impacto/geografia.
• Executar o Failover Runbook: tráfego, promoção BD, filas, dinheiro.
• Incluir degrade-UX/limites; publicar updates por SLA.
• Recolher evidence (timeline, gráficos, logs, comandos).

Após o acidente

• Observar SLO n espaçamento; executar o failback como planejado.
• Realizar AAR/RCA; confeccionar CAPA.
• Atualizar playbooks, catalisadores de alertas, malas de teste DR..
• Reportar aos steakhalders/reguladores (se necessário).

14) Modelos

14. 1 Cartão de cenário DR. (exemplo)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook «Promote réplicas de BD» (fragmento)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 Plano de exercício DR. (Resumo)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Anti-pattern

«Há bacapes» sem testes de restore regulares.
Os segredos/endpoints não mudam automaticamente.
Não há idempotidade → duplicação/transações perdidas na reaproveitação.
Configs iguais para regiões sem flagras de fich degradação.
Uma longa Time-to-Declare por medo de «alarme falso».
Provedores monorregionais (PSP/KYC) sem alternativa.
Não há plano de failback. Vivemos numa topologia de emergência para sempre.

16) Mapa de trânsito de implementação (6-10 semanas)

1. Ned. 1-2: classificação de serviços por Tier, instalação de RTO/RPO alvo, seleção de patterns DR..
2. Ned. 3-4: configuração de replicações/bacapes, GSLB/DNS, procedimentos de promoção; playbooks e runbook 'i.
3. Ned. 5-6: primeiro exercício DR. (tabletop→stage), fixação de métricas e CAPA.
4. Ned. 7-8: ensinamentos prod-light com tráfego limitado; automação failover.
5. Ned. 9-10: otimização de custos (FinOps), transferência de Tier 0 para hot/AA, regulamento de exercícios trimestrais e relatórios.

17) Resultado

Um DR. eficiente não é só bacapes. É uma arquitetura coerente, automação failover/failback, disciplina de dados (idempotação/replicação), treinamento e comunicações transparentes. Quando o RTO/RPO é real, os playbooks são trabalhados e os ensinamentos regulares, o desastre se transforma em um evento controlado, depois do qual os serviços voltam rapidamente e previsivelmente à normalidade.