Escenarios de recuperación ante desastres

1) Por qué se necesita DR y qué objetivo

Disaster Recovery (DR) es un conjunto de arquitecturas, procesos y entrenamientos para la recuperación de servicios después de desastres (falla del centro de datos/región, pérdida de datos, errores de configuración masiva). El objetivo del DR es cumplir con RTO/RPO objetivo a un costo y riesgo controlados, manteniendo la confianza del cliente y el cumplimiento de la normativa.

RTO (Recovery Time Objective): tiempo de inactividad permitido.
RPO (Recovery Point Objective): pérdida de datos admisible (tiempo desde el último punto de consistencia).
RLO (Recovery Level Objective): nivel de funcionalidad que debe volver primero (servicio mínimamente viable).

2) Clasificación de sistemas por criticidad

Tier 0 (vital): pagos, inicio de sesión, KYC, núcleo de transacciones - RTO ≤ 15 min, RPO ≤ 1-5 min.
Tier 1 (alto): paneles operativos, informes D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min.
Tier 2 (promedio): back office, analítica near-real-time - RTO ≤ 4-8 h, RPO ≤ 4-8 h.
Tier 3 (bajo): auxiliar no crítico - RTO ≤ 24-72 h, RPO ≤ 24 h.

Cada servicio asignará Tier + RTO/RPO de destino en el directorio de servicios; decisiones y presupuestos para conciliar exactamente con ellos.

3) Modelo de amenazas y escenarios

Hecho por el hombre: fallo de AZ/región/proveedor, degradación de la red/DNS, fallo del DB/almacenamiento, bug masivo del lanzamiento.
Factor humano: confecciones/IaC erróneas, eliminación de datos, compromiso de claves.
Natural/externo: incendio/inundación, interrupciones de energía, bloqueos legales.
Para cada uno, estimar la probabilidad/impacto, enlazar al script DR y al playbook.

4) Patrones de arquitectura DR

1. Active-Active (Multi-Región): ambas regiones dan servicio al tráfico.

Pros: mínimo RTO/RPO, alta resistencia.
Contras: complejidad de datos/consistencia, alto precio.
Dónde: leer-pesado, carga almacenada en caché, servicios sin estado, multi-master DB (reglas estrictas de conflicto).

2. Active-Passive (Hot Standby): una pasiva «caliente» mantiene una copia completamente caliente.

RTO: minutos; RPO: minutos. Requiere failover automatizado y replicación.

3. Warm Standby: parte de los recursos de calentamiento, escala en caso de accidente.

RTO: decenas de minutos; RPO: 15-60 min. Más económico, pero más largo.

4. Pilot Light: «chispa» mínima (metadatos/imágenes/scripts) + reversión rápida.

RTO: relojes; RPO: reloj. Barato, adecuado para Tier 2-3.

5. Backup & Restore: backups offline + calentamiento manual.

RTO/RPO: horas-día. Sólo para baja crítica y archivos.

5) Datos y coherencia

• Sincrónico es casi nulo RPO, pero ↑latentnost/stoimost.
• Asincrónico: mejor rendimiento, RPO> 0 (registro de cola).
• Consistencia: seleccione un modelo (strong/eventual/causal). Para los pagos - estrictamente, para los analistas - eventual.
• Cortes (snapshots): cree puntos de consistencia con regularidad + almacene registros (WAL/redo).
• Transacciones entre regiones: evite la 2PC; utilizar operaciones idempotentes, deli-i-repetition (retry con deduplicación), event sourcing.
• Colas/buses: replicación/espejado, DLQ, orden e idempotencia de los consumidores.

6) Red, tráfico y DNS

GSLB/Anycast/DNS: políticas de failover/failback, TTL bajas (pero no demasiado), checks de salud de varias regiones.
Enrutamiento L7: mapas regionales, banderas de degradación (limitación de funciones).
Enlaces privados/VPN: canales de respaldo a proveedores (PSP/KYC/CDN).
Rate limiting: protección contra tormentas durante la recuperación.

7) Stateful vs Stateless

Stateless es transferido por el script/auto-skale; stateful requiere una estrategia de datos coherente (replicación, snapshots, réplica de promoción, quórum).
Caché/sesiones: externas (Redis/Memcached) con replicación cruzada regional o re-seed por registro; mantener las sesiones en tokens (JWT) o almacenamiento compartido.

8) Disparadores y automatización de DR

SLO-gardrailes y sondas de quórum → runbook automático de región-falla.
Cambiar freeze en caso de accidente: bloqueamos versiones/migraciones no relevantes.
Infraestructura como Código: implementación de stand buy por manifiesto, verificación de la deriva.
Promoción de roles: promoción automática de réplicas de BD + ligadura de escritores/secretos.

