No necesitas un equipo de mando ni una reunión de dos horas para aprender de un fallo en producción. Una revisión breve puede conservar lo que vivieron los usuarios, reconstruir la cronología y proponer un cambio del sistema que reduzca la probabilidad o el impacto de repetición. El objetivo no es demostrar que deberías haberlo previsto, sino mejorar el entorno de la próxima decisión.
| Sección | Pregunta | Evidencia útil |
|---|---|---|
| Resumen | ¿Qué falló y a quién afectó? | Inicio, fin, duración y efecto de negocio |
| Detección | ¿Cómo te enteraste? | Alerta, prueba sintética, informe o descubrimiento manual |
| Cronología | ¿Qué observaste e hiciste? | Despliegues, logs, cambios y mitigaciones fechadas |
| Condiciones | ¿Por qué fue posible o difícil de detectar? | Prueba ausente, valor inseguro, dependencia o runbook |
| Seguimiento | ¿Qué reducirá la probabilidad o el impacto? | Acción concreta, responsable, plazo y prueba |
“La importación terminó con cero filas después de que el proveedor cambiara un campo” es una observación; “olvidé probarlo” no explica el sistema. Pregunta por qué el cambio pasó inadvertido, por qué el proceso lo consideró exitoso y qué control habría avisado antes de afectar datos. Varias condiciones pueden combinarse; no fuerces una única causa raíz.
Este principio también sirve en solitario. La vergüenza lleva a ocultar incidentes menores y casi fallos. Asume que tomaste la mejor decisión posible con la información y herramientas disponibles entonces. Después mejora el sistema: validación de contrato, valor predeterminado seguro, rollback, alerta, prueba de backup o un runbook más claro. La responsabilidad consiste en cambiar condiciones, no en castigarte.
“Reescribir la integración” no es un plan. Mejor: “rechazar una versión de esquema desconocida y alertar antes de escribir registros”. Pon una fecha realista y define la prueba de finalización: test, señal del panel, ejercicio de restauración o revisión del runbook. Una acción importante completada vale más que una lista eterna.
Resumen: … Impacto: … Detección: … Cronología: … Condiciones contribuyentes: … Qué funcionó: … Acciones: responsable / fecha / evidencia. Guárdala junto al runbook, elimina identificadores de clientes y revisa el trabajo hasta verificarlo.
Un postmortem individual puede tomar diez minutos y una página. Conserva evidencia, describe el impacto, explica las condiciones del sistema sin culpar y comprométete con una mejora verificable. Solo sirve si la lección cambia una prueba, protección, alerta o recuperación.