Postmortem sin culpa en SRE: cómo reducir incidentes repetitivos
Guía para implantar postmortems efectivos con análisis de causa raíz, acciones verificables y aprendizaje organizativo.
Si un incidente termina sin aprendizaje accionable, volverá a ocurrir. El postmortem sin culpa convierte fallos operativos en mejoras técnicas verificables.
Puntos clave
- Timeline factual del incidente.
- Impacto técnico y de negocio.
- Causa raíz y factores contribuyentes.
Indice del articulo
Indicadores de eficacia del proceso
Métricas para evitar recurrencia
Estructura mínima de un postmortem
- Timeline factual del incidente.
- Impacto técnico y de negocio.
- Causa raíz y factores contribuyentes.
- Acciones preventivas con owner y fecha.
- Plan de validación de eficacia.
Errores que invalidan el proceso
- Buscar culpables en lugar de causas sistémicas.
- Acciones vagas sin responsable ni plazo.
- No verificar si la corrección fue efectiva.
- No compartir aprendizajes entre equipos.
Plantilla de acciones correctivas que sí funciona
- Acción concreta (qué cambia en código, infraestructura o proceso).
- Owner único con fecha compromiso y criterio de finalización.
- Métrica de verificación (ejemplo: reducción de MTTD, caída de recurrencia).
- Revisión posterior a 30 días para confirmar eficacia real.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Definir SLI/SLO por servicio crítico y validar ventanas de error budget.
- Prueba de alertas con escenarios controlados (ruido vs señal).
- Simulación de incidente para validar detección y escalado.
- Revisión de postmortem con acciones preventivas verificables.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Identificar servicios críticos y experiencia objetivo | Definir user journeys y SLI asociados | SLO acordados por servicio crítico |
| Hipótesis | Reducir ruido y acelerar respuesta | Clasificar alertas por severidad y accionabilidad | Plan para reducir alertas irrelevantes |
| Validación | Comprobar detección y recuperación | Game day con escenarios de fallo controlado | MTTD/MTTR dentro de objetivo |
| Escalado | Sostener fiabilidad en crecimiento | Revisión semanal de error budget y postmortems | Incidentes repetitivos en descenso |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Disponibilidad real | Synthetics + SLO | Diario | >= objetivo SLO |
| MTTD | Alerting | Semanal | Tendencia descendente |
| MTTR | Incidentes | Semanal | Tendencia descendente |
| Incidentes repetitivos | Postmortem tracker | Mensual | < 20% |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Error budget | SLO platform | Diario | Consumo < 75% de ventana |
| Ruido de alertas | Pager / alert manager | Diario | Alertas accionables > 60% |
| Diagnóstico | Logs + traces + metrics | Tiempo real | Tiempo a causa raíz en descenso |
| Postmortem | Tracker de acciones | Semanal | Acciones cerradas >= 80% en plazo |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
SLI/SLO y señal de alertas definidos.
Reducción de ruido y mejor detección temprana.
MTTD/MTTR en descenso con playbooks activos.
Ciclo continuo de mejora con error budget.
Riesgos que invalidan resultados
- Definir SLO sin vincularlos a una experiencia de usuario concreta.
- Tener dashboards bonitos pero sin alertas accionables.
- Acumular postmortems sin cerrar acciones preventivas.
- Medir disponibilidad solo por infraestructura y no por transacción.
Recomendaciones de implementación real
- No crear alertas sin playbook asociado.
- Reducir ruido de alertado antes de ampliar cobertura.
- Unificar trazas, logs y métricas por servicio para acelerar diagnóstico.
- Cerrar postmortems solo con acciones implementadas y validadas.
Preguntas frecuentes que suele hacer un equipo técnico
¿Qué diferencia hay entre monitorización y observabilidad?
Monitorización detecta síntomas; observabilidad permite explicar causas. Para SRE necesitas ambas y trazabilidad end-to-end.
¿Cuántos SLO debería definir al inicio?
Empieza con 2-4 SLO por servicio crítico (latencia, disponibilidad, errores) y amplía cuando el proceso madure.
¿Cómo reducir la fatiga del equipo on-call?
Eliminando alertas no accionables, mejorando runbooks y midiendo de forma estricta el ratio señal/ruido.
Preguntas frecuentes
¿Qué es un postmortem sin culpa?
Es un análisis de incidente centrado en causas del sistema y mejoras de proceso, evitando personalizar la responsabilidad en individuos.
¿Cuándo hacer un postmortem?
Tras incidentes de impacto relevante (por ejemplo P1/P2) o cuando hay recurrencia de fallos con impacto operativo.
¿Qué diferencia hay entre RCA y postmortem?
El RCA identifica causa raíz; el postmortem incluye además impacto, decisiones, acciones y seguimiento de mejora.
¿Cómo medir si un postmortem funciona?
Con reducción de recurrencia, mejor tiempo de detección/resolución y cierre efectivo de acciones preventivas.
¿Quieres aplicarlo en tu plataforma?
Si quieres priorizar quick wins y un plan ejecutable para tu equipo, podemos ayudarte con una sesión técnica de 30 minutos.