9) Comunicaciones y cumplimiento

War-room: IC/TL/Comms/Scribe; intervalos de apdate por SEV.
Status page: geografía de influencia, ETA, soluciones.
Regulación: plazos de notificación, seguridad de los datos, almacenamiento inmutable de la información.
Socios/proveedores: contactos confirmados, canal dedicado.

10) Pruebas y ejercicios de DR

Tabletop: Discutimos el escenario y las soluciones.
Día del juego (stage/prod-light): simulación de fallas de AZ/regiones, desactivación del proveedor, restablecimiento de DNS.
Pruebas de restauración: periódicamente restauramos los backups de forma aislada y validamos la integridad.
Inyección de Failure/Chaos: fallas controladas de red/nodos/dependencias.
KPI del ejercicio: RTO/RPO alcanzado, defectos de playbooks, CAPA.

11) Finanzas y selección de estrategia (FinOps)

Cuenta $ por RPO/RTO reducido: cuanto más bajo sea el objetivo, más caros serán los canales, las licencias y las reservas.
Híbrido: Tier 0 - active-active/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
Los datos son caros: utilice capas frías (archivo/S3/GLACIER), snapshots incrementales, deduplicación.
Rugido periódico de costos y certificados/licencias de infra DR.

12) Métricas de madurez DR

RTO (hecho) y RPO (hecho) por cada Tier.
DR Coverage:% de los servicios con script/playbook/test diseñado.
Backup Success & Restore Success: éxito diario de backups y recuperaciones probadas.
Disaster Time-to-Declare: la velocidad de decisión de failover.
Failback Time: volver a la topología normal.
Definición Nota de las Enseñanzas: Espacios/Enseñanzas encontrados.
Compliance Evidence Completeness: la plenitud de los artefactos.

13) Hojas de cheques

Antes de implementar DR

• El directorio de servicios contiene Tier, RTO/RPO, dependencias y propietarios.
• Se seleccionó un patrón (AA/AP/WS/PL/BR) para Tier y Presupuesto.
• Los acuerdos de consistencia y replicación están documentados.
• GSLB/DNS/routing y health-checks están configurados y probados.
• Bacaps, snapshots, registros de cambios - incluidos, verificados en restore.
• DR playbucks y contactos de proveedores actualizados.

Durante el accidente (breve)

• Declarar SEV y montar una sala de guerra; congelar los lanzamientos.
• Comprobar el quórum de las sondas; fijar el impacto/geografía.
• Ejecutar Failover Runbook: tráfico, promoción de BD, colas, caché.
• Habilitar degrade-UX/límites; publicar apdates por SLA.
• Recopilar evidence (línea de tiempo, gráficos, registros, comandos).

Después de un accidente

• Observar los intervalos SLO N; ejecutar failback según el plan.
• Realizar AAR/RCA; formalizar CAPA.
• Actualizar playbucks, catalizadores de alertas, casos de prueba de DR.
• Informar a los stakeholders/reguladores (si es necesario).

14) Plantillas

14. 1 Tarjeta de script DR (ejemplo)

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 DB» (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 Plan de ejercicios DR (breve)

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-patrones

"Hay backups' sin pruebas de restore regulares.
Los secretos/endpoints no cambian automáticamente.
Falta de idempotencia → transacciones duplicadas/perdidas durante la reintroducción.
Las mismas confecciones para las regiones sin banderas de degradación.
Un largo tiempo para declarar por miedo a una «falsa alarma».
Proveedores monorregionales (PSP/KYC) sin alternativa.
No hay plan de fracaso - vivimos en una topología de emergencia «eternamente».

16) Hoja de ruta para la implementación (6-10 semanas)

1. Ned. 1-2: clasificación de servicios por Tier, instalación de RTO/RPO objetivo, selección de patrones DR.
2. Ned. 3-4: configuración de replicación/respaldo, GSLB/DNS, procedimientos de promoción; playbucks y runbook 'y.
3. Ned. 5-6: primeros ejercicios de RD (tabletop→stage), fijación de métricas y CAPA.
4. Ned. 7-8: ejercicios prod-light con tráfico limitado; automatización de failover.
5. Ned. 9-10: optimización de costes (FinOps), transferencia de Tier 0 a hot/AA, regulación de ejercicios trimestrales e informes.

17) Resultado

Un DR eficaz no es solo un backups. Se trata de arquitectura coherente, automatización failover/failback, disciplina de datos (idempotencia/replicación), formación y comunicaciones transparentes. Cuando la RTO/RPO es real, los playbooks se han trabajado y los ejercicios son regulares, el desastre se transforma en un evento administrado después del cual los servicios vuelven a la normalidad rápida y previsiblemente.