Este principio del pilar de confiabilidad del Google Cloud framework de Well-Architected proporciona recomendaciones para ayudarte a realizar análisis post mortem eficaces después de fallas e incidentes.
Este principio es pertinente para el área de enfoque del aprendizaje de la confiabilidad.
Descripción general del principio
Un análisis post mortem es un registro escrito de un incidente, su impacto, las acciones que se tomaron para mitigar o resolver el incidente, las causas raíz y las acciones de seguimiento para evitar que se repita. El objetivo de un análisis post mortem es aprender de los errores y no asignar culpas.
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:
- Cómo crear un análisis post mortem
- Captura los hechos
- Identificar y analizar las causas raíz
- Planifica el futuro
- Ejecute el plan
Realiza análisis post mortem después de eventos importantes y no importantes, como los siguientes:
- Interrupciones o degradaciones visibles para el usuario que superen un umbral determinado
- Pérdidas de datos de cualquier tipo
- Intervenciones de ingenieros de guardia, como la reversión de una versión o el redireccionamiento del tráfico
- Tiempos de resolución superiores a un umbral definido
- Fallas de supervisión, que suelen implicar el descubrimiento manual de incidentes
Recomendaciones
Define los criterios de análisis post mortem antes de que ocurra un incidente para que todos sepan cuándo es necesario realizar un análisis post mortem.
Para realizar análisis post mortem eficaces, ten en cuenta las recomendaciones de las siguientes subsecciones.
Realiza análisis retrospectivos libres de responsabilidad
Las post mortem eficaces se centran en los procesos, las herramientas y las tecnologías, y no culpan a personas o equipos. El propósito de un análisis a posteriori es mejorar tu tecnología y tu futuro, no encontrar a los culpables. 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 asignan culpas y los comentarios sin culpas:
- Comentarios que asignan culpas: "Tenemos que volver a escribir todo el complicado sistema de backend". Se ha descompuesto semanalmente durante los últimos tres trimestres, y estoy seguro de que todos estamos cansados de arreglar las cosas de forma fragmentada. En serio, si me llaman una vez más, lo reescribiré yo mismo…".
- Comentarios sin culpar a nadie: "Una acción para reescribir todo el sistema de backend podría evitar que sigan apareciendo estas páginas. El manual de mantenimiento de esta versión es bastante largo y muy difícil de aprender por completo. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".
Haz que el informe de la revisión posterior al incidente sea legible para todos los públicos previstos
Para cada dato que planees incluir en el informe, evalúa si es importante y necesario para ayudar al público a comprender lo que sucedió. Puedes trasladar los datos y las explicaciones complementarias 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 comenzar a explorar soluciones para un problema, evalúa su importancia y la probabilidad de que se repita. Agregar complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede aumentar la inestabilidad.
Comparte el análisis post mortem con la mayor cantidad de personas posible
Para garantizar que los problemas no queden sin resolver, publica los resultados del análisis post mortem para un público amplio y obtén asistencia de la administración. El valor de un análisis post mortem es proporcional al aprendizaje que se produce después de este. Cuando más personas aprenden de los incidentes, se reduce la probabilidad de que se repitan fallas similares.