intermediate Por StackPractices
Postmortems Sin Culpa — Aprendiendo de Incidentes Sin Culpar
Guía práctica sobre postmortems sin culpa: capturar timelines, identificar causas raíz, escribir seguimientos accionables y construir una cultura de mejora continua a partir de interrupciones.
Nota para desarrolladores hispanohablantes: Esta guía incluye ejemplos y convenciones de nomenclatura adaptadas a equipos que trabajan en español. Cuando existen diferencias significativas en terminología técnica entre el inglés y el español, se indican explícitamente para facilitar la comunicación en equipos multiculturales.
Descripción General
Un postmortem es una revisión estructurada de un incidente que se enfoca en qué pasó, por qué pasó y cómo prevenir que vuelva a pasar. El aspecto “sin culpa” es crítico: las personas no causan incidentes; los sistemas y procesos sí. Al remover la culpa, creas seguridad psicológica que lleva a análisis honesto, exhaustivo y a mejoras reales.
Esta guía cubre el proceso de postmortem, estructura de plantilla, técnicas de facilitación y responsabilidad de seguimiento.
Cuándo Usar
- Un incidente de Sev2 o superior ha sido resuelto
- Ocurrió un near-miss que pudo haber sido una interrupción mayor
- Un incidente Sev1 se repite (indicando que una solución anterior falló)
- Quieres construir proactivamente una cultura de aprendizaje
- Una alerta disparó pero no paginó (probando tu detección)
Conceptos Clave
| Concepto | Descripción |
|---|---|
| Sin Culpa | Enfocarse en fallas de sistema, no en errores individuales |
| Causa Raíz | La razón fundamental por la que un incidente fue posible |
| Factores Contribuyentes | Condiciones que empeoraron o hicieron más probable el incidente |
| Action Items | Seguimientos específicos, asignados, con fechas límite |
| Timeline | Registro minuto a minuto del incidente |
| Five Whys | Cuestionamiento iterativo para profundizar hasta la causa raíz |
Timeline del Postmortem
| Fase | Cuándo | Duración |
|---|---|---|
| Agendar | Dentro de 24 horas de la resolución | 5 minutos |
| Borrador | Dentro de 48 horas | 1-2 horas |
| Revisar | Dentro de 72 horas | 1 hora |
| Compartir | Dentro de 1 semana | Continuo |
| Seguimiento | 30 días después | 30 minutos |
Proceso de Postmortem Paso a Paso
1. Agenda Prontamente
Programa la reunión mientras la memoria es fresca:
## Checklist de Agendamiento de Postmortem
- [ ] Agendado dentro de 48 horas de la resolución
- [ ] Todos los respondedores del incidente invitados (asistencia obligatoria)
- [ ] Stakeholders relevantes invitados (asistencia opcional)
- [ ] Dueño del borrador/timeline asignado con anticipación
- [ ] Pre-read enviado 2 horas antes de la reunión (borrador de timeline)
- [ ] Reunión protegida: sin culpa, sin juicio, sin castigoPrincipios de agendamiento:
- No esperes más de 72 horas. Los detalles se desvanecen rápidamente.
- Incluye a todos los que estuvieron involucrados en la respuesta.
- Haz opcional la asistencia de personas no directamente involucradas.
- Envía un pre-read para que los asistentes puedan revisar antes de la reunión.
2. Construye el Timeline
El timeline es la base del postmortem:
## Plantilla de Timeline de Incidente
| Hora (UTC) | Evento | Fuente |
|------------|--------|--------|
| 14:30:00 | Despliegue de v2.3.1 a producción | Logs de CI/CD |
| 14:35:00 | Primer pico de error detectado | Monitoreo |
| 14:37:00 | Alerta PagerDuty: HighErrorRate | Sistema de alertas |
| 14:38:00 | Ingeniero de guardia reconoció alerta | PagerDuty |
| 14:45:00 | Incidente declarado, #incident-2024-001 creado | Slack |
| 14:50:00 | Hipótesis: despliegue reciente causó problema | Discusión del equipo |
| 14:55:00 | Rollback a v2.3.0 iniciado | Logs de CI/CD |
| 15:02:00 | Tasa de error retornando a línea base | Monitoreo |
| 15:10:00 | Servicio completamente recuperado, monitoreo verde | Monitoreo |
| 15:15:00 | Incidente cerrado | Sistema de seguimiento de incidentes |Mejores prácticas de timeline:
- Construye a partir de logs, no de memoria. Los logs no olvidan.
- Incluye detección, respuesta y tiempos de recuperación.
- Nota cada decisión y quién la tomó.
- Incluye los períodos “silenciosos” donde nada sucedió.
- La zona horaria debe ser consistente (UTC recomendado).
3. Identifica Factores Contribuyentes
Usa los Five Whys para encontrar causas sistémicas:
## Ejemplo de Five Whys
**Problema:** El servicio de pagos devolvió errores 500 por 35 minutos.
**Por qué 1:** ¿Por qué el servicio de pagos devolvió 500s?
- El pool de conexiones a base de datos estaba agotado.
**Por qué 2:** ¿Por qué el pool de conexiones estaba agotado?
- Una nueva funcionalidad agregó una consulta de larga duración que retenía conexiones.
**Por qué 3:** ¿Por qué una consulta de larga duración fue desplegada?
- La consulta no fue probada contra el volumen de datos de producción.
**Por qué 4:** ¿Por qué no fue probada contra el volumen de producción?
- Las pruebas de carga no usan tamaños de datos realistas.
**Por qué 5:** ¿Por qué las pruebas de carga no usan datos realistas?
- Los datos de producción se consideran sensibles y no están disponibles en staging.
**Causa Raíz:** Los entornos de prueba carecen de datos similares a producción, permitiendo que regresiones de rendimiento lleguen a producción.Principios de análisis:
- Pregunta “por qué” al menos 5 veces para incidentes Sev1.
- Identifica múltiples factores contribuyentes, no solo una causa raíz.
- Considera factores humanos, brechas de proceso y limitaciones de herramientas.
- Evita “error humano” como causa raíz. Pregunta por qué el humano tomó esa decisión.
4. Escribe el Documento de Postmortem
Usa una plantilla consistente:
# Postmortem: Interrupción del Servicio de Pagos — 2024-06-15
## Resumen Ejecutivo
El 15 de junio de 2024, el servicio de pagos devolvió errores 500 por 35 minutos,
afectando el 12% de intentos de checkout. El problema fue causado por agotamiento
de pool de conexiones introducido en v2.3.1. La recuperación se logró vía rollback.
## Impacto
- **Duración:** 35 minutos (14:35 - 15:10 UTC)
- **Servicios afectados:** Servicio de pagos
- **Impacto a usuario:** 12% de intentos de checkout fallaron
- **Impacto en ingresos:** Estimado $45,000 en transacciones perdidas
## Timeline
| Hora (UTC) | Evento |
|------------|--------|
| 14:30 | Despliegue de v2.3.1 |
| 14:35 | Pico de error detectado |
| 14:37 | Alerta disparada |
| 14:45 | Incidente declarado |
| 14:55 | Rollback iniciado |
| 15:10 | Servicio recuperado |
## Causa Raíz
Los entornos de prueba carecían de volúmenes de datos similares a producción,
permitiendo que una regresión de rendimiento en consultas de base de datos llegara a producción.
## Factores Contribuyentes
1. Límite de pool de conexiones no fue probado bajo carga realista
2. Timeout de consulta no estaba configurado (espera infinita)
3. Umbral de alerta era muy alto (5% errores vs 12% real)
4. Procedimiento de rollback no había sido practicado recientemente
## Lo Que Funcionó Bien
- Error fue detectado dentro de 2 minutos del inicio
- Rollback completado en 8 minutos
- Ingeniero de guardia respondió dentro de 3 minutos
## Lo Que Funcionó Mal
- Umbral de alerta no era lo suficientemente sensible
- Script de rollback requirió intervención manual
- No había circuit breaker para prevenir fallas en cascada
## Action Items
| Item | Responsable | Fecha Límite | Prioridad |
|------|-------------|--------------|-----------|
| Añadir datos similares a producción a staging | Equipo de Plataforma | 2024-07-01 | P1 |
| Establecer timeout de consulta a 5 segundos | Equipo de BD | 2024-06-22 | P1 |
| Bajar umbral de alerta a 1% | Equipo de SRE | 2024-06-20 | P2 |
| Automatizar procedimiento de rollback | Equipo de SRE | 2024-07-15 | P2 |
| Añadir circuit breaker a cliente de pagos | Equipo de Backend | 2024-07-30 | P3 |
## Lecciones Aprendidas
- Las pruebas de rendimiento deben usar volúmenes de datos realistas
- Cada despliegue debería tener una ruta de rollback probada
- Los umbrales de alerta deberían ser lo suficientemente sensibles para detectar problemas temprano5. Facilita la Reunión de Revisión
Corre una discusión productiva y sin culpa:
## Guía de Facilitación de Reuniones de Postmortem
**Antes de la reunión:**
- Envía pre-read 2 horas de anticipación
- Recuerda a asistentes: sin culpa, enfoque en sistemas
**Durante la reunión (60 minutos):**
1. **Lee el resumen en voz alta (5 min)**
- Asegura que todos tengan el mismo contexto
2. **Recorre el timeline (15 min)**
- Clarifica eventos faltantes
- Nota donde detección o respuesta fue lenta
3. **Discute causa raíz y factores contribuyentes (20 min)**
- Usa Five Whys para problemas complejos
- Captura todos los factores contribuyentes
4. **Identifica action items (15 min)**
- Cada action item necesita responsable y fecha límite
- Prioriza basado en impacto y esfuerzo
5. **Cierra con aprendizaje (5 min)**
- ¿Qué haremos diferente la próxima vez?
- ¿Qué cambio de proceso o herramienta habría prevenido esto?
**Después de la reunión:**
- Distribuye el documento final dentro de 24 horas
- Añade action items al sprint/board del equipo
- Agenda seguimiento a 30 días para verificar completitudReglas de facilitación:
- El facilitador debe detener activamente el lenguaje de culpa.
- “¿Quién hizo X?” se convierte en “¿Qué del sistema permitió que X sucediera?”
- No saltes la sección “lo que funcionó bien”. Los incidentes son oportunidades de aprendizaje, no solo fallas.
- Si un action item no es específico y asignable, no es un action item.
6. Rastrea Action Items Hasta Completitud
Los postmortems son inútiles sin seguimiento:
| Checkpoint | Acción |
|---|---|
| Semana 1 | Todos los action items P1 asignados y en progreso |
| Semana 2 | Items P1 completados o escalados |
| Semana 4 | Todos los action items revisados para completitud |
| Mes 3 | Revisita: ¿se ha repetido este tipo de incidente? |
Mejores prácticas de seguimiento:
- Añade action items al mismo backlog que el trabajo de funcionalidades
- Asigna fechas límite realistas basadas en esfuerzo
- Revisa completitud de action items en retrospectives de sprint
- Mide tasa de completitud de postmortems como métrica de equipo
Mejores Prácticas
- Agenda dentro de 48 horas. Los detalles se desvanecen; escribe mientras la memoria es fresca.
- Asume buena intención. Nadie viene a trabajar queriendo causar una interrupción.
- Enfócate en el sistema. ¿Cómo permitió el sistema que esto sucediera?
- Sé específico. “Mejorar testing” no es accionable. “Añadir prueba de carga con 1M filas” sí lo es.
- Comparte ampliamente. Los postmortems deberían ser visibles para toda la organización de ingeniería.
- Rastrea seguimientos. Action items sin completar significan que el postmortem fue una pérdida de tiempo.
Errores Comunes
- Culpar a individuos. Esto destruye seguridad psicológica y reduce calidad de reportes.
- Saltarse postmortems. “Estamos muy ocupados” significa que estás muy ocupado para aprender.
- Action items vagos. “Tener más cuidado” no es una mejora de sistema.
- Esconder postmortems. La transparencia construye confianza con clientes y equipos.
- Ignorar near-misses. Los near-misses son lecciones gratuitas. Aprende de ellos.
Variantes
- Pre-mortem: Análisis hipotético antes del lanzamiento (“¿qué podría salir mal?”)
- Revisión de near-miss: Postmortem para incidentes que no causaron impacto a usuario
- Postmortem de seguridad: Formato especializado para brechas y vulnerabilidades
- Revisión de chaos engineering: Análisis post-juego de fallas inyectadas
FAQ
P: ¿Deberíamos hacer un postmortem para cada incidente? Haz postmortems para todos los incidentes Sev1/Sev2 y near-misses significativos. Sev3/4 pueden manejarse con una retrospectiva ligera o ticket.
P: ¿Qué pasa si alguien cometió un error claro? Pregunta por qué el sistema permitió que el error tuviera tanto impacto. ¿Faltó una guardarrail, paso de revisión o salvaguarda?
P: ¿Cómo manejo postmortems en una cultura de culpa? Comienza con compromiso de liderazgo. Comparte ejemplos de Google, Etsy y Netflix. Enmarca postmortems como aprendizaje, no castigo.
P: ¿Qué pasa si los action items nunca se completan? Trátalos como cualquier otro trabajo. Añádelos a sprints, asigna puntos y revisa completitud en retrospectives.
Conclusión
Los postmortems sin culpa son el motor de la mejora operativa. Al investigar incidentes honestamente, escribir action items específicos y rastrearlos hasta su completitud, conviertes interrupciones en inversiones en confiabilidad.