Este principio del pilar de fiabilidad del Google Cloud marco de trabajo bien diseñado proporciona recomendaciones para ayudarte a llevar a cabo análisis post mortem eficaces después de fallos e incidentes.
Este principio se aplica al área de aprendizaje de la fiabilidad.
Descripción general de los principios
Un informe post mortem es un registro escrito de un incidente, su impacto, las medidas tomadas para mitigar o resolver el incidente, las causas principales y las medidas de seguimiento para evitar que se repita. El objetivo de un análisis post mortem es aprender de los errores y no culpar a nadie.
En el siguiente diagrama se muestra el flujo de trabajo de un análisis post mortem:
El flujo de trabajo de un análisis post mortem incluye los siguientes pasos:
- Crear un informe post mortem
- Captura los hechos
- Identificar y analizar las causas principales
- Planifica el futuro
- Ejecutar el plan
Realiza análisis post mortem después de eventos importantes y no importantes, como los siguientes:
- Tiempos de inactividad o degradaciones visibles para los usuarios que superen un umbral determinado.
- Pérdida de datos de cualquier tipo.
- Intervenciones de ingenieros de guardia, como la reversión de una versión o el desvío del tráfico.
- Tiempos de resolución superiores a un umbral definido.
- Fallos de monitorización, que suelen implicar la detección manual de incidentes.
Recomendaciones
Define los criterios de análisis post mortem antes de que se produzca un incidente para que todos sepan cuándo es necesario realizar un análisis post mortem.
Para llevar a cabo análisis post mortem eficaces, ten en cuenta las recomendaciones de las siguientes subsecciones.
Realizar análisis post mortem sin buscar culpables
Las post mortem eficaces se centran en los procesos, las herramientas y las tecnologías, y no culpan a personas ni a equipos. El objetivo de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar al culpable. Todos cometemos errores. El objetivo debe ser analizar los errores y aprender de ellos.
En los siguientes ejemplos se muestra la diferencia entre los comentarios que atribuyen la culpa y los que no:
- Comentarios que atribuyen la culpa: "Tenemos que volver a escribir todo el complicado sistema backend. Se ha estado rompiendo semanalmente durante los últimos tres trimestres y estoy seguro de que todos estamos cansados de arreglar las cosas poco a poco. En serio, si me avisan una vez más, lo reescribiré yo mismo".
- Comentarios sin culpabilizar: "Una tarea para reescribir todo el sistema backend podría evitar que se sigan produciendo estos errores. El manual de mantenimiento de esta versión es bastante largo y resulta muy difícil aprenderlo por completo. Seguro que nuestros futuros ingenieros de guardia nos lo agradecerán".
Redactar el informe post mortem de forma que sea legible para todas las audiencias a las que va dirigido
Por cada información que quieras incluir en el informe, evalúa si es importante y necesaria para que el público entienda lo que ha ocurrido. Puedes mover los datos complementarios y las explicaciones a un apéndice del informe. Los revisores que necesiten más información pueden solicitarla.
Evita las soluciones complejas o demasiado elaboradas
Antes de empezar a buscar soluciones para un problema, evalúa su importancia y la probabilidad de que vuelva a ocurrir. Añadir complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede provocar una mayor inestabilidad.
Comparte el análisis post mortem lo más ampliamente posible
Para asegurarte de que los problemas no queden sin resolver, publica los resultados del análisis post mortem para una audiencia amplia y pide ayuda a la dirección. El valor de un análisis post mortem es proporcional al aprendizaje que se produce después de él. Cuando más personas aprendan de los incidentes, menor será la probabilidad de que se produzcan fallos similares.