Como hacer un Post-mortem sin culpa (Blameless Postmortem )

El objetivo de un post-mortem sin culpa es descubrir qué sucedió en un incidente; para comprender cómo evitar que ocurra un incidente similar en el futuro.

Ninguna empresa esta excenta de experimentar incidentes importantes por mucho que su proceso este orientado a asegurar la calidad de su producto.

Es posible prevenir incidentes , acortar plazos, reducir su impacto. Pero no podemos desaparecer los incidentes por completo en el corto plazo.

Debemos ver los incidentes como una por oportunidad de mejora continua y aprendizaje. De hecho son una oportunidad para descubrir vulnerabilidades, errores, prevenir problemas a futuro y agregar mejoras a nuestros proceso que puedan reducir el impacto para crear un mejor software.

La mejor manera de aprender de los incidentes es instituir un Postmortem de incidentes. Postmortem sin culpa.

¿Qué es un Post-mortem sin culpa?

Un post-mortem de incidentes reúne a las personas o equipos involucrados para analizar más a fondo un incidente y descubrir qué sucedió, por qué sucedió, cómo respondió el equipo y qué se puede hacer para evitar que se repitan los incidentes y mejorar las respuestas futuras.

Los Post-mortem sin culpa hacen todo esto sin culpar a nadie por lo sucedido.

En un Post-mortem sin culpa, se supone que cada equipo y empleado actuó con las mejores intenciones en función de la información que tenían en ese momento. En lugar de identificar y castigar a quien haya cometido un error, los Post-mortem sin culpa se centran en mejorar el rendimiento en el futuro.

Cuando las cosas van mal, buscar a alguien a quien culpar es una tendencia humana natural. Sin embargo, lo mejor para Atlassian es evitar esto, por lo que cuando realiza una autopsia, debe superarlo conscientemente. Asumimos buenas intenciones por parte de nuestro personal y nunca culpamos a las personas por las fallas. La autopsia debe examinar de manera honesta y objetiva las circunstancias que llevaron a la falla para que podamos encontrar la(s) verdadera(s) causa(s) raíz(es) y mitigarlas.
Del Manual de gestión de incidentes de Atlassian

Promotores de los Post-mortem sin culpa, como Google y Etsy, dicen que este enfoque ayuda a fomentar una cultura de aprendizaje y mejora el rendimiento con el tiempo. Señalan que eliminar la parte de caza de brujas del programa crea un cambio psicológico. En lugar de preocuparse por ser despedidos o degradados y tratar de pasar la culpa como una papa caliente, los equipos pueden concentrarse en solucionar los problemas subyacentes.

Los detractores se preguntan si las autopsias sin culpa son realmente posibles (¿no están los humanos preparados para culpar?) y les preocupa que el enfoque no fomente la rendición de cuentas.

¿Son posibles los post-mortem sin culpa?

Una de las principales críticas a los post-mortem sin culpa es que simplemente no son posibles. Después de todo, la culpa y el juicio son naturales. La rendición de cuentas es una parte esencial para dirigir un equipo exitoso. Y los detractores imaginan que los post-mortem sin culpa son como una cena familiar incómoda: todos intentan con poco éxito sonreír y no decir lo que realmente están pensando.

Estas críticas asumen que el objetivo de los post-mortem sin culpa es hacer que los responsables de un incidente se sientan mejor, un objetivo que probablemente sofocaría la conversación real y la rendición de cuentas.

Pero el objetivo real de los post-mortem sin culpa es eliminar el miedo a hacer el ridículo, ser reprendido o incluso perder su trabajo con el objetivo final de fomentar una comunicación honesta, objetiva y centrada en hechos que conduzca a mejores resultados futuros.

Por ejemplo, digamos que ocurrió un incidente porque el Empleado A asumió, incorrectamente, que el Empleado B había implementado una solución. En lugar de pasar el post-mortem tratando de averiguar si el empleado A o el empleado B fueron los culpables en última instancia, un post-mortem sin culpa haría que cada empleado revisara sus procesos de trabajo y procesos de pensamiento para tratar de llegar al meollo del asunto.

Al recorrer el proceso, podemos identificar dónde podemos mejorar. Quizás nuestros procesos de formación no están funcionando. Quizás la documentación era confusa. Tal vez haya una manera de crear controles y equilibrios dentro de nuestros sistemas técnicos para que los empleados no tengan que recordar con quién verificar.

El punto no es que los post-mortem sin culpa nunca identifiquen quién cometió un error. Es que la inocencia abre la comunicación y reconoce que los incidentes de TI son complejos y que puede haber múltiples formas de mejorar en el futuro, sin avergonzar ni despedir al Empleado A.

¿Quién realiza el post-mortem?

El equipo de desarrollo dueño del servicio o aplicación que falló (el equipo que posee el "Servicio defectuoso" que tuvo incidente) es responsable de completar el post-mortem. Ese equipo selecciona a un dueño(champion) del post-mortem.

