Módulo 13Trimestre 4 · Operaciones en producción8 puntos del póster

Recuperación ante desastres y gestión de incidentes

Inicia sesión para guardar tu progreso en todos tus dispositivos. Mientras tanto, se guarda en este navegador.

Por qué importa

Todo sistema acaba teniendo un mal día: la caída de un proveedor, una migración fallida, una base de datos borrada, una clave comprometida. Las empresas y los reguladores no preguntan si vas a tener incidentes. Preguntan con qué rapidez los detectas, cómo comunicas, cuántos datos puedes perder y con qué rapidez te recuperas.

Resultados de aprendizaje

  1. Definir el RPO y el RTO de cada sistema y diseñar las copias de seguridad para cumplirlos.
  2. Demostrar que las copias de seguridad funcionan restaurándolas.
  3. Planificar el failover y entender cuándo está justificado el multirregión.
  4. Gestionar un incidente con roles y comunicación claros.
  5. Montar un sistema de guardias sostenible.
  6. Escribir postmortems sin culpables que produzcan correcciones reales.
  7. Ejecutar experimentos de caos controlados.

Lecciones

13.1 RPO y RTO (83)

  • RPO (Recovery Point Objective): cuántos datos te puedes permitir perder (por ejemplo, 5 minutos).
  • RTO (Recovery Time Objective): cuánto tiempo puedes estar caído (por ejemplo, 1 hora).
  • Defínelos por sistema junto con el negocio. Un libro contable necesita un RPO casi nulo; una caché de analítica se puede reconstruir.

13.2 Copias de seguridad (84)

  • Regla 3-2-1: 3 copias, en 2 medios o servicios distintos, 1 fuera del sitio (otra cuenta u otro proveedor).
  • Point-in-time recovery (PITR) para la base de datos principal.
  • Copias de seguridad inmutables y en una cuenta separada, para que un administrador comprometido o un agente descontrolado no pueda borrarlas. (Que agentes y atacantes borren las copias de seguridad junto con producción es un patrón de incidente recurrente.)
  • Haz copia de más cosas que la base de datos: almacenamiento de objetos, secretos y configuración (mediante IaC), datos de terceros que no puedas regenerar.
  • Una copia de seguridad que no has restaurado es una esperanza. Programa simulacros de restauración; mide el RTO real.

13.3 Failover y multirregión (85, 86)

  • Failover (85): promociona un standby (réplica, región secundaria, segundo proveedor). El failover automático necesita una detección de salud fiable para evitar oscilaciones o split-brain.
  • Multirregión (86): mejora la latencia para usuarios globales y sobrevive a caídas regionales, a costa de complejidad, retos de consistencia de datos y dinero. La mayoría de las startups necesitan multi-zona dentro de una región, más copias de seguridad fuera de la región, no un multirregión activo-activo.
  • Ten en cuenta la residencia de datos antes de replicar datos personales entre países.
  • Dependencias de un solo proveedor (un único proveedor de LLM, una única pasarela de SMS): planifica uno secundario.

13.4 Respuesta a incidentes (109)

Niveles de severidad (ejemplo): SEV1 caída total o brecha de datos / movimientos de dinero incorrectos; SEV2 funcionalidad principal caída; SEV3 servicio degradado, existe una alternativa. Roles: Incident Commander (coordina, decide), responsable técnico/de operaciones (corrige), responsable de comunicación (página de estado, clientes, reguladores), Scribe (cronología). En una empresa de una sola persona, haces los cuatro papeles; escribe la checklist por adelantado para no tener que pensar. Secuencia: detectar → declarar → mitigar primero (rollback, desactivar el flag, failover) → comunicar pronto y con regularidad → resolver → hacer seguimiento. En las brechas de datos empiezan a correr plazos legales: por ejemplo, la PDPA de Singapur exige notificar a la PDPC en un plazo de 3 días naturales desde que se determina que la brecha es notificable (consulta 14 · Cumplimiento normativo, gobernanza y auditoría).

13.5 Guardias (110)

Rotación clara, ruta de escalado, runbooks para cada alerta, revisiones de la calidad de las alertas, compensación o descanso tras los avisos. Versión para fundadores en solitario: una herramienta de avisos en el móvil, un contratista de confianza como respaldo y una higiene de alertas implacable.

13.6 Postmortems (111)

Sin culpables: céntrate en cómo el sistema permitió el fallo, no en quién se equivocó. Plantilla: resumen, impacto (usuarios, duración, dinero), cronología, causa raíz y factores contribuyentes (5 porqués), qué salió bien, qué salió mal, dónde tuvimos suerte, acciones con responsables y fechas límite. Haz seguimiento de las acciones hasta completarlas.

13.7 Chaos engineering (87)

Formula una hipótesis ("si el proveedor de LLM falla, los usuarios ven el fallback y nada más se rompe"), limita el radio de impacto, ejecútalo primero en staging y luego, con cuidado, en producción durante los game days; mide y corrige. Empieza con ejercicios de mesa (tabletop) antes de inyectar fallos reales.

Lab 13: Game day

  1. Define el RPO/RTO de cada almacén de datos; configura PITR y copias de seguridad inmutables en otra cuenta.
  2. Simulacro de restauración: restaura la copia de producción en un entorno nuevo; verifica los datos; registra el RTO real.
  3. Game day: el instructor rompe el sistema (despliegue defectuoso, clave filtrada, caída de un proveedor, tabla borrada) sin avisar. Los alumnos gestionan el incidente con roles, página de estado y comunicaciones.
  4. Escribe el postmortem en un plazo de 48 horas.

Definition of Done

Paquete de prompts de IA

  • "Escribe un runbook de incidente para 'base de datos principal no disponible' para esta arquitectura, con los pasos de detección, mitigación, comunicación y recuperación."
  • "Convierte esta cronología del incidente en un postmortem sin culpables con 5 porqués y acciones concretas."