Disaster Recovery Plan
1) Destino, área e princípios
O objetivo é assegurar que a plataforma de TI seja restaurada a tempo após desastres (como ciber, vendedor, geopolítico) sem violar as exigências regulatórias, os contratos e as expectativas dos jogadores.
Área: ambiente produtivo (circuito de jogos, pagamentos, KYC/AML, antifrode, vitrines DWH/BI), integração (PSP, KYC, CDN, estúdios/agregadores), infraestrutura (nuvem/K8s, redes, segredos/chaves), dados (BD, arquivos, logs)
Princípios: safety-first, minimização de RTO/RPO, automação e reprodução (IaC), «comprovabilidade padrão», exercícios regulares.
2) Classificação de sistemas e metas de recuperação
2. 1 Níveis de criticidade
Tier-1 (vital): pagamentos/cassautas, core-games, login/autenticação, CUS/sanções.
Tier-2: analista em tempo real, marketing/CRM, relatórios DWH.
Tier-3 - portais internos, serviços de apoio.
2. 2 Metas
RTO (Recovery Time Objective): tempo até o serviço ser restabelecido.
RPO (Recovery Point Objective): perda de dados de tempo válida.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual): os valores reais são registrados nos relatórios.
MTO/MBCO: Tempo máximo de inatividade/nível mínimo aceitável de serviço (modo degraded).
- Tier-1 - RTO ≤ 30-60 min, RPO ≤ 15 min; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.
3) Estratégias de DR. e arquitetura
3. 1 Topologias
Ativo-ativo (região multi): RTO/RPO mínimo, requer consistência e conflito-ressalva.
Ativo-Standby (quente/quente/frio): saldo custo/velocidade.
Separação geo de dados e chaves: KMS/HSM per-region, BYOK, caminhos de replicação independentes.
3. 2 Dados e bacapes
PITR (point-in-time recovery): registros de transações, intervalos de arquivamento ≤ 5-15 min para Tier-1.
Snepshots/full bacapes: diárias/relógios, armazenamento 3-2-1 (3 cópias, 2 mídias, 1 off/off).
Permanência: WORM/looks de objetos, assinatura/cadeia de hash de artefatos.
Catálogo de recuperação: inventário de bacapes, integridade, data de validade, transcrição de teste.
3. 3 Aplicativos e Integração
Serviços de estágio: implantação rápida através de IaC/CI.
Componentes de estágio: súmulos alinhados, orquestração de seqüência de lançamento.
Integrações (PSP/KYC/Agregados): crediários duplos, fallback-endpoint, webhooks assinados, controle de reaproveitamento (idempotação).
4) Ordem de recuperação (runbook geral)
1. O anúncio do cenário DR. → a atribuição do DR. Invident Project (DR.-IC), iniciando o war-room.
2. Avaliação de danos: regiões/subsistemas afetados, RTA/RPA relevante, decisão de ativar o feelover.
3. Isolamento/contêiner: bloqueio de causas originais (LCA de rede, segredos, desativação do provedor).
- rede/segredos/KMS →
- BD/armazenamento/dinheiro →
- API/serviços → frente/CDN → integração externa.
- 5. Verificação de integridade contra. somas, pedidos «secos», provas de health.
- 6. Reconciação de finanças/jogos: acréscimo de pagamentos, apostas, balanços, repetição idumpotente de transações.
- 7. Comunicações: status-página, jogadores/parceiros/reguladores; timeline de atualizações.
- 8. Vigilância e estabilização: desativação de degradações à medida que normalizamos.
- 9. RCA, CAPA, atualização DRP.
5) Runbooks especializados (fatias)
5. 1 Perda da região principal (Action-Standby → Standby)
yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"5. 2 Corrupção BD/recuperação de PITR
yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]5. 3 PSP degradação em DR
yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation6) Integridade de dados e reconciliação
Finanças: verificação de depósitos/pagamentos/comissões, reencontro de notificações e webhooks de dedução (idempotency-keys).
Contorno de jogo: restauração de estados de rodadas, repetição de cálculos quando necessário, proteção contra débitos duplos/pagamentos.
Registro/auditoria: mapeamento de logs WORM antes/depois, assinaturas/hashi, relatórios de inadimplência.
Relatório DPO/Complacência: Em caso de exposição ao PII, fixa escala, timeline e notificações.
7) DR. para tecnologias-chave (exemplos)
SUBD (Relational): Replicação sincronizada/asincrona, slots WAL, fast-promote, stand-bai quente.
NoSQL/cachê: multiclaster, deficiência TTL, preenchimento frio, rejeição cross-region write sem conflito-resolva.
Filas/striptease: topics/cluster espelhados, controle de deslocamento, dedução dos consumidores.
Armazenamento de objetos: versioning, replicação para «bunker», inventário de objetos e políticas de retenção.
CI/CD/artefatos: réplicas de registros, assinatura de artefatos, cópias off-line de contêineres críticos.
Segredos/chaves: KMS per-region, chaves de raiz independentes, break-glass com revista e TTL.
8) Segurança e privacidade em DR
Os direitos mais baixos são DR acessíveis por papéis/perfis individuais (JIT/PAM).
Backapps imutáveis: off/off, teste de recuperação e decodificação.
Janelas de regulação: fixação de eventos e decisão de notificação (regulador/banco/PSP/usuários) junto com Legal/DPO.
Traçabilidade: registro completo de ações do comando DR., assinatura de timeline.
9) Ensinamentos e tipos de testes
Walkthrough/Review: Verificação de documentos/papéis/contatos (trimestral).
Tabletop: pesquisa de cenários para seco com solução de conflitos.
Tecnical partial: restauração de um serviço/BD separado.
Full failover/switch-over - transferência de tráfego e dados para a região de reserva.
Chaos-dias (controlado): injeções de falhas/falhas para verificação automática.
Cada teste → um relatório com RTA/RPA, lista de desvios, CAPA e atualização do DRP.
10) Métricas (KPI/KRI)
RTA/RPA vs RTO/RPO (Tier-1): ≥ 95% das correspondências.
Dr. Teste Coverage: ≥ 2 testes DR completos/ano + parciais regulares.
Time-to-First-Status: ≤ 15 min após o anúncio do DR..
Reconciação Zero-Partiff: Todos os cruzamentos em dinheiro e jogos sem discrepâncias.
Backup Integrity: 100% das restaurações seletivas são bem sucedidas por trimestre.
Config Drift: 0 à deriva entre primary/segundary (IaC).
Segurança em DR.: 100% das ações DR. com registro e confirmação.
11) RASI (acentuado)
12) Folhas de cheque
12. 1 Pronta para Dr
- Contatos de DR./vendedores/reguladores atualizados
- Replicação verde, PITR incluído, decodificação de teste de bacapes
- Acessíveis JIT/PAM, «break-glass» testado
- Os playbooks e variáveis de ambiente são validados
- Cartões duplos/webhooks PSP/KYC, rotas alternativas
- O status da página/modelos de mensagem está pronto
12. 2 Durante o DR
- Indicado DR.-IC, aberto war-room, timeline de eventos
- Isolar a causa, selecionar o cenário, iniciar o runbooks
- Testes de integridade, health-amostras, smoke-testes
- Primeiro update público ≤ 15 min; notificações a parceiros/reguladores de SLA
- Captura de artefatos para investigação
12. 3 Depois do DR
- Acerto completo de dinheiro/jogos e revistas
- Pós-mortem, RCA, CAPA com datas e proprietários
- Atualização DRP/BIA/contatos/IAC
- Plano de novo teste de gravação
13) Modelos (fatias)
13. 1 Cartão de serviço (Dr. passaporte)
yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]13. 2 Relatório de teste Dr. (extrato)
yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"13. 3 Modelo de mensagem de status
[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.14) Mapa de trânsito de implementação (6-8 semanas)
Semanas 1-2: inventário de serviços e dependências, classificação Tier, alvos RTO/RPO, escolha de topologias, passaportes DR..
Semanas 3-4: implementação de bacapes/PITR/emputabilidade, replicação de segredos/KMS, preparação de runbooks e status.
Semanas 5-6: TAC parcial (BD/dinheiro/fila), tabletop em cenários PSP/KYC/região.
Semanas 7-8: full switch-over (se possível), relatório com RTA/RPA, CAPA, atualização do DRP e plano de testes regulares.
15) Integração com outras seções wiki
Associar a: BCP, Registro de Risco, Gerenciamento de Incidentes, Política de Logs (WORM), TPRM e SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, Política de senhas e MFA, Gerenciamento DE com lançamentos.
TL; DR
DRP de trabalho = RTO claro/RPO por Tier → arquitetura de Ative-Ative/Standby + backps/PITR → rotbooks reproduzidos e feedback → reconciação de dinheiro/jogos → exercícios regulares e CAPA. Então qualquer grande falha se transforma em um procedimento controlado, com tempo previsível de recuperação e zero surpresas para reguladores e jogadores.