Estratégias DR. e RTO/RPO

1) Princípios básicos

1. Alvos antes dos fundos. Primeiro formulamos RTO/RPO e cenários críticos, depois escolhemos a tecnologia.
2. Segmentação de importância. Nem todos os serviços exigem ouro; divida por criticidade de negócios.
3. Os dados são o núcleo DR. A consistência, a replicação, a detecção e o ponto de recuperação são mais importantes do que o ferro.
4. Automação e verificabilidade. O Dr. não faz sentido sem IaC, testes de regressão e telemetria.
5. Ensinamentos e provas. Um plano sem «game day» regular é uma ilusão de disposição.
6. Segurança e complacência. Criptografia, isolamento, WORM/imutable-bacaps, DPA/jurisdição.

2) Termos e conformidades

RTO - Tempo do evento até a restauração do serviço «normal».
RPO é a «idade» do último ponto de dados saudável na recuperação.
O RLO (Recovery Level Objectiva) é o nível de funcionalidade que deve ser restaurado (serviço minimamente viável).
MTD (Máximo Tolerable Downtime) é um limiar após o qual o negócio tem danos inaceitáveis.
RTA/RPA (Actual) - tempo real/ponto de recuperação de práticas.

Ligação: RTO ≤ MTD; RPA ≤ RPO. A disparidade entre os objectivos e os factos é um assunto pós-mortem e melhorias.

3) Classes de estratégias DR. (níveis de preparação)

4) Cenários contra os quais nos defendemos

Perda de região/nuvem/centro de dados (eletricista, rede, provedor).
Corrupção de dados/erro do operador (remoção, réplicas «batidas», estrago lógico).
Malware/criptografado (ransomware).
Defeito de lançamento/configuração (outage em massa).
O colapso da dependência (KMS, DNS, segredos, provedor de pagamentos).
Eventos legais (bloqueios, proibição de saída de dados da jurisdição).

Para cada cenário, especifique RTO/RPO, nível DR., playbook, responsáveis.

5) Estratégias de dados (chave para RPO)

5. 1 Bacapes

Registros de transações completos + incorporativos + (para BB).
Armazéns imutáveis/WORM e cópias off-line («air-gapped»).
Catálogo de bacapes com metadados e criptopodescrito; Restauração de teste programada.

5. 2 Replicação

Sincronizado (RPO baixo, ↑latentnost, risco de disseminação).
Asincrona (baixa influência na perf, RPO> 0; combinar com o pedaço de estrago).
CDC (Mudança Data Capture) para replicação em streaming e reconstrução de status.

5. 3 Proteção contra estragos lógicos

Versionização/» pontos no tempo» (PITR) com janela ≥ N dias.
Assinaturas de invariantes (balanços, somas, chexummas) - detecção inicial de dados «batidos».
Canais de replicação «lentos» (delay 15-60 min) como tampão contra quebra instantânea.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) Aplicativo, estado, dinheiro

Camada de Staitless - Dimensionando e reiniciando em qualquer região (imagem/lista/manifesto em Git).
Estado (BD/cachê/cu): A origem da verdade é um BD; cachês e índices são superenerrados.
Idempotidade e re-drive - reaproveitamento de eventos é permitido; use outbox/inbox, dedup e versões.

7) Rede e ponto de entrada

Failover GSLB/DNS: latency/health-based, TTL curtos na janela do acidente.
Anycast/L7-proxy: Um único IP, um roteiro sobre a saúde das regiões.
Domínios regionais e políticas de jurisdição (geo-pinning para PII).
Feedback de certificados/KMS: cadeias de reposição, dual-key.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) Modelo operacional e automação

IaC/GitOps: infra-estrutura da segunda região = código, implantação «único».
Policy as Code: gate «nenhum manifesto DR./backaps/alertas - nenhum lançamento».
Runbooks: instruções passo a passo e botão vermelho idêntico a ambas as regiões.
Segredos: credos curtos, Federação OIDC, plano de comprometimento/revogação.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) Exercícios e testes (Game Days)

Tabela de cenários: perda do banco de dados, dados «batidos», falha do KMS, queda da região, limite de egress repentino.
Frequência: trimestral para missão crítica; uma vez a cada seis meses, para os outros.
Métricas de ensinamento: RTA/RPA vs alvos, proporção de passos automáticos, número de intervenções manuais, erros de playbook.
Chaos-smoke em lançamentos: degradação de dependências não deve «quebrar» caminhos de DR..

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) Playbooks (modelo canônico)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) Métricas de observabilidade de DR

Replica lag (segundos), RPO-drivt (diferença entre RPO de destino e RPO real).
Restore SLI: tempo de recuperação a frio/calor pelos ambientes.
Coverage:% dos serviços com playbooks/bacaps/PITR ≥ N dias.
Drill score: proporção de passos automáticos, distribuição RTA, frequência de erros.
Permanência:% de bacapes em WORM/air-gapped.
Métricas de evento: comprimento de filas/velocidade de ré-drive após o feelover.

12) Custo e compromissos

CapEx/OpEx: estande quente é mais barato que o Ativo/Ativo, mas mais caro que o Pilot Light.
Egress: Replicação interregional/interglacial custa dinheiro; dinheiro/compressão/unidades locais.
RTO/RPO vs $: cada «nove» de disponibilidade e um segundo de RPO custam o dobro - concorde com o negócio.
Janelas verdes: batch-replicação - em relógios baratos/« verdes ».

13) Segurança e complacência

Criptografia em paz e transito, domínios KMS separados por região.
Imutable-bacapes, proteção contra ransomware: «3-2-1» (3 cópias, 2 mídias, 1 off), MFA-delete.
Jurisdição: geo-pinning para PII, localização de bacapes, Legal Hold acima de TTL.
Os horários disponíveis são os papéis temporários para as operações DR., o registro de auditoria.

14) Anti-pattern

«Escreva um plano mais tarde».
Replicar sem proteção contra estragos lógicos reproduz o erro.
Uma região KMS/segredos é um feelover impossível.
Os bacapes sem restaurações regulares são o Dr. Shredinger.
Transações sincronizadas estreitamente relacionadas entre regiões - Latidão em cascata/queda.
Não há prioridade: nível DR. igual para tudo (caro e inútil).

15) Folha de cheque do arquiteto

1. RTO/RPO/RLO definidos para serviços e cenários?
2. Os dados classificados são: origem da verdade, PITR/janela, WOM/imutable?
3. O nível de DR. selecionado (Backup/Restore, Pilot, Warm, A/P, A/A) por-serviço?
4. Rede: GSLB/Anycast, certificados/chaves com reserva, bandeiras «read-only»?
5. Idempotidade, outbox/inbox compensando transações?
6. Um clique para a segunda região?
7. Horários, KPI RTA/RPA, pós-treinamento?
8. Monitoramento: lag, RPO-drivt, restore-SLI, drill-score, backapps imutáveis?
9. KMS, jurisdição, Legal Hold?
10. Custo: orçamento egress, janelas verdes, nível economicamente razoável?

16) Mini-receitas e sketches

16. 1 PITR para Postgres (ideia):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 Proteção contra estragos lógicos (réplica atrasada):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 Mudança de tráfego (pseudo-API GSLB):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 Verificação de invariantes após o feelover (pseudocode):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

Conclusão

DR. é a capacidade de tomar decisões técnicas e organizacionais mais rapidamente do que os danos crescem. Defina RTO/RPO realista, selecione um nível de preparação suficiente, automatize a infraestrutura e verificações, treine regularmente e mede RTA/RPA real. O acidente não se transformaria num desastre, mas num incidente controlado com resultado previsível.