Plantilla de Plan de Recuperación ante Desastres

Usa esta plantilla para prepararte para fallas catastróficas y minimizar el tiempo de recuperación. Complémentala con la Plantilla de Runbook para procedimientos operacionales, y verifica que tus backups realmente restauran con la Plantilla de Test de Verificación de Backups.

Plantilla

# Plan de Recuperación ante Desastres: [Nombre del Servicio / Sistema]

## Overview
| Campo | Valor |
|-------|-------|
| **Responsable del plan** | [equipo o persona] |
| **Último test** | [fecha] |
| **RTO** | [horas — downtime máximo aceptable] |
| **RPO** | [minutos — pérdida de datos máxima aceptable] |
| **Autoridad de declaración** | [quién puede declarar el desastre] |

## Escenarios de Riesgo

| Escenario | Probabilidad | Impacto | Mitigación |
|-----------|--------------|---------|------------|
| Caída de región | Media | Crítico | Despliegue multi-región |
| Corrupción de base de datos | Baja | Crítico | Restore point-in-time |
| Compromiso de credenciales | Media | Alto | Rotación de tokens + lockdown IAM |
| Caída de tercero | Alta | Medio | Circuit breakers + fallback |

## Procedimientos de Failover

### Escenario: Región Primaria No Disponible

1. **Detectar** — la alerta de monitoreo confirma fallo del health check regional
2. **Decidir** — el incident commander confirma el failover (no es flapping)
3. **Enrutar** — actualizar DNS / load balancer a la región secundaria
4. **Verificar** — los smoke tests pasan en la región secundaria
5. **Comunicar** — actualizar status page y canales internos

### Escenario: Corrupción de Base de Datos

1. **Detener escrituras** — poner la base de datos en solo lectura
2. **Identificar** — determinar el alcance de la corrupción y el momento del evento
3. **Restaurar** — restaurar desde el último backup limpio a una instancia nueva
4. **Reproducir** — aplicar WAL / binlog hasta justo antes de la corrupción
5. **Validar** — correr chequeos de integridad de datos
6. **Conmutar** — promover la instancia restaurada a primaria

## Runbook de Recuperación

​```bash
# 1. Verificar salud de la región secundaria
kubectl --context=dr get nodes

# 2. Promover read replicas
gcloud sql instances promote-replica dr-replica

# 3. Actualizar DNS
aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch file://failover.json

# 4. Verificar
./smoke-tests.sh --env=dr
​```

## Dependencias y su Estado DR

| Dependencia | Su RTO | Nuestro Fallback |
|-------------|--------|------------------|
| Procesador de pagos | 4 horas | Encolar transacciones, reintentar después |
| Identity provider | 1 hora | Validación JWT en caché + login degradado |
| CDN | 0 minutos | Switch multi-CDN |

## Roles Durante un Desastre

| Rol | Responsabilidad |
|-----|-----------------|
| Incident commander | Declara el desastre, aprueba el failover |
| Recovery lead | Ejecuta los pasos del runbook |
| Communications lead | Status page, stakeholders, clientes |
| Scribe | Documenta cada acción para el postmortem |

## Calendario de Tests

| Tipo de Test | Frecuencia | Última Realización | Resultado |
|--------------|------------|--------------------|-----------| 
| Ejercicio tabletop | Trimestral | [fecha] | [aprobado / gaps encontrados] |
| Drill de failover | Semestral | [fecha] | [aprobado / gaps encontrados] |
| Test de restore de backup | Mensual | [fecha] | [aprobado / gaps encontrados] |
| Chaos engineering | Mensual | [fecha] | [aprobado / gaps encontrados] |

## Plan de Comunicación

| Audiencia | Disparador | Mensaje | Canal |
|-----------|------------|---------|-------|
| Ingeniería | Cualquier evento DR | Canal de incidentes | Slack #incidents |
| Dirección | RTO > 50% | Actualización de estado | Email + llamada |
| Clientes | RTO > 75% | Status page + anuncio | Status page |

RTO y RPO Explicados

Métrica	Definición	Ejemplo
RTO (Recovery Time Objective)	Cuánto tiempo puedes estar caído	4 horas
RPO (Recovery Point Objective)	Cuántos datos puedes perder	15 minutos

Estos dos números dirigen el resto de decisiones del plan — y son donde la mayoría de los planes de DR fallan. Los equipos copian “RTO 1 hora, RPO 15 minutos” de otro documento sin comprobar si su infraestructura puede cumplirlo físicamente.

