Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a realizar análisis post mortem eficaces después de fallas e incidentes.
Este principio es relevante para el área de enfoque de aprendizaje de la confiabilidad.
Descripción general del principio
Un análisis post mortem es un registro escrito de un incidente, su impacto, las medidas que se tomaron para mitigarlo o resolverlo, 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:
- Crear análisis post mortem
- Captura los hechos
- Identificar y analizar las causas raíz
- Planifica para el futuro
- Ejecute 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 el usuario que superen un umbral determinado.
- Pérdidas de datos de cualquier tipo
- Intervenciones de los ingenieros de guardia, como una reversión de la versión o un cambio de ruta 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 las autopsias antes de que ocurra un incidente para que todos sepan cuándo es necesaria una autopsia.
Para realizar análisis post mortem eficaces, ten en cuenta las recomendaciones de las siguientes subsecciones.
Realiza análisis post mortem libres de culpas
Los análisis post mortem eficaces se enfocan en los procesos, las herramientas y las tecnologías, y no culpan a las personas ni a los equipos. El propósito de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar quién es 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 asignan culpas y los comentarios sin culpas:
- Comentarios que asignan culpas: "¡Tenemos que volver a escribir todo el complicado sistema de backend! Se ha estado rompiendo semanalmente durante los últimos tres trimestres y estoy seguro de que todos estamos cansados de arreglar las cosas de a poco. En serio, si me llaman una vez más, lo reescribiré yo mismo…"
- Comentarios sin culpas: "Un elemento de acción para reescribir todo el sistema de backend podría evitar que estas páginas sigan ocurriendo. El manual de mantenimiento de esta versión es bastante largo y es muy difícil capacitarse por completo. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".
Haz que el informe de análisis post mortem sea legible para todos los públicos objetivo
Para cada dato que planees incluir en el informe, evalúa si esa información es importante y necesaria para ayudar al público a comprender lo que sucedió. Puedes mover los datos y las explicaciones complementarios a un apéndice del informe. Los revisores que necesiten más información pueden solicitarla.
Evita las soluciones complejas o con exceso de ingeniería.
Antes de comenzar a explorar soluciones para un problema, evalúa la importancia del problema y la probabilidad de que vuelva a ocurrir. Agregar complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede aumentar la inestabilidad.
Comparte la autopsia con la mayor cantidad de personas posible
Para asegurarte de que los problemas no queden sin resolver, publica el resultado 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.