Cómo escribir un postmortem de infraestructura que tu equipo realmente lea
Guía práctica para crear postmortems de incidentes que generen aprendizaje real. Plantilla, ejemplos y cómo la IA puede automatizar el 80% del trabajo.
El problema con los postmortems: nadie los escribe y nadie los lee
Si le preguntas a cualquier equipo de ingeniería si hacen postmortems después de cada incidente, la respuesta habitual es: "Sí, aunque a veces tardamos un poco en escribirlos."
"Un poco" normalmente significa nunca.
Y si se escriben, el documento suele tener cuatro secciones vacías, un timeline incompleto y una sección de "action items" con tareas que llevan semanas en el backlog sin assignee.
Los postmortems son una de las prácticas más valiosas de la ingeniería moderna y, a la vez, una de las que peor se ejecutan. Este artículo explica por qué, y cómo hacerlo bien.
Qué es un postmortem blameless (y por qué importa)
Un postmortem —también llamado incident review o retrospectiva de incidente— es un análisis estructurado de qué salió mal, por qué, y cómo evitar que vuelva a ocurrir.
El adjetivo blameless (sin culpa) es fundamental. El objetivo no es encontrar al culpable. Es entender el sistema.
Google SRE popularizó este enfoque: "Los errores son esperables en sistemas complejos. Lo que importa es si el sistema estaba diseñado para que alguien pudiera cometer ese error."
Si el deployment fallido de Carlos tumbó producción, la pregunta no es "¿por qué Carlos hizo ese deploy?". La pregunta es: "¿Por qué el sistema permitió que un deploy malformado llegara a producción sin detectarse antes?"
Esta distinción no es solo filosófica. Tiene consecuencias prácticas: los postmortems blameless generan información honesta. Los postmortems con culpables generan versiones edulcoradas donde nadie admite lo que realmente pasó.
La anatomía de un postmortem efectivo
Un buen postmortem tiene cinco secciones, ni más ni menos:
1. Resumen ejecutivo (5 líneas máximo)
¿Qué pasó? ¿Cuándo? ¿Cuánto duró? ¿Qué impacto tuvo?
Ejemplo:
El 15 de enero a las 14:32 UTC, el servicio de pagos experimentó un tiempo de inactividad de 43 minutos. Aproximadamente 2.300 transacciones no pudieron procesarse. La causa raíz fue un cambio en el schema de base de datos que no fue compatible con la versión anterior del código.
2. Timeline detallado
Minuto a minuto desde el primer síntoma hasta la resolución. Con timestamps exactos y acciones tomadas.
Este es el lugar donde se invierte más tiempo, y donde más se aprende. Un timeline bien construido revela:
- ¿Cuánto tardamos en detectar el problema?
- ¿Cuánto tardamos en diagnosticar la causa raíz?
- ¿Cuánto tardamos en implementar la solución?
Cada uno de esos tiempos es una oportunidad de mejora.
3. Causa raíz (con los 5 porqués)
La técnica de los 5 Porqués (popularizada por Toyota) es especialmente útil aquí:
- ¿Por qué falló el servicio de pagos? → Porque el nuevo código era incompatible con el schema de BD
- ¿Por qué el nuevo código llegó a producción siendo incompatible? → Porque los tests de integración no cubren migraciones de schema
- ¿Por qué los tests no cubren migraciones de schema? → Porque el entorno de CI no incluye la BD real
- ¿Por qué el CI no incluye BD real? → Porque "lo pusimos en el backlog hace 6 meses"
- ¿Por qué lleva 6 meses en el backlog sin hacerse? → Porque no teníamos métricas de coste de no-hacerlo
Ahí está: la causa raíz real no fue el deploy de Carlos. Fue una deuda técnica ignorada porque no tenía visibilidad de coste.
4. Impacto cuantificado
Esta sección transforma el postmortem de documento técnico a herramienta de negocio:
- Usuarios afectados: número y % del total
- Transacciones fallidas: volumen y valor económico si aplica
- Coste de ingeniería: horas-persona invertidas en resolución × coste/hora
- Daño reputacional: tickets de soporte, menciones en redes, NPS si aplica
Un incidente de 43 minutos que afecta a 2.300 transacciones de una tienda online con ticket promedio de 60€ implica potencialmente 138.000€ de ventas no realizadas. Eso cambia la conversación sobre si priorizar los tests de integración de BD.
5. Action items (con dueño, fecha y definición de hecho)
La sección más importante y la que más se descuida:
| Acción | Dueño | Fecha | Hecho cuando... | |--------|-------|-------|-----------------| | Añadir tests de migración de schema al CI | @carlos | 2026-02-01 | El pipeline falla si el schema nuevo no es retrocompatible | | Implementar feature flags para deploys gradables | @ana | 2026-02-15 | Los deploys pasan por el 5% de usuarios antes del 100% | | Añadir alerta de anomalía en tasa de errores de pagos | @infra | 2026-01-25 | Se dispara con >1% de errores en ventana de 2 min |
Sin dueño, sin fecha, sin definición de hecho → el action item no existe.
Los errores más comunes en postmortems
Error 1: Escribirlos una semana después
La memoria humana es selectiva. Si el postmortem no se empieza dentro de las 48 horas del incidente, perderás detalles críticos del timeline. Mejor un postmortem incompleto y fresco que uno completo y con recuerdos alterados.
Error 2: Confundir causa inmediata con causa raíz
"El deploy falló porque el código tenía un bug" es la causa inmediata. "El deploy falló porque no tenemos tests de regresión para X" es la causa raíz. La diferencia determina si el action item previene el próximo incidente similar o solo el próximo incidente idéntico.
Error 3: Action items sin dueño
"El equipo debería mejorar el proceso de code review" no es un action item. Es un deseo. Un action item tiene un nombre de persona, una fecha y una definición de éxito.
Error 4: No compartirlos
El postmortem de tu equipo contiene información que podría evitar el mismo error en otros equipos de la empresa. Publicar postmortems internamente (o incluso públicamente, como hace Google o Cloudflare) multiplica el valor del análisis.
Automatizando el 80% del trabajo con IA
La parte más costosa de los postmortems es la construcción del timeline. Requiere:
- Revisar logs de distintas fuentes (Kubernetes, aplicación, infraestructura)
- Correlacionar timestamps entre sistemas con relojes potencialmente desincronizados
- Identificar qué alertas llegaron y en qué orden
- Entender qué acciones tomó el equipo y cuándo
Un ingeniero senior puede tardar 2-3 horas solo en construir un timeline fiable de un incidente de una hora. En un equipo que tiene 2-3 incidentes al mes, eso son 6-9 horas mensuales solo en reconstruir la historia.
La IA puede hacer ese trabajo en segundos:
- Ingiere automáticamente los logs de todos los sistemas afectados
- Correlaciona los eventos por timestamp y servicio
- Identifica el primer síntoma, el punto de escalada y el momento de resolución
- Sugiere la causa raíz basándose en patrones históricos
- Genera el borrador del postmortem completo
El equipo solo necesita revisar, corregir y añadir el contexto humano que la IA no tiene (la conversación de Slack donde alguien dijo "esto huele raro" diez minutos antes de que saltara la primera alerta).
Plantilla de postmortem lista para usar
# Postmortem: [Título del incidente]
**Fecha**: [YYYY-MM-DD]
**Duración**: [X horas Y minutos]
**Severidad**: [P0/P1/P2]
**Autores**: [nombres]
**Estado**: [Borrador / En revisión / Cerrado]
## Resumen
[2-3 frases que cualquier persona de la empresa pueda entender]
## Impacto
- Usuarios afectados: X (Y% del total)
- Duración de degradación: HH:MM
- Coste estimado: X EUR
## Timeline
| Hora | Evento |
|------|--------|
| 14:32 | Primera alerta recibida |
| 14:35 | On-call empieza a investigar |
| ... | ... |
| 15:15 | Servicio restaurado al 100% |
## Causa raíz
[Resultado de los 5 porqués]
## Qué salió bien
- [Lista de cosas que funcionaron: detección rápida, comunicación, rollback, etc.]
## Qué mejorar
- [Lista sin culpables, orientada a sistemas]
## Action items
| Acción | Dueño | Fecha | Hecho cuando |
|--------|-------|-------|--------------|
| | | | |
El postmortem como cultura, no como proceso
Los equipos que más se benefician de los postmortems no son los que los hacen más detallados. Son los que los hacen sistemáticamente, para todos los incidentes (no solo los grandes), y donde todos pueden contribuir sin miedo a represalias.
Cuando los postmortems se convierten en rutina, ocurre algo interesante: el equipo empieza a pensar diferente. Los deploys se diseñan pensando en qué pasaría si fallan. Las alertas se configuran pensando en cuánto tardaremos en detectar X. Las arquitecturas se diseñan para fallar de forma predecible.
Ese cambio de mentalidad —de reactivo a proactivo— es el verdadero valor de los postmortems.
centinelAI genera automáticamente el borrador del postmortem cuando declaras un incidente desde Slack. Pruébalo gratis — instalación en 10 minutos.
Artículos relacionados
¿Listo para reducir el ruido?
Conecta centinelAI en 10 minutos. Gratis para siempre hasta 5 servicios.
Empieza gratis →