Este principio del pilar de confiabilidad del Google Cloud Framework de la arquitectura proporciona recomendaciones para ayudarte a realizar análisis post mortem eficaces después de fallas e incidentes.
Este principio es relevante para el aprendizaje área de enfoque de confiabilidad.
Descripción general de los principios
Un análisis post mortem es un registro escrito de un incidente, su impacto, las acciones que se tomaron para mitigarlo o resolverlo, las causas raíz y las acciones de seguimiento para evitar que vuelva a ocurrir. 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:
- Crea un informe post mortem
- Captura los hechos
- Identifica y analiza 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:
- 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 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 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 sub secciones.
Realiza análisis post mortem sin culpas
Los análisis post mortem eficaces se enfocan en los procesos, las herramientas y las tecnologías, y no culpan a las personas o los equipos. El propósito de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar a los culpables. Todos cometen 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: “Necesitamos reescribir todo el sistema de backend complicado. Se ha roto semanalmente durante los últimos tres cuartos 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 culpas: “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 de esta versión es bastante largo y es muy difícil completar la capacitación. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".
Haz que todos los públicos previstos puedan leer el informe post mortem
Para cada dato que planeas incluir en el informe, evalúa si es importante y necesario 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 sobreingeniería
Antes de comenzar a explorar soluciones para un problema, evalúa su importancia 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 el proceso post mortem lo más ampliamente posible.
Para asegurarte de que los problemas no permanezcan sin resolver, publica el resultado del análisis post mortem a un público amplio y obtén la asistencia de la administración. El valor de un análisis post mortem es proporcional al aprendizaje que se obtiene después de él. Cuando más personas aprenden de los incidentes, se reduce la probabilidad de que se repitan fallas similares.