Toda organización con sistemas en producción acaba teniendo un procedimiento de análisis de incidentes. La diferencia entre las que mejoran y las que repiten los mismos fallos no está en tener el procedimiento, sino en si sus conclusiones cambian algo.
El indicador más fiable de que un análisis no ha servido es que la causa raíz identificada sea «error humano».
Por qué «fallo humano» nunca es la respuesta
Cuando alguien ejecuta un comando destructivo en el entorno equivocado, la pregunta interesante no es por qué se equivocó. Las personas se equivocan; es una constante, no una variable.
Las preguntas que sí producen mejoras son otras: por qué era posible ejecutar ese comando en producción sin una confirmación adicional, por qué los entornos se parecían lo suficiente como para confundirlos, por qué el sistema no detectó la anomalía hasta que la reportó un cliente, y por qué la vuelta atrás tardó cuarenta minutos.
Cada una de esas preguntas señala un cambio concreto y posible. «Que la gente tenga más cuidado» no señala ninguno.
Que no haya culpables no es amabilidad, es método
Conviene desactivar el malentendido habitual: el enfoque sin culpables no existe para proteger sentimientos, existe porque es la única forma de obtener información fiable.
En una cultura donde el análisis puede tener consecuencias personales, la gente narra los hechos de forma defensiva. Se omiten los pasos intermedios, se suavizan los tiempos, no se menciona que hubo un intento previo que empeoró las cosas. Y esos detalles omitidos son precisamente donde está la información útil.
La prueba de que la cultura funciona es sencilla: si en el último año nadie ha reconocido voluntariamente haber provocado una incidencia, no significa que no haya pasado. Significa que no se cuenta.
Qué debe contener el documento
- Impacto en términos de negocio. Cuántos clientes, durante cuánto tiempo, qué no pudieron hacer. No «el servicio X estuvo degradado».
- Cronología con horas exactas, desde que empezó el problema hasta que se resolvió, distinguiendo cuándo empezó de cuándo se detectó. Ese hueco suele ser el hallazgo más valioso.
- Qué se intentó y no funcionó. Los caminos descartados evitan que la próxima persona los repita bajo presión.
- Acciones con responsable y fecha. Sin nombre y sin plazo, una acción es una intención.
Y una regla que cambia mucho el resultado: como máximo tres o cuatro acciones. Un postmortem con quince tareas garantiza que no se hará ninguna. Es preferible cerrar tres cosas de verdad que documentar quince que envejecerán en el backlog.
El seguimiento es la parte que decide
Aquí se separan las organizaciones que aprenden de las que solo documentan. Las acciones derivadas de un incidente compiten por el mismo tiempo que las funcionalidades nuevas, y sin un mecanismo explícito pierden siempre esa competencia.
Lo que funciona: que esas acciones entren en el trabajo planificado con la misma visibilidad que el resto, y una revisión periódica corta donde se comprueba qué se ha cerrado. Cuando alguien tiene que responder mensualmente por las acciones pendientes de incidentes, se cierran.
Qué mirar en conjunto
Un incidente aislado dice poco. Diez incidentes leídos juntos dicen mucho: si la mitad tienen que ver con despliegues, el problema está en el proceso de entrega; si predominan los tiempos de detección largos, el problema es la monitorización; si se repite el mismo componente, hay deuda técnica localizada con nombre y apellidos.
Esa lectura agregada, hecha una vez por trimestre, suele ser más rentable que cualquier análisis individual.
¿Vuestros incidentes se repiten? Revisemos qué os están diciendo →
Sigue leyendo
- Guardias on-call: cómo diseñarlas sin quemar al equipo
- Cuatro métricas para saber si tu DevOps funciona de verdad
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.