Cuando el sistema se cae en producción: el runbook, la comunicación durante el incidente y el postmortem que convierte el error en aprendizaje sin buscar culpables.
Cuándo usarlo: Diseñar el proceso completo de incident response: detección, respuesta, comunicación, resolución y el postmortem blameless que convierte cada incidente en aprendizaje.
Herramienta recomendada: Claude
Eres un experto en site reliability engineering y en la gestión de incidentes técnicos con experiencia en sistemas de alta disponibilidad. Necesito diseñar el proceso completo de incident response que minimice el impacto de los fallos y convierta cada incidente en aprendizaje organizacional. **Mi contexto técnico:** [DESCRIBE TU SISTEMA: tipo de aplicación, stack tecnológico, tamaño del equipo de ingeniería, herramientas de monitorización y alerting que ya usas, SLA comprometidos con los clientes, incidentes recientes que hayas tenido] --- Diseña el sistema completo de gestión de incidentes para mi caso: **1. Detección y alerting** La infraestructura que te avisa antes de que lo haga el cliente: - La estrategia de monitorización: los cuatro golden signals de SRE —latencia, tráfico, errores y saturación— y cómo implementarlos en mi stack - El alerting que no genera fatiga: la diferencia entre alertas accionables y ruido, los umbrales dinámicos y cómo evitar que el equipo deje de responder a las alertas porque hay demasiadas - Synthetic monitoring: las pruebas proactivas que detectan la degradación del servicio desde la perspectiva del usuario antes de que el sistema empiece a generar errores internos - On-call rotations: cómo organizar la guardia para que sea sostenible — la rotación, el escalado y el compensation que hace que la guardia no destruya el equipo **2. La clasificación del incidente** No todos los problemas son P1: - Los niveles de severidad: P1/P2/P3/P4 — cómo definirlos según el impacto en los usuarios y el negocio, con ejemplos concretos de qué califica como qué - El incident commander: el rol que lidera la gestión del incidente, sus responsabilidades y por qué es un rol distinto al de quien está resolviendo el problema técnico - La declaración del incidente: cuándo declara formalmente un incidente, quién lo hace y qué activa esa declaración en el proceso **3. El runbook de respuesta** El manual que el equipo sigue bajo presión: - La estructura del runbook: diagnóstico, mitigación, resolución y verificación — los pasos que alguien que no conoce el sistema puede seguir - Los runbooks específicos por tipo de incidente: los escenarios más frecuentes en mi stack y las acciones documentadas para cada uno - Cómo mantener los runbooks actualizados: el proceso que hace que la documentación refleje cómo funciona el sistema hoy, no como funcionaba hace un año - Automated runbooks: cuándo tiene sentido automatizar la respuesta y cómo hacerlo sin que la automatización genere más problemas de los que resuelve **4. La comunicación durante el incidente** El proceso que mantiene informados a todos sin interrumpir la resolución: - El war room y los canales de comunicación: cómo estructurar el canal de Slack o el bridge de voz durante el incidente para que sea útil y no caótico - Los updates de estado: la cadencia, el formato y el tono de los updates internos al equipo de management y los externos a los clientes - La status page: cuándo publicar el incidente, qué nivel de detalle dar y cómo comunicar que el servicio está degradado sin generar más alarma de la necesaria - Cómo hablar con clientes durante un incidente: los mensajes que tranquilizan sin mentir sobre el impacto o el tiempo de resolución **5. La mitigación y resolución** Las decisiones técnicas bajo presión: - La distinción entre mitigación y resolución: restaurar el servicio primero, arreglar la causa raíz después — y por qué confundirlos alarga los incidentes - Los runbooks de rollback: cómo deshacer un deployment que ha provocado el incidente de forma rápida y segura - Feature flags y circuit breakers: las herramientas de mitigación que permiten degradar el servicio de forma controlada mientras se resuelve el problema - Cómo tomar decisiones bajo presión: el framework para elegir entre opciones de mitigación cuando hay información incompleta y el tiempo apremia **6. El postmortem sin culpables** El aprendizaje que justifica haber pasado por el incidente: - La cultura del postmortem blameless: por qué buscar culpables destruye la capacidad de aprendizaje y cómo crear un entorno donde se puede hablar con honestidad - La estructura del postmortem: timeline del incidente, impacto, causa raíz, factores contribuyentes, acciones correctivas y seguimiento - El análisis de causa raíz con los 5 porqués: cómo ir más allá del síntoma y encontrar el fallo sistémico que permitió que el incidente ocurriera - Las action items del postmortem: cómo asegurar que las mejoras identificadas se implementan y no quedan en el backlog indefinidamente **7. La madurez del proceso de incident management** Cómo mejorar el sistema con el tiempo: - Las métricas del incident management: MTTD (mean time to detect), MTTR (mean time to resolve), incident frequency por severidad y % de action items completados - Las revisiones periódicas del proceso: la cadencia para evaluar si el proceso está funcionando y qué ajustar - Chaos engineering: cómo practicar la resiliencia induciendo fallos controlados — los primeros pasos para un equipo que nunca ha hecho gamedays Termina con el template de postmortem para el último incidente que tuvimos o para el escenario de incidente más probable en mi sistema, con todos los campos que el equipo necesita rellenar.