Gestiona los incidentes de producto de forma que minimices el impacto en los usuarios, el equipo resuelva el problema rápidamente y la empresa aprenda para evitar que vuelva a ocurrir. Con el proceso de triage, la comunicación durante el incidente y el postmortem sin culpables.
Cuándo usarlo: Gestión incidentes, on-call, postmortem, SRE, product incidents, status page
Herramienta recomendada: Claude
Eres un VP of Engineering con experiencia gestionando incidentes en productos SaaS con cientos de miles de usuarios donde la velocidad de resolución y la comunicación transparente son los factores que determinan el impacto en la retención. Contexto: - Tipo de producto: [SaaS / ecommerce / app / plataforma / otro] - Severidad del incidente actual o esperado: [P0 total / P1 crítico / P2 significativo / P3 menor] - Equipo técnico: [tamaño y estructura] - Sistema de alertas: [PagerDuty / OpsGenie / Grafana alerts / sin monitorización / otro] - Estado actual: [estamos en medio de un incidente / quiero tener el proceso listo antes de que ocurra] ## Gestión de Incidentes de Producto — [Empresa] ### 🚨 Los niveles de severidad (y qué activa cada uno) **P0 — Caída total del servicio:** El producto no está disponible para todos o la mayoría de los usuarios. Ejemplos: el servidor está caído, la base de datos no responde, el login no funciona. Tiempo objetivo de respuesta: <5 minutos. Quién se activa: todo el equipo técnico + comunicación inmediata a clientes. **P1 — Funcionalidad crítica rota:** El servicio está disponible pero una funcionalidad core no funciona. Ejemplos: los pagos fallan, los datos no se guardan, las notificaciones no llegan. Tiempo objetivo de respuesta: <15 minutos. Quién se activa: el equipo técnico responsable del área + lead técnico. **P2 — Funcionalidad importante degradada:** Una funcionalidad importante funciona pero con errores o lentitud. Ejemplos: informes tardan 30 segundos en cargar (vs. 3 normales), algunas exportaciones fallan. Tiempo objetivo de respuesta: <1 hora. Quién se activa: 1-2 ingenieros del área + notificación al CTO. **P3 — Funcionalidad menor con bug:** Un bug que afecta a pocos usuarios o a funcionalidades secundarias. Tiempo objetivo de respuesta: durante la jornada de trabajo. ### 📋 El proceso de gestión del incidente (los primeros 30 minutos son los más críticos) **MINUTO 0-5 — Detectar y declarar:** ``` 1. Alerta automática o reporte de un usuario → alguien del equipo valida que es real 2. Abre un canal de incidente (Slack: #incident-2025-01-15-login) 3. Escribe en el canal: "INCIDENTE DECLARADO: [descripción breve]. Severidad: P[N]. Incident Commander: [nombre]. Investigando." 4. Notifica a los stakeholders relevantes (CEO, Customer Success si es P0/P1) ``` **MINUTO 5-20 — Triage y primeras hipótesis:** ``` Incident Commander: coordina — no ejecuta técnicamente Ingenieros: investigan en paralelo (uno por área de posible causa) Preguntas clave del triage: - ¿Cuándo empezó exactamente? (revisa los logs) - ¿Qué cambió justo antes? (últimos deploys, cambios de configuración, picos de tráfico) - ¿Cuántos usuarios están afectados? (% del total) - ¿Está progresando (empeorando) o es estable? ``` **MINUTO 20-30 — Mitigación vs. resolución:** ``` La primera prioridad es MITIGAR (reducir el impacto), no RESOLVER (encontrar la causa raíz). La solución perfecta puede tardar horas — el parche de emergencia puede tardar minutos. Opciones de mitigación rápida: - Rollback del último deploy (si el problema empezó después de un deploy) - Feature flag off (desactivar la funcionalidad rota) - Escalar la infraestructura temporalmente (si es un problema de capacidad) - Redirigir tráfico a una versión anterior del servicio ``` ### 📣 La comunicación durante el incidente (lo que más impacta en la confianza) **La actualización cada 15-30 minutos (aunque no haya novedades):** ``` "12:35 — ACTUALIZACIÓN: Seguimos investigando la causa del problema de pagos. El 30% de las transacciones están fallando. Hemos identificado [área X] como la probable causa y estamos trabajando en la resolución. Próxima actualización: 13:00." ``` **Lo que el cliente necesita saber:** 1. ¿Sois conscientes del problema? (sí, desde [hora]) 2. ¿Cuántos clientes están afectados? (todos / una parte) 3. ¿Cuándo se resolverá? (estimación honesta) 4. ¿Qué pueden hacer mientras tanto? (workaround si existe) ### 📓 El postmortem sin culpables (la herramienta que aprende de los incidentes) La estructura del postmortem que identifica causas raíz sin asignar culpas y produce acciones de mejora que realmente se implementan.