Disaster Recovery Plan
1) Propósito, área y principios
Objetivo: garantizar la recuperación oportuna de la plataforma de TI tras los desastres (los de ciber, vendor, geopolítica) sin violar los requisitos regulatorios, los contratos y las expectativas de los jugadores.
Área: entornos productivos (circuito de juegos, pagos, KYC/AML, antifraude, escaparates DWH/BI), integración (PSP, KYC, CDN, estudios/agregadores), infraestructura (nube/K8s, redes, secretos/claves), datos (DB, archivos, registros).
Principios: safety-first, minimización de RTO/RPO, automatización y reproducibilidad (IaC), «probabilidad por defecto», ejercicios regulares.
2) Clasificación de sistemas y objetivos de recuperación
2. 1 Niveles de criticidad
Tier-1 (vital): pagos/cajeros, juegos de núcleo, inicio de sesión/autenticación, CUS/sanciones.
Tier-2: análisis en tiempo real, marketing/CRM, informes de DWH.
Tier-3: portales internos, servicios auxiliares.
2. 2 Objetivos
RTO (Recovery Time Objective): tiempo antes de restaurar el servicio.
RPO (Recovery Point Objective): pérdida de datos admisible en el tiempo.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual): los valores reales se registran en los informes.
MTO/MBCO: tiempo de inactividad máximo transportable/nivel de servicio mínimo aceptable (modo degradado).
- Tier-1 - RTO ≤ 30-60 min, RPO ≤ 15 min; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.
3) Estrategias de DR y arquitectura
3. 1 Topologías
Active-Active (multi-región): RTO/RPO mínimo, requiere consistencia y conflicto-resolve.
Active-Standby (caliente/caliente/frío): equilibrio costo/velocidad.
Separación geo de datos y claves: KMS/HSM por región, BYOK, rutas de replicación independientes.
3. 2 Datos y backups
PITR (recuperación de puntos en tiempo): registros de transacciones, intervalos de archivado ≤ 5-15 min para Tier-1.
Snapshots/full-backups: diario/horario, almacenamiento en el circuito 3-2-1 (3 copias, 2 medios, 1 offline/offsite).
Inmutabilidad: WORM/objetos locks, firma/hash cadenas de artefactos.
Catálogo de recuperación: inventario de respaldo, integridad, fecha de caducidad, descifrado de prueba.
3. 3 Aplicaciones e integraciones
Servicios Statles: implementación rápida a través de IaC/CI.
Componentes Stateful: snapshots coherentes, orquestación de secuencia de lanzamiento.
Integraciones (PSP/KYC/agregadores): doble crédito, fallback-endpoints, webhooks firmados, control de re-entrega (idempotencia).
4) Orden de recuperación (runbook general)
1. Anuncio de script DR → asignación de DR Incident Commander (DR-IC), lanzamiento de war-room.
2. Evaluación de daños: regiones/subsistemas afectados, RTA/RPA relevantes, decisión de activación de Feilover.
3. Aislamiento/contenedor: bloquear las causas originales (ACL de red, secretos, desconexión del proveedor).
- red/secretos/KMS →
- BD/almacenamiento/caché →
- API/servicios → frente/CDN → integraciones externas.
- 5. Verificación de integridad: contra. sumas, solicitudes «secas», muestras de salud.
- 6. Reconciliation finanzas/juegos: pagos de conciliación, apuestas, balances, operaciones de repetición idempotente.
- 7. Comunicaciones: status page, jugadores/socios/reguladores; una línea de tiempo de actualizaciones.
- 8. Observación y estabilización: desactivación de las degradaciones a medida que se normalizan.
- 9. Post mortem: RCA, CAPA, actualización DRP.
5) Runbooks especializados (fragmentos)
5. 1 Pérdida de la región principal (Active-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 Corrupción BD/Recuperación 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 Degradación PSP en modo 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) Integridad de los datos y reconciliation
Finanzas: conciliar depósitos/pagos/comisiones, volver a enviar notificaciones y webhooks con deduplicación (idempotency-keys).
Circuito de juego: restablecimiento de estados de rondas, repetición de cálculos si es necesario, protección contra cargos/devoluciones dobles.
Registros/auditoría: correlación de registros WORM «antes/después», firmas/hashes, informes de consistencia.
Informe DPO/Cumplimiento: en caso de impacto PII, fijación de escala, timeline y notificaciones.
7) DR para tecnologías clave (ejemplos)
DBAM (relacional): replicación sincrónica/asíncrona, ranuras WAL, fast-promote, standbays calientes.
NoSQL/caché: multiclaster, TTL-invalidez, relleno en frío, rechazar la escritura cross-region sin conflicto-resolve.
Colas/streams: topics/clústeres espejados, control de desplazamientos, deduplicación de consumidores.
Almacenamiento de objetos: versionar, replicar en un «búnker», inventario de objetos y políticas de retención.
CI/CD/artefactos: réplicas de registros, firma de artefactos, copias offline de contenedores críticos.
Secretos/claves: KMS per-region, claves raíz independientes, break-glass con registro y TTL.
8) Seguridad y privacidad en DR
Principio de los derechos más pequeños: Acceso a DR por roles/perfiles individuales (JIT/PAM).
Backups inmutables: offline/offsite, prueba de recuperación y descifrado.
Ventanas regulatorias: fijación de eventos y decisión de notificaciones (regulador/banco/PSP/usuarios) junto con Legal/DPO.
Trazabilidad: registro completo de las acciones del comando DR, firma de la línea de tiempo.
9) Ejercicios y tipos de pruebas
Walkthrough/Review: validación de documentos/roles/contactos (trimestral).
Tabletop: corriendo escenarios a lo «seco» con solución de conflictos.
Parte técnica: restauración de un servicio/DB separado.
Full failover/switch-over: transfiere tráfico y datos a una región de respaldo.
Chaos-days (controlable): inyecciones de fallos/fallos para verificar los automáticos.
Cada prueba → un informe con RTA/RPA, lista de desviaciones, CAPA y actualización DRP.
10) Métricas (KPI/KRI)
RTA/RPA vs RTO/RPO (Tier-1): ≥ 95% de cumplimiento.
DR Test Coverage: ≥ 2 pruebas DR completas/año + parciales regulares.
Time-to-First-Status: ≤ 15 minutos después del anuncio del DR.
Reconciliation Zero-Diff: todas las conciliaciones de dinero y juego sin discrepancias.
Backup Integrity: 100% de las restauraciones selectivas son exitosas en un trimestre.
Fig Drift: 0 deriva entre primario/secundario (comparación IaC).
Seguridad en DR: 100% de acciones de DR con registro y confirmación.
11) RACI (ampliado)
12) Hojas de cheques
12. 1 Preparación para el DR
- Contactos actualizados del equipo de DR/vendedores/reguladores
- Replicación verde, PITR activado, descifrado de prueba de backups
- Acceso JIT/PAM, «break-glass» verificado
- Los reproductores de Feilover y las variables de entorno son válidos
- Doble crédito/webhooks PSP/KYC, rutas alternativas
- Status-page/plantillas de mensajes listos
12. 2 Durante el DR
- DR-IC asignado, sala de guerra abierta, línea de tiempo de eventos
- Aislamiento de causa, selección de script, ejecución de runbooks
- Pruebas de integridad, pruebas de salud, pruebas de humo
- Primer apdate público ≤ 15 minutos; notificaciones a socios/reguladores sobre SLA
- Incautación de artefactos para la investigación
12. 3 Después de DR
- Conciliación completa de dinero/juegos y revistas
- Post mortem, RCA, CAPA con fechas y propietarios
- Actualización DRP/BIA/contactos/IaC
- Plan de repetición de pruebas de fix
13) Plantillas (fragmentos)
13. 1 Tarjeta de servicio (pasaporte DR)
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 Informe de la prueba DR (extracto)
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 Plantilla de mensaje de estado
[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.14) Hoja de ruta para la implementación (6-8 semanas)
Semanas 1-2: inventario de servicios y dependencias, clasificación Tier, objetivos RTO/RPO, selección de topologías, pasaporte DR.
Semanas 3-4: implementación de backups/PITR/inmutabilidad, replicación de secretos/KMS, preparación de runbooks y estado.
Semanas 5-6: Pruebas parciales (DB/caché/colas), tabletop por scripts PSP/KYC/región.
Semanas 7-8: cambio completo (si es posible), informe con RTA/RPA, CAPA, actualización de DRP y plan de pruebas regulares.
15) Integración con otras particiones wiki
Vincular con: BCP, Registro de Riesgos, Gestión de Incidentes, Política de Registros (WORM), TPRM y SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, Política de contraseñas y MFA, Gestión de cambios/versiones.
TL; DR
Trabajo DRP = RTO/RPO claro por Tier → arquitectura Active-Active/Standby + backups/PITR inmutables → reproducibles runbooks y feilover → reconciliación de dinero/juegos → ejercicios regulares y CAPA Entonces, cualquier fallo importante se convierte en un procedimiento manejable con tiempos de recuperación predecibles y cero sorpresas para reguladores y jugadores.