El dueño del post-mortem lidera el post-mortem a través de la redacción y la aprobación, hasta que se publica. Ellos son responsables de completar el post-mortem.
Generalmente las empresas tienen wikis como Confluence o Notion donde se publican los resultados del Post-mortem.

Pasos para ejecutar un post-mortem sin culpa

Hacer el resumen del problema y la línea de tiempo
Reunirse con el equipo y los involucrados para discutir el tema
Identificar y poner en práctica ideas que solucionen y problema y eviten que vuelva a ocurrir.

Para facilitar la recolección de información y facilitar la lluvia de ideas recomiendo usar el formato: Blameless Postmortem Canvas de David Frink.

Plantilla de Postmortem sin culpa en Miro.

Descripción del Formato

Resumen (completar antes de la reunión)

Un resumen de alto nivel del problema, centrándose en lo que se sabe en este punto y cuál fue el impacto para el cliente. Mantén esto en una oración o dos.

Cronograma aproximado (completar antes de la reunión)
Una cronología aproximada del problema. Dependiendo de qué tan rápido se haya movido el problema, esta línea de tiempo podría abarcar desde unos minutos hasta unas pocas horas o unos pocos días. Si su enfoque principal es mejorar los tiempos de respuesta del equipo durante las emergencias, querrá que esto se reduzca al segundo.

Al capturar la línea de tiempo, asegúrese de incluir:

¿Cuándo se informó el problema y quién/qué proceso?
¿Qué acciones se tomaron
¿Cuándo la comunicación se hizo dentro y fuera del equipo.
Ideas de para encontrar una solución
Cuando se reúna para discutir el tema, invite a todos los que trabajaron en el tema. Esto incluye al equipo de soporte de producción, así como a los miembros del equipo de soporte al cliente que pueden haber estado involucrados.

Revise el resumen, revise la línea de tiempo y agregue las partes faltantes, luego pase a la lluvia de ideas para manejar este tipo incidentes.

Estas preguntas están formuladas para ayudar al equipo a hacerse cargo del problema. Hay algunos problemas 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 ante el desastre.

Detectar: ¿cómo detectamos este problema o un problema como este antes?
Suponga que este problema o un problema muy parecido volverá a ocurrir. ¿Cómo puede el equipo de soporte detectar este problema más rápido y encontrarlo antes que un cliente?

Reaccionar: ¿cómo mejoramos nuestra reacción ante problemas como estos?
Supongamos que se informa el problema. ¿Qué tan rápida fue la reacción? ¿Se perdieron minutos mientras las personas enviaban correos electrónicos tratando de que alguien analizara el problema?

La próxima vez que ocurra este problema, ¿cómo puede el equipo reaccionar más rápido o de manera más organizada?

Solución rápida: ¿cómo detenemos el sangrado más rápido?
Cuando esto vuelva a suceder, ¿hay una 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?

Prevenir: ¿Cómo prevenimos o reducimos el impacto de problemas como en el futuro?
Esta es a menudo la única pregunta que hacen los equipos en una autopsia. Es una pregunta importante y deberías pasar mucho tiempo aquí. Sin embargo, si te limitas a preguntar solo cómo prevenir un problema, no te permite asumir ninguna responsabilidad por las cosas que están bajo tu control (como cómo detectas, reaccionas o solucionas rápidamente un problema).

Mientras hace una lluvia de ideas, no se limite a las soluciones técnicas. Mejor seguimiento, mejores vías de comunicación, mejor formación.

Otras áreas de riesgo: ¿Qué otras áreas comparten esta misma vulnerabilidad?
Cada problema es una pista de dónde está débil su sistema. Lo más probable es que, por cada problema que encuentre, haya docenas al acecho en las sombras, aún por encontrar.

Algo así como si ves una cucaracha en tu cocina. No tienes un problema de una "cucaracha", tienes un problema de "curachas".

Es probable que haya otras partes del sistema que compartan las mismas suposiciones de diseño o, en algunos casos, el mismo código (no es que nadie copie/pegue el código).

Dedique unos minutos a pensar en otros lugares que sean vulnerables de manera similar.

Cuando los equipos están estresados y con exceso de trabajo, se saltarán este paso. Considero que esta es la pregunta más importante que se debe hacer para que el equipo adopte una mentalidad proactiva y para reducir la aparición de problemas en el futuro.

Próximos pasos
Una vez que haya identificado todas las cosas posibles que puede hacer para mejorar la forma en que los problemas se detectan, reaccionan, solucionan rápidamente y previenen… y ha encontrado las otras áreas de su aplicación que necesitan atención… pase a decidir qué acciones tomar. .

Asigne una persona responsable y una fecha para cada acción que planee realizar antes de salir de la reunión.
Si a alguien en la reunión le apasiona tomar una de las medidas, anímalo a hacerlo, incluso si crees que podría no ser lo más importante para arreglar.

Los Torres de Trimurti

Buscar este blog