Lienzo de postmortem sin culpa

Esta plantilla de Post-Mortem "sin culpas" te ayuda a recopilar información sobre los incidentes ocurridos en producción. Seguir este proceso significa que los ingenieros cuyas acciones han contribuido a un accidente pueden dar un relato detallado de:

• qué acciones tomaron a qué hora,

• qué efectos observaron,

• expectativas que tenían,

• suposiciones que habían hecho,

• su comprensión del cronograma de eventos tal como ocurrieron.

• y que puedan dar esta cuenta detallada sin miedo a castigos o represalias.

El postmortem Blameless incluye las siguientes secciones

Paso 1: Resumen (prellenar antes de la reunión)

Un resumen de alto nivel de la incidencia, centrándose en lo que se sabe hasta este momento y en el impacto que tuvo para el cliente. Limítalo a una o dos frases.

Paso 2: Cronograma aproximado (prellenar antes de la reunión)

Un cronograma aproximado de la incidencia. Dependiendo de lo rápido que se moviera la incidencia, este cronograma podría abarcar desde unos minutos hasta unas horas o unos días. Si tu enfoque principal es mejorar los tiempos de respuesta del equipo durante emergencias, querrás que esto se mida hasta el segundo.

Al capturar el cronograma, asegúrate de incluir:

• Cuándo se reportó la incidencia y por quién/qué proceso

• Qué acciones se tomaron

• Cuando se estableció la comunicación dentro y fuera del equipo

Ideas de Remediación

• Cuando te reúnas para discutir la incidencia, invita a todos los que trabajaron en ella. Esto incluye al equipo de soporte para la producción, así como a los miembros del equipo de atención al cliente que pudieran haber estado involucrados.

• Revisa el resumen, revisa la línea de tiempo y añade las partes que falten. Luego, pasa a las ideas de remediación.

• Estas preguntas están formuladas para ayudar al equipo a asumir la responsabilidad del problema. Hay algunas incidencias que parecen estar fuera del control del equipo (el centro de datos pierde energía, etc). Pero incluso en eventos como esos, el equipo aún puede mejorar su reacción al desastre.

Paso 3: Detectar – ¿Cómo detectamos este problema o un problema como este antes?

Asume que este problema o un problema muy similar ocurrirá de nuevo. ¿Cómo puede el equipo de soporte detectar este problema más rápido y encontrarlo antes de que lo haga un cliente?

Paso 4: React – ¿Cómo mejoramos nuestra reacción ante incidencias como estas?

Asume que se ha reportado la incidencia. ¿Qué tan rápida fue la reacción? ¿Se perdieron minutos mientras las personas enviaban correos intentando que alguien revisara el problema?

¿Cómo puede el equipo reaccionar más rápidamente o de manera más organizada la próxima vez que ocurra esta incidencia?

Paso 5: Solución Rápida: ¿Cómo detenemos la hemorragia más rápido?

Cuando esto vuelva a ocurrir, ¿hay un solución alternativa lista que podamos proporcionar al cliente para reducir el impacto del problema?

Si esto es algo que empeora con el tiempo (como un ataque DDoS), ¿tenemos una forma rápida de cerrar las compuertas mientras descubrimos la causa raíz?

Paso 6: Prevenir: ¿Cómo prevenimos o reducimos el impacto de incidencias similares en el futuro?

Esta es a menudo la única pregunta que los equipos hacen en un postmortem. Es una pregunta importante y deberías dedicarle mucho tiempo. Sin embargo, si te limitas a preguntar solo cómo prevenir una incidencia, te permite no asumir ninguna responsabilidad por las cosas que están bajo tu control (como la forma en que detectas, reaccionas o solucionas rápidamente una incidencia).

Mientras haces una lluvia de ideas, no te limites solo a soluciones técnicas. Mejor monitoreo, mejores vías de comunicación, mejor capacitación, asegurarse de que las personas en asistencia al cliente conozcan a las personas en asistencia de producción por su nombre, etc.

Paso 7: Otras áreas de riesgo: ¿Qué otras áreas comparten esta misma vulnerabilidad?

Cada incidencia es una pista de dónde tu sistema es débil. Es probable que, por cada incidencia que encuentres, haya docenas acechando en las sombras, aún por descubrir.

Es como si vieras un ratón en tu cocina. No tienes un problema de "ratón", tienes un problema de "ratones".

Es probable que haya otras partes del sistema que compartan los mismos supuestos de diseño o, en algunos casos, el mismo código (aunque nadie copia/pega código).

Dedica unos minutos a hacer una lluvia de ideas sobre otros lugares que sean vulnerables de manera similar.

Cuando los equipos están estresados y sobrecargados, omitirán este paso. Encuentro que esta es la pregunta más importante que hacer para lograr que el equipo tenga una mentalidad proactiva y reducir la aparición de incidencias en el futuro.

Paso 8: Próximos pasos (Acciones)

Después de haber identificado todas las cosas posibles que puedes hacer para mejorar cómo se detectan, reaccionan, corrigen rápidamente y previenen las incidencias... y haber encontrado las otras áreas de tu aplicación que necesitan atención... pasa a decidir qué acciones tomar.

La forma en que priorizas esto depende de ti. Pero tengo algunos consejos.

Consigue un nombre y una fecha para cada uno que planees ejecutar antes de salir de la reunión

Si alguien en la reunión está entusiasmado con tomar una de las acciones, anímalo a hacerlo, incluso si piensas que podría no ser lo más importante a solucionar.

Nombres y fechas

En general, he encontrado que a los equipos les gusta este ejercicio (siempre que puedas crear un ambiente sin culpas para la reunión). Les gusta analizar el problema y hacer lluvias de ideas para encontrar soluciones. Sin embargo, todos se sienten ocupados y sobrecargados de trabajo. A menos que esta reunión concluya con propietarios y fechas junto a las cosas que deben hacerse, lo más probable es que ninguna de las mejoras ocurra.

Lo que sucederá es que dentro de 3 semanas, cuando el mismo problema ocurra en producción (pero esta vez de manera más grande), alguien dirá: "oh sí, hablamos sobre arreglar eso." No es un gran lugar para estar.

Para combatir eso, simplemente asegúrate de que haya un nombre y una fecha junto a cada acción que el grupo quiera realizar.

Basado en David Frink Blameless Postmortem Canvas.