Captura la línea de tiempo completa del incidente, blast radius, factores contribuyentes y acciones de seguimiento concretas después de incidentes de producción para que los equipos construyan memoria institucional en lugar de repetir las mismas sorpresas. Un postmortem bien escrito separa causa raíz de triggers, evita culpa y produce action items rastreados que previenen recurrencia.
Casos de uso
- Un outage facing customer que duró más de 30 minutos y afectó un porcentaje medible de usuarios
- Un incidente de integridad de datos donde datos incorrectos fueron servidos o almacenados, incluso si el error fue rápidamente corregido
- Un incidente repetido donde el mismo modo de fallo occurred dentro de 90 días de un postmortem anterior
- Un near-miss donde un fallo fue atrapado por automatización antes de que se volviera visible para el usuario pero el riesgo era significativo
- Un incidente triggered por un cambio que pasó todos los CI checks y fue aprobado por un ingeniero senior, revelando una brecha en el proceso de revisión
Funciones principales
- Congela la línea de tiempo factual tan pronto como el incidente se resuelve mientras las memorias están frescas: captura cuándo la alert sonó, cuándo el ingeniero se engageó, cuándo comenzó la mitigación y cuándo se restauró el servicio
- Separa causa raíz (el flaw sistémico subyacente que permitió queoccurriera el incidente) de triggers (el evento inmediato que inició la cascade): resiste conflactar los dos
- Identifica factores contribuyentes: gaps de proceso, automatización faltante, propiedad poco clara o fallos de tooling que hicieron el incidente peor o más difícil de detectar
- Archiva remediaciones específicas y rastreadas con owners nombrados y deadlines: no sugerencias vagas como 'mejorar monitoreo' sino acciones concretas como 'añadir alert en latencia p99 > 2s para /api/checkout'
- Revisa el postmortem en una reunión sin culpa con todas las partes involucradas, actualízalo basado en discusión y publícalo al equipo dentro de 48 horas del incidente
Relacionados
Relacionados
3 Entradas indexadas
Postmortem trigger and root-cause taxonomy
Resume el Apéndice C del workbook SRE (“Results of Postmortem Analysis”): explica cómo Google estandariza postmortems para relacionar disparadores observables versus categorías de causa raíz, priorizando arreglos sistémicos. El apéndice cita estadística histórica 2010–2017 donde empujes binarios (~37 %) y configuración (~31 %) encabezan triggers, más fracciones menores comportamiento usuarios (~9 %), pipelines (~6 %), cambios proveedor (~5 %), degradación (~5 %), capacidad (~5 %) y hardware (~2 %). Otra tabla liga causa raíz: fallos software (~41 %), proceso desarrollo (~20 %), comportamientos complejos (~17 %), planificación despliegue (~7 %), red (~3 %). Úsalas como benchmark heurístico, no SLA.
Canary rollouts
Despliega una nueva versión a un pequeño porcentaje de tráfico de producción primero, monitorea error budgets y latencia contra línea base y automáticamente amplía o hace rollback basado en criterios pre-definidos. Esto mantiene el blast radius de un mal deployment pequeño: particularmente importante cuando agentes de IA están modificando pipelines de deployment donde un solo mal comando podría afectar a muchos usuarios.
Agentic coding vendor readiness review
Convierte guías de fiabilidad de plataforma y agentes de codificación multi-proveedor en una lista antes de estandarizar un stack de IA para código: inventariar SLAs del host SCM (incidentes en githubstatus.com), comparar agentes primarios/reserva (Copilot, Cursor, Claude Code, Codex), verificar observabilidad con Braintrust u otras trazas, y ensayar flujos cuando el host o la API del agente fallen. Cita páginas de estado y cambios de facturación públicos (p. ej. Copilot por uso en github.blog).