¿Qué hace útil un postmortem de incidente?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Un postmortem existe para que el siguiente incidente sea menos probable o más corto, no para señalar culpables. Expone el impacto en usuarios con números y una línea temporal precisa desde la primera señal hasta la resolución. Describe las condiciones contribuyentes, técnicas y organizativas, como una alerta ausente, un rollback sin probar o una revisión de cambio saltada por la fecha, con evidencia de cada una. Analiza detección y respuesta por separado: cuánto tardó alguien en saberlo, cuánto tardó en actuar la persona adecuada, qué frenó la mitigación. Cierra con pocas acciones, cada una con dueño y fecha, seguidas hasta completarse, y se comparte ampliamente para que otros equipos aprendan.

Ejemplo

Tras una caída del checkout de 40 minutos, el postmortem registró 12.000 sesiones afectadas, una línea temporal con 18 minutos desde los primeros errores hasta el aviso porque la alerta usaba una ventana de 15 minutos, y un rollback que tardó 15 minutos porque el runbook estaba desactualizado. Acciones: una alerta de tasa de consumo con ventana de 2 minutos, un simulacro trimestral de rollback y desplegar la configuración por el mismo pipeline que el código. Las tres se completaron en un mes y se reportaron.

Errores frecuentes

• Nombrar a una persona como causa y detener ahí el análisis.
• Producir veinte acciones sin dueño.
• Escribir el documento y no comprobar nunca si las acciones se completaron.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.