La matemática es implacable: si tus backups de base de datos corren cada hora y tu RPO es 15 minutos, tu estrategia de backup no cumple el objetivo — necesitas replicación continua o archivado de WAL. Si tu DNS TTL es 300 segundos y el failover requiere un cambio de DNS, eso solo ya consume 5 minutos de un RTO de 15 antes de que nadie toque un runbook.

Define objetivos por tier de servicio, no globales:

Tier	Servicios de ejemplo	RTO sugerido	RPO sugerido
Tier 0 — crítico para ingresos	checkout, auth, pagos	5-15 min	~0 (replicación síncrona)
Tier 1 — cara al usuario	API, web app, búsqueda	30-60 min	5-15 min
Tier 2 — herramientas internas	dashboards, admin, analytics	4-8 horas	1-24 horas
Tier 3 — batch/reporting	jobs ETL, exports	24-48 horas	24-48 horas

Conseguir buy-in para estos números importa más que los números mismos. Un RTO fijado por dirección sin input de ingeniería tiende a ser físicamente imposible; un RTO fijado por ingeniería sin input del negocio tiende a sobreinvertir. La Plantilla de Documento SLO ayuda a formalizar los objetivos de uptime que estos objetivos de DR deben sostener.

Cómo Elegir una Arquitectura de DR

Cuatro patrones estándar, ordenados por costo:

Patrón	Cómo funciona	RTO alcanzable	Costo relativo
Backup & restore	Snapshots a otra región; reconstruir ante el fallo	Horas-días	$
Pilot light	Núcleo mínimo (replicación de DB) siempre activo; escalar en el failover	30-60 min	$$
Warm standby	Copia viva reducida en la región secundaria	Minutos	$$$
Activo-activo	Capacidad completa en ambas regiones, tráfico repartido	Casi cero	$$$$

La trampa es pagar warm standby en todas partes. Ajusta la arquitectura a la tabla de tiers de arriba: activo-activo para Tier 0, pilot light para la mayoría de los Tier 1, backup-and-restore para todo lo demás. Una startup que se salta el análisis de Tier 3 acaba corriendo bases de datos de producción para servicios que estarían bien restaurados desde un snapshot nocturno.

Dos detalles que hunden arquitecturas por lo demás buenas: el lag de replicación (la replicación asíncrona significa que tu warm standby puede ir minutos por detrás — ese es tu RPO real) y split-brain (si ambas regiones aceptan escrituras durante una partición, fusionarlas es una pesadilla manual; elige una primaria y valla la otra).

La Capa de Backups

Todo plan de DR se apoya en una estrategia de backups, y la mayoría de los equipos tiene una más débil de lo que cree. La regla clásica es 3-2-1: 3 copias de tus datos, en 2 medios distintos (o proveedores), con 1 copia offsite (u offline). Un snapshot de base de datos en la misma región que la base de datos son dos copias en un mismo lugar — protege contra corrupción, no contra una caída de región o una cuenta comprometida.

Tres detalles que conviene auditar antes de escribir el plan:

• Inmutabilidad. El ransomware borra los backups primero. Snapshots que pueden borrarse con las mismas credenciales que administran producción no son una vía de recuperación — son parte del blast radius. Object-lock o una cuenta separada para el storage de backups cierra ese agujero.
• El tiempo de restore es el insumo real del RPO+RTO. Un snapshot de 2TB que tarda 6 horas en restaurar hace físicamente imposible un RTO de 1 hora, diga lo que diga el plan. Mide la duración del restore durante los drills, no durante el incidente.
• La recuperación point-in-time gana a los snapshots en escenarios de corrupción. Si alguien borró una tabla a las 09:00 y lo notas a las 14:00, el último snapshot contiene el error. El archivado de WAL/binlog te permite reproducir hasta justo antes.

Declarar un Desastre

La decisión de DR más difícil no es técnica — es decidir que hoy es el día. Disparar demasiado pronto y haces failover sobre un falso positivo, posiblemente empeorando las cosas; demasiado tarde y el RTO se agotó antes de que nadie abriera el runbook.

El campo “autoridad de declaración” de la plantilla existe porque esta decisión no puede ser un voto de comité a mitad del incidente. Escribe por adelantado quién puede declarar (normalmente el incident commander o el lead de guardia, nunca un grupo) y dale criterios que pueda comprobar en menos de cinco minutos: un fallo de health check regional confirmado, un chequeo de integridad de datos que falla, o un proveedor confirmando una caída de varias horas en una dependencia crítica.

Igual de importante: define qué no cuenta como desastre. Una región degradada donde tu app sigue sirviendo lecturas es un incidente, no un evento DR. Hacer failover sobre una primaria degradada pero viva es cómo los equipos convierten un hipo de nube de 20 minutos en una caída autoinfligida de dos horas.

