Después de una caída hay dos caminos. Uno termina con una persona señalada y un sistema exactamente igual de frágil que antes. El otro termina con un sistema un poco mejor y un equipo que entiende algo más de lo que opera. La diferencia entre ambos no es el talento de quien lo analiza, sino el método y, sobre todo, el clima en el que se hace.
Ese segundo camino es el postmortem sin culpables: un análisis posterior al incidente que busca entender qué pasó y por qué tenía sentido hacerlo así en el momento, en lugar de averiguar quién se equivocó. No es tanto una cuestión de amabilidad, sino más bien una forma de trabajar que produce mejor información, y la información es lo único que permite que el próximo incidente cueste menos.
Qué es un postmortem sin culpables y por qué funciona mejor
El capítulo sobre cultura de postmortem del libro de Site Reliability Engineering de Google parte de un supuesto sencillo: todas las personas implicadas actuaron de buena fe con la información que tenían en ese momento. Si se acepta esa premisa, la pregunta deja de ser quién falló y pasa a ser qué condiciones hicieron razonable esa decisión. El objetivo declarado es documentar el incidente, entender las causas que contribuyeron y dejar acciones eficaces para reducir la probabilidad o el impacto de que se repita.
Tampoco es un documento para archivar. Un postmortem que nadie lee ni consulta cumple el trámite y pierde el propósito. Por eso conviene que sea breve, honesto y fácil de encontrar.
Cuando un análisis se convierte en una búsqueda de responsables, las personas aprenden rápido a protegerse. Los incidentes pequeños dejan de reportarse, los detalles incómodos se omiten y las versiones se suavizan. El resultado es paradójico: el equipo pierde la única fuente fiable que tiene para entender su propio sistema, justo la que más necesita. Las organizaciones que castigan el error no tienen menos errores, solo tienen menos información sobre ellos.
Por eso la cultura sin culpables es una condición técnica del análisis. Sin seguridad para contar lo que pasó, la cronología sale incompleta, las causas salen sesgadas y las acciones atacan síntomas.
Cómo se hace: cronología, causas y acciones
Un buen análisis se apoya en tres piezas, y conviene trabajarlas en este orden: primero qué pasó, después por qué pasó y, por último, qué se hará distinto.
La cronología: la parte aburrida que más información da
Todo buen análisis empieza por reconstruir qué ocurrió y en qué orden: cuándo saltó la primera señal, quién la vio, qué se probó, qué se descartó y cuándo volvió el servicio. Es la parte más tediosa de escribir y la que más información aporta, porque obliga a separar lo que se sabía en cada momento de lo que se supo después.
La cronología también evita el error más habitual: contar la historia desde el final. Con el resultado delante, todas las decisiones parecen evidentes y los errores, obvios. Con la secuencia real se ve que quien estaba de guardia tomaba decisiones con datos incompletos, a menudo contradictorios, y bajo presión. Tres hábitos ayudan a conseguirlo. El primero es anotar la hora de cada hecho con una referencia horaria común. El segundo, registrar también lo que no funcionó o no se pudo comprobar. Y el tercero, separar lo que se sabía en cada momento de lo que se supo después. Si en la reconstrucción faltan datos, esa carencia ya es un hallazgo.
Causas contribuyentes frente a causa raíz
La técnica de los cinco porqués se usa mucho para llegar al origen de un fallo: se pregunta por qué ocurrió algo, luego por qué ocurrió eso, y así sucesivamente. Funciona bien con problemas simples. Con sistemas complejos tiene un límite: construye una cadena lineal donde casi nunca la hay, y termina señalando un único eslabón, que además suele ser una persona.
Lo habitual es que un incidente real sea la suma de varias condiciones que por separado eran inofensivas: una alerta mal calibrada, una documentación desactualizada, un cambio que coincidió con otro, un procedimiento que asumía algo que ya no era cierto. A esas condiciones se las llama causas contribuyentes, y listarlas todas da muchas más palancas de mejora que perseguir una causa raíz única. La propia guía de debriefing que Etsy publicó en abierto, firmada por John Allspaw, invita a revisar el concepto de causa raíz porque centrar la mirada en un operador o en un componente puede ocultar otros factores relevantes.
La misma guía relata un caso ilustrativo. Un ingeniero se culpaba a sí mismo por un fallo y el grupo estaba a punto de archivarlo como error de ingeniería. El facilitador siguió preguntando qué estaba viendo esa persona y en qué se estaba fijando. Resultó que el diseño de un panel de control mostraba un recuento de fallos como si fuera cero. El error de la persona era real, pero era el punto de partida: debajo había un problema de diseño que podía corregirse. Escribir «error humano» en un informe cierra la investigación justo donde empezaba a ser útil.
Cambiar la pregunta cambia lo que se encuentra. Algunos ejemplos de cómo se reformula:
| La pregunta que cierra la investigación | La pregunta que la abre |
|---|---|
| ¿Por qué no se dio cuenta? | ¿Qué estaba viendo en ese momento y qué le mostraba el panel? |
| ¿Quién aprobó el cambio? | ¿Qué información tenía quien lo aprobó y cuál le faltaba? |
| ¿Por qué no siguió el procedimiento? | ¿Decía el procedimiento lo mismo que hacía falta en la práctica? |
| ¿Por qué no avisó antes? | ¿Qué hacía difícil o poco seguro avisar? |
Acciones con responsable y con fecha
Un postmortem sin acciones es una narración. Para que sirva, cada causa contribuyente relevante debería terminar en una acción concreta, con una persona responsable, una fecha y una prioridad. Si una acción no tiene nombre ni fecha, nadie la hará. Y conviene distinguir entre las acciones que reducen la probabilidad de que algo vuelva a pasar y las que reducen su impacto cuando pase, porque suelen requerir esfuerzos distintos.
Este seguimiento tiene además un efecto regulatorio cada vez más visible. Con NIS2, las organizaciones afectadas deben notificar los incidentes por fases, y los plazos escalonados de 24 horas, 72 horas y un mes incluyen un informe final con la causa raíz y las medidas aplicadas. Quien ya tiene la costumbre de analizar sus incidentes con método llega a esa obligación con el trabajo hecho en gran parte.
Cuándo escribir uno y cómo mantenerlo vivo
El libro de SRE de Google recomienda definir de antemano los criterios que disparan un postmortem, para que no dependa del ánimo ni de la gravedad percibida en caliente. Entre los ejemplos que menciona están:
- indisponibilidad o degradación visible para el usuario por encima de un umbral
- cualquier pérdida de datos
- una intervención de guardia, como un rollback o un cambio de tráfico
- un tiempo de resolución largo
- un fallo de monitorización que obligó a descubrir el problema a mano
Cualquier persona interesada puede además solicitar uno. Lo que ocurre después importa tanto como el documento, y el mismo capítulo describe prácticas culturales que ayudan a que se aprenda de verdad: compartir cada mes un postmortem bien escrito, guardarlos en un repositorio donde se puedan buscar, reconocer públicamente los buenos análisis y recrear incidentes pasados como ejercicio de rol con las personas que se incorporan al equipo. Nada de esto exige herramientas sofisticadas, sino constancia.
Por dónde empezar
No hace falta rediseñar toda la gestión de incidentes. Basta con empezar por el siguiente incidente que merezca análisis y seguir una estructura fija. Una plantilla de una página puede ser suficiente:
| Sección | Qué responde |
|---|---|
| Resumen e impacto | Qué pasó, a quién afectó y durante cuánto tiempo, en dos frases. |
| Cronología | Los hechos en orden y con hora, sin interpretar todavía. |
| Qué funcionó | Lo que ayudó a detectar, contener o recuperar. |
| Causas contribuyentes | Los varios factores que se combinaron, no una sola causa. |
| Qué nos sorprendió | Lo que creíamos saber del sistema y no era así. |
| Acciones | Qué se hará, con responsable, fecha y prioridad. |
Una pista para el primer análisis: elegir un incidente real y reciente, aunque fuera pequeño, y medir si en el documento aparecen más preguntas sobre el sistema que sobre las personas. También conviene contrastar lo aprendido con lo que se haya probado en simulacros, como los que recomendábamos en el artículo sobre pruebas de recuperación de backup, donde cada restauración fallida es ya un pequeño postmortem en miniatura.
Si tu equipo gestiona infraestructura propia o ajena y quiere construir esta disciplina, o necesita apoyo para operar con ella, en Irontec trabajamos con el equipo de infraestructuras cloud y servicios IT gestionados para acompañar a organizaciones en la operación de sus entornos. Un postmortem bien hecho no cierra el incidente, hace que el siguiente cueste menos.
