Runbooks, simulacros e incidentes

A las 3 de la mañana, con los pagos caídos y cinco personas en una llamada, nadie piensa bien. Se discute quién decide, se buscan contraseñas, alguien ejecuta un comando que otro ya había ejecutado. El buen diseño técnico se pierde en una mala respuesta humana.

Esta lección cubre lo que hace que la recuperación funcione en la práctica: un documento que dice qué hacer, quién lo hace y cuándo; criterios para declarar un desastre; práctica antes de necesitarlo y aprendizaje después.

Runbook y playbook

Esta es la distinción del pilar de fiabilidad de Well-Architected (REL12-BP01). En la práctica, un playbook termina muchas veces en «ejecuta el runbook X».

Anatomía de un runbook

1. 1

   Disparador

   Qué señal lo activa: una alarma concreta, un evento de AWS Health, una decisión del comandante.
2. 2

   Dueño y roles

   Quién lo mantiene y quién hace qué durante el incidente: comandante del incidente (decide y coordina, no teclea), comunicaciones (habla con clientes y negocio), líderes técnicos por área y un escriba que anota la línea de tiempo.
3. 3

   Prerrequisitos

   Accesos de emergencia probados, herramientas y copias del propio runbook fuera de la región afectada.
4. 4

   Pasos

   Numerados y marcados como automáticos o manuales. Cada uno dice cómo verificar que funcionó.
5. 5

   Evidencia

   Qué capturar y cuándo: horas de cada paso, retraso de replicación, capturas del SLI. Sirve para el análisis posterior y para medir el RTO real.
6. 6

   Puntos de decisión

   Dónde se para a decidir, con qué criterio y quién decide.
7. 7

   Reversa

   Cómo deshacer cada paso si sale mal.
8. 8

   Criterios de éxito

   Cuándo se da por recuperado: el SLO en verde durante un tiempo acordado, no «parece que ya funciona».

RUNBOOK: Failover de «pagos» a la región secundaria
Versión 7 · Dueño: equipo de pagos · Último simulacro: (fecha)

DISPARADOR
  Alarma «pagos-slo-burn-rate-alto» por 15 min  Y  canary externo fallando
  O  evento de AWS Health que afecta la región principal

ROLES
  Comandante del incidente · Comunicaciones · Líder técnico de datos
  Líder técnico de aplicación · Escriba (lleva la línea de tiempo)

PRERREQUISITOS
  Acceso de emergencia probado · Consola de la región secundaria
  Este runbook y los contactos, copiados fuera de la región principal

PASOS
  1. [MANUAL] Confirmar impacto con el SLI y el canary externo
  2. [DECISIÓN] ¿Cumple los criterios de activación? Si no → monitorear
  3. [AUTO]   Detener escrituras en la región principal
  4. [AUTO]   Promover la base de datos secundaria
  5. [MANUAL] Aprobar el cambio de tráfico
  6. [AUTO]   Redirigir el tráfico a la región secundaria

EVIDENCIA
  Hora de cada paso · Retraso de replicación al momento de promover

ÉXITO
  SLO de «pagar» en verde 30 min en la región secundaria

REVERSA
  Si falla el paso 4 → reactivar escrituras en la principal y escalar

Cuándo declarar un desastre

Declarar un desastre es activar el plan grande: failover a otra región, restauración desde respaldos, comunicación a clientes. Los criterios de activación se acuerdan antes, por escrito, con el negocio. Por ejemplo: «el SLO de pagar quema presupuesto a más de 10 veces su tasa normal durante 20 minutos, el canary externo lo confirma y no hay una causa que se pueda corregir en la región». También se acuerda quién puede declarar, para no esperar a que conteste el director.

La decisión es parte del RTO: si tu objetivo es 1 hora y tardas 40 minutos en decidir, quedan 20 para recuperar. Lo detallamos en RPO y RTO. Un flujo genérico de incidente mayor:

1. 1

   Detectar

   Una alarma por síntoma, un canary externo o un evento de AWS Health.
