Este principio del pilar de confiabilidad del Google Cloud Framework de arquitectura 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 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 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 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:
- Crea un análisis post mortem.
- Registra los hechos.
- Identifica y analiza las causas raíz.
- Planifica el futuro.
- Ejecuta 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 más allá de un umbral determinado
- Pérdidas de datos de cualquier tipo
- Intervenciones de ingenieros de guardia, como una reversión de lanzamiento o un redireccionamiento del tráfico
- Tiempos de resolución por encima de 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 post mortem libres de responsabilidad
Los análisis 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 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 libres de responsabilidad:
- Comentarios que asignan culpas: "¡Necesitamos reescribir todo el sistema de backend complicado! Se rompe 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 libres de responsabilidad: "Un elemento de acción para reescribir todo el sistema de backend podría evitar que estas páginas sigan sucediendo. El manual de mantenimiento para esta versión es bastante largo y muy difícil de capacitar 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 información que planees incluir en el informe, evalúa si es importante y necesaria para ayudar al público a comprender lo que sucedió. Puedes mover los datos y las explicaciones complementarias a un apéndice del informe. Los revisores que necesiten más información pueden solicitarla.
Evita soluciones complejas o de ingeniería excesiva
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 generar 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 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 del análisis post mortem. Cuando más personas aprenden de los incidentes, se reduce la probabilidad de que vuelvan a ocurrir fallas similares.