Cómo Correr un Ejercicio Tabletop

Un ejercicio tabletop es un drill en papel: reúne al equipo de guardia durante 60-90 minutos y recorre el plan en voz alta, paso a paso, fingiendo que un escenario real acaba de dispararse. Cuesta casi nada y encuentra el 80% de los problemas que encontraría un drill en vivo.

Estrúcturalo así:

1. Elige un escenario de tu tabla de riesgos — “región primaria no disponible” es la primera corrida clásica.
2. Narra la línea de tiempo. “Son las 14:03, salta la alerta. ¿Quién la ve? ¿Qué hace primero?” Fuerza respuestas concretas, no “ya lo resolveríamos”.
3. Asigna un scribe que anote cada gap: un teléfono desactualizado, una credencial de DNS que solo tiene una persona, un paso que nadie sabía que existía.
4. Cierra con una lista de acciones — responsable y fecha límite para cada gap. Un tabletop sin seguimiento es una reunión, no un test.

Corre el drill con alguien que no escribió el plan. Si solo el autor puede ejecutarlo, el plan no es un plan — es la memoria de una persona.

Mantener el Plan Vivo

Un plan de DR se degrada más rápido que casi cualquier otro documento de la wiki. Los contactos se van, las regiones cambian de nombre, el canal de Slack se archiva, alguien rota las credenciales de DNS — y el plan sigue apuntando a un mundo que ya no existe. La única defensa es una cadencia de revisión que corre por calendario, no por memoria de alguien.

Mete la revisión dentro del calendario de drills, no al lado: cada tabletop termina con diez minutos de “¿qué hay en este documento que ya no es cierto?”. Eso atrapa la obsolescencia mientras es barata. Dos veces al año, verifica explícitamente lo pequeño — teléfonos, rotaciones de guardia, IDs de cuenta, credenciales de DNS — porque esos son exactamente los detalles que se pudren en silencio entre incidentes grandes.

Versiona el plan en git como código. Cuando ocurra un incidente real, querrás hacer diff entre lo que decía el plan y lo que el equipo hizo de verdad — esa brecha es el insumo más honesto que tendrá la siguiente revisión.

Y asigna un único responsable al documento. No un comité — una persona con nombre cuyo trabajo incluye disparar la revisión cuando el calendario lo dice. La propiedad compartida de un plan DR suena a colaboración sobre el papel y funciona en la práctica como abandono. Si esa persona se va y nadie hereda el documento, descubrirás que el plan quedó huérfano justo cuando más lo necesitabas.

Lo que Funciona

• Testea la recuperación trimestralmente — un plan no testeado es una fantasía. Consulta la Guía de Infraestructura como Código para aprovisionamiento automatizado de entornos.
• Automatiza el failover donde sea posible — el failover humano tarda 10 veces más bajo estrés.
• Documenta decisiones, no solo pasos — por qué elegiste ese RTO ayuda a futuros revisores a cuestionar correctamente.
• Mantén el plan accesible offline — durante un desastre, tu wiki interna puede estar caída. Consulta la Guía de Monitoreo y Alertas para los disparadores de detección.
• Incluye dependencias de terceros — tu DR es tan fuerte como tu proveedor más débil.
• Cronometra el drill contra el objetivo — si tu RTO es 1 hora y el drill tarda 3, eso es un hallazgo, no un fallo. Registra la brecha, arregla el cuello de botella y vuelve a correrlo; un plan que solo cumple sus objetivos sobre el papel no los cumple en ningún lado.

Errores Comunes

• Backups no testeados — un backup que nunca restauraste es el backup de Schrödinger.
• Todo en una sola región — las regiones de AWS fallan; multi-región no es opcional para servicios críticos.
• Sin rollback del failover — volver a la primaria es más difícil que conmutar, y casi nadie lo planifica.
• Ignorar la consistencia de datos durante el failover — las escrituras split-brain corrompen datos en ambos lados.
• RTO/RPO fijados por managers sin input de ingeniería — si el objetivo es físicamente imposible, el plan es teatro.
• Copiar la plantilla una vez y nunca actualizarla — un plan DR con listas de contactos desactualizadas es peor que no tener plan, porque genera falsa confianza.
• Dejar campos requeridos en blanco — una tabla llena de placeholders [fecha] significa que el drill nunca corrió de verdad.

Troubleshooting de Procedimientos DR

• El failover corre pero el tráfico no conmuta: revisa el DNS TTL — un TTL de 300s significa hasta 5 minutos de registros obsoletos. Baja los TTLs antes del drill, o usa una capa de load balancer que no dependa de la propagación DNS.
• El backup existe pero no restaura: la ruta de restore nunca se ejercitó. Snapshots corruptos, dependencias que faltan o una versión de base de datos que cambió desde el backup. Los tests de restore mensuales atrapan esto antes de que importe.
• El drill supera el RTO: cronometra cada paso por separado. Normalmente el cuello de botella no es la infraestructura — es la cadena de aprobación o un paso del runbook que asume conocimiento que solo tiene una persona.
• Split-brain tras un failover parcial: valla la antigua primaria antes de promover la réplica (bloquea escrituras a nivel de red o IAM), y luego reconcilia. Nunca dejes que ambos lados acepten escrituras.
• El failback a la primaria sale mal: nadie lo testeó. Planifica el failback como su propio escenario — suele ser más difícil que el failover porque la “nueva” primaria ahora tiene datos vivos que la vieja no tiene.

Variantes

Contexto	Enfoque	Notas
Startup	DR simplificado: backup + restore	RTO 8h, RPO 24h aceptable
Enterprise	DR multi-región activo-activo	RTO 15min, RPO 0
E-commerce	DR con prioridad en catálogo y checkout	Restaurar en orden de impacto en ingresos
Fintech	DR con prioridad en integridad de transacciones	Cero pérdida de datos tolerable

Ejemplo de Plan DR: Fallo de Región Primaria

=== Plan DR: Fallo de región us-east-1 ===

Escenario: región us-east-1 no disponible
Objetivo RTO: 1 hora
Objetivo RPO: 15 minutos

Triage Inicial (0-5 min):
  1. Confirmar que us-east-1 está caída (no es un falso positivo)
     - Revisar AWS Health Dashboard
     - Revisar status.aws.amazon.com
  2. Declarar incidente DR-SEV1
  3. Notificar a dirección y stakeholders
  4. Activar canal DR (#dr-incident)

Ejecución del Failover (5-45 min):
  Paso 1: Promover región secundaria (eu-west-1) a primaria
    - Actualizar DNS (Route 53) para apuntar a eu-west-1
    - Verificar que los health checks pasan en eu-west-1
    - Tiempo estimado: 5-10 min

  Paso 2: Escalar recursos en eu-west-1
    - Aumentar réplicas para soportar todo el tráfico
    - kubectl scale deployment app -n production --replicas=20
    - Tiempo estimado: 5-10 min

  Paso 3: Restaurar datos desde backup
    - Último backup RDS: hace 12 min (dentro del RPO)
    - Restaurar snapshot a nueva instancia en eu-west-1
    - Tiempo estimado: 15-20 min

  Paso 4: Verificar servicios
    - Health checks en todos los endpoints
    - Smoke tests en flujos críticos (login, pago, checkout)
    - Verificar que no hay pérdida de datos (comparar conteos de registros)
    - Tiempo estimado: 5-10 min

Comunicación (en paralelo a la ejecución):
  - Status page: "Investigando caída de us-east-1"
  - A los 15 min: "Failover a eu-west-1 en curso"
  - A los 45 min: "Servicios restaurados en eu-west-1"
  - A los 60 min: "Incidente resuelto; investigando causa raíz"

Rollback (si el failover falla):
  - Si eu-west-1 no soporta la carga: degradar a modo solo lectura
  - Si los datos no pueden restaurarse: usar último backup válido (mayor RPO)
  - Si todo falla: activar plan de comunicación de caída prolongada

Post-Recuperación:
  - Monitorizar estabilidad en eu-west-1 durante 24 horas
  - Investigar causa raíz del fallo de us-east-1
  - Hacer postmortem en 48 horas
  - Actualizar el plan DR con los aprendizajes
  - Planificar migración de vuelta a us-east-1 (o región nueva)

Puntos Clave

• Un plan DR no testeado es ficción — el tabletop trimestral es lo que convierte un documento en una capacidad.
• RTO/RPO son restricciones de ingeniería, no aspiraciones: verifica tu cadencia de backups y tus TTL de DNS contra ellos antes de escribirlos.
• Ajusta la arquitectura de DR al tier del servicio — activo-activo en todas partes es teatro presupuestario.
• Aprobación humana para el switch de tráfico, automatización para todo lo demás.
• El failback merece su propio plan; la mayoría de los equipos lo descubre durante su primer incidente real.

Lectura Adicional

• AWS — Disaster Recovery of Workloads on AWS — el whitepaper de referencia para backup/restore, pilot light, warm standby y activo-activo.
• Google SRE Workbook — Incident Response — cómo los equipos SRE de Google estructuran la respuesta a incidentes y los postmortems.
• Archivos de postmortems de Cloudflare y GitLab — eventos DR reales y qué salió mal de verdad.