Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Postmortem y acciones preventivas
Cierra con un postmortem sin culpa que transforme la causa técnica en controles, pruebas y observabilidad verificables.
30 min aprox.
05Decisión de diseñoPostmortem y acciones preventivas
Cierra con un postmortem sin culpa que transforme la causa técnica en controles, pruebas y observabilidad verificables.
+
Postmortem y acciones preventivas
Cierra con un postmortem sin culpa que transforme la causa técnica en controles, pruebas y observabilidad verificables.
El postmortem reconstruye impacto, detección, timeline, causa raíz y factores contribuyentes con evidencia. Evita 'error humano' como causa final: pregunta qué guardrail, test o diseño permitió que una acción normal causara daño. Separa acciones correctivas por prevenir, detectar, mitigar y aprender, con propietario y fecha.
Cada acción debe tener condición de cierre. 'Mejorar monitorización' no sirve; 'alertar si p95 supera 24 min durante dos runs y enlazar el Query Profile' sí. Actualiza runbooks, añade una prueba de regresión con distribución representativa y valida el fix bajo carga. Comparte el aprendizaje sin incluir datos sensibles del incidente.
actions:
- id: INC-2041-A1
class: prevent
owner: data-orders
change: "test de skew con 45 % de claves nulas"
done_when: "p95 de tareas < 3x mediana en CI de rendimiento"
- id: INC-2041-A2
class: detect
owner: platform-observability
change: "alerta de p95 runtime y enlace a statement_id"
due: 2026-08-05Una acción se cierra con evidencia; no marques completado sólo por crear un ticket.
¿Qué hace verificable la acción 'añadir una alerta'?
Profundiza
Un postmortem útil explica cómo el sistema permitió el incidente, no quién cometió el último error. La causa raíz rara vez es una persona o una única línea: incluye condiciones técnicas, señales ausentes, controles que no funcionaron y decisiones razonables con información incompleta. El documento separa hechos del timeline, hipótesis confirmadas, factores contribuyentes e impacto. Cada acción debe cambiar una propiedad verificable del sistema y tener owner, prioridad, fecha y evidencia de cierre. Añadir monitorización no basta si nadie sabe qué umbral representa daño ni qué runbook ejecutar. La revisión termina cuando los aprendizajes se convierten en tests, guardrails, observabilidad o diseño, no cuando se publica una narrativa elegante.
Condición técnica u organizativa que aumentó probabilidad, impacto o tiempo de recuperación sin ser por sí sola causa suficiente.
Permite corregir varias defensas débiles en lugar de buscar una única explicación simplista o una persona culpable.Tarea correctiva con responsable, fecha y una evidencia concreta que demuestra que cambió el comportamiento del sistema.
Transforma aprendizaje en reducción de riesgo y evita cerrar promesas vagas sin comprobar su eficacia.Intervalo entre el inicio del impacto y el momento en que una señal accionable llega al equipo responsable.
Muestra si observabilidad y ownership permitieron reaccionar antes de que el daño creciera significativamente.Resumen
Puntos clave
- Describe mecanismos y condiciones, no culpas.
- Convierte acciones en resultados verificables con propietario.
- Añade una prueba que reproduzca el patrón causal.
Evita
- Usar 'formar al operador' como única acción ante un sistema sin guardrails.
- Cerrar tareas por despliegue sin verificar que el indicador cambió.