2. 2

   Evaluar

   Qué recorridos están afectados, desde cuándo y si hay un cambio reciente que revertir.
3. 3

   Declarar

   Comparar contra los criterios de activación y nombrar al comandante.
4. 4

   Contener y proteger los datos

   Detener escrituras, pausar procesos que puedan dañar datos, anotar el retraso de replicación.
5. 5

   Recuperar

   Promover la base secundaria, escalar la capacidad de respaldo, restaurar si hace falta.
6. 6

   Redirigir

   Mover el tráfico a la región sana. Los detalles, en failover y failback.
7. 7

   Validar

   Probar los recorridos críticos con canaries y comparar el SLI con el objetivo.
8. 8

   Operar en contingencia

   Con capacidad o funciones reducidas, y avisos claros a los clientes.
9. 9

   Volver y aprender

   Planear el regreso con calma y hacer el análisis posterior.

Comunicar durante el incidente

El silencio genera más tickets que la falla. El rol de comunicaciones publica en la página de estado (alojada fuera de la región afectada) qué está afectado, qué no y cuándo será la próxima actualización, aunque no haya novedades. Hacia adentro, un solo canal para el incidente y resúmenes periódicos para el negocio, soporte y dirección. Las plantillas de mensajes se escriben antes, no a las 3 de la mañana.

Automatizar y practicar con AWS

• 

  Systems Manager Automation

  Los pasos automáticos del brigadista

  Runbooks en YAML o JSON con pasos que corren en orden. Hay runbooks predefinidos de AWS, se pueden pedir aprobaciones, disparar desde EventBridge y ejecutar en varias cuentas y regiones.
• 

  AWS Health + EventBridge

  Los eventos de AWS Health (problemas de servicio, mantenimientos) llegan a EventBridge, que puede avisar o iniciar una automatización.
• 

  AWS Resilience Hub

  El inspector que revisa el plan

  Evalúa una aplicación contra una política de RTO y RPO por tipo de falla: aplicación, infraestructura, AZ y región. Recomienda cambios y pruebas.
• 

  AWS Fault Injection Service

  El simulacro de evacuación

  Experimentos de fallas reales con condiciones de parada sobre alarmas de CloudWatch. Su biblioteca trae escenarios como «AZ Availability: Power Interruption» y «Cross-Region: Connectivity».
• 

  ARC Region switch

  Planes de cambio de región con pasos en orden o en paralelo. Tiene plano de datos en cada región, así que no depende de la región que estás abandonando.

La práctica va de menos a más riesgo:

• Ejercicio de mesa (tabletop): el equipo recorre un escenario conversando, runbook en mano. Barato y sorprendentemente útil: aparecen pasos que nadie sabe hacer.
• Game day: se inyecta una falla real en un entorno controlado, con FIS, y el equipo responde como si fuera de verdad. Well-Architected lo pide de forma regular (REL12-BP05).
• Simulacro de DR con calendario fijo: failover completo a la región de respaldo. Anota la hora de cada fase y compara el RTO real contra el objetivo. Si el objetivo es 1 hora y el simulacro tomó 3, el objetivo es ficción hasta que lo corrijas.

Después del incidente: análisis sin culpables

Amazon llama a su práctica Correction of Error (COE). Se escribe una línea de tiempo, el impacto en clientes y negocio, y un análisis de causas con la técnica de los cinco porqués. La regla central: se pregunta por qué pasó, no quién lo hizo. Si una persona pudo borrar la tabla de producción con un comando, el problema es que el sistema lo permitió.

Las preguntas útiles, según el pilar de excelencia operativa (OPS11-BP02):

• ¿Pudimos detectarlo antes? ¿Qué alarma faltó?
• ¿Pudimos diagnosticarlo antes? ¿Llamamos a la persona correcta a tiempo?
• ¿Pudimos mitigarlo antes? ¿Qué paso del runbook faltaba o estaba mal?
• ¿Cómo evitamos que vuelva a pasar?

Cada respuesta se vuelve una acción con dueño y fecha, y el runbook se actualiza con lo aprendido. Un análisis sin acciones cerradas es solo un relato.