Análisis a toro pasado de los incidentes

En Atlassian realizamos los análisis a toro pasado irreprochables para asegurarnos de comprender y remediar el origen del problema de cada incidente con una gravedad de nivel 2 o superior. A continuación te mostramos una versión resumida de nuestra documentación interna que describe cómo llevamos a cabo los análisis a toro pasado en Atlassian.

¿Qué es un análisis retrospectivo?

Un análisis a toro pasado es un registro escrito de un incidente que describe:

• El impacto de un incidente.

• Las acciones realizadas para mitigar o resolver el incidente.

• El origen del problema del incidente.

• Las acciones de seguimiento realizadas para evitar que el incidente se vuelva a repetir.

En Atlassian, supervisamos todos los análisis retrospectivos con actividades de Jira para garantizar que se completan y aprueban. Si tus necesidades son menos complejas, puedes optar por un sistema más sencillo, como una página de Confluence, para cada análisis retrospectivo.

¿Qué hacemos en los análisis a toro pasado?

Los objetivos de un análisis a toro pasado son comprender los orígenes que han contribuido a causar el problema, documentar el incidente para futuras referencias y el descubrimiento de patrones y realizar acciones preventivas efectivas para reducir la probabilidad o el impacto de la recurrencia.

Para que los análisis retrospectivos sean efectivos a la hora de reducir incidencias repetidas, el proceso de revisión debe fomentar que los equipos identifiquen los orígenes del problema y los solucionen. El método exacto depende de la política corporativa de tu equipo; en Atlassian, hemos encontrado una combinación de métodos que funciona con nuestros equipos de respuesta ante incidentes: 

• Las reuniones presenciales ayudan a llevar a cabo análisis adecuados y a sincronizar al equipo con respecto a qué necesita solución.

• Las aprobaciones de los análisis a toro pasado de los gestores de los equipos de entregas y operaciones fomentan a los equipos a llevarlos a cabo de forma minuciosa.

• Las "acciones prioritarias" designadas tienen un objetivo de nivel de servicio (SLO) de unas 4 u 8 semanas de duración, según el servicio, con recordatorios e informes para garantizar que se lleven a cabo.

Participar en este proceso y asegurarse de que sea efectivo requiere un compromiso a todos los niveles de la organización. Nuestros gestores y directores de ingeniería optaron por aprobadores y SLO para la resolución de acciones en sus áreas. Este sistema solo codifica e intenta aplicar sus decisiones.

¿Cuándo es necesario un análisis a toro pasado?

Llevamos a cabo análisis a toro pasado con incidentes de gravedad 1 y 2. De lo contrario, son opcionales.

Durante la resolución de la incidencia o justo después, el propietario del análisis a toro pasado crea una nueva incidencia de análisis a toro pasado.

¿Quién lleva a cabo un análisis a toro pasado?

El equipo de entregas del servicio que ha fallado (el equipo que posee el "Faulty Service" [Servicio defectuoso] en la incidencia) es el responsable de llevar a cabo el análisis a toro pasado. Este equipo selecciona al propietario del análisis a toro pasado y asigna la incidencia de análisis a toro pasado.

• El propietario del análisis retrospectivo gestiona dicho análisis desde la redacción y la aprobación hasta que se publica. Es responsable de llevar a cabo el análisis retrospectivo. 

• Los aprobadores de análisis a toro pasado son los encargados de revisar y aprobar estos análisis, y se espera que prioricen las acciones de seguimiento en su backlog.

Tenemos una página de Confluence que enumera a los aprobadores de análisis a toro pasado (opcionales y obligatorios) por grupo de servicio, que normalmente se corresponden con un producto de Atlassian (p. ej., Bitbucket Cloud).

¿Cómo se supervisan de las acciones de análisis a toro pasado?

Por cada acción que deriva de un análisis a toro pasado:

• Emitimos una actividad de Jira en el backlog del equipo que la posea. Todas las acciones de análisis retrospectivo deben supervisarse en Jira.

• Las vinculamos desde la incidencia del análisis a toro pasado como "Priority Action" (Acción prioritaria) (para correcciones de origen del problema) o "Improvement Action" (Acción de mejora) (para mejoras no relacionadas con el origen del problema).

Creamos informes personalizados con las API de Jira REST para supervisar el número de incidentes por cada nivel de gravedad cuyo origen del problema se ha solucionado mediante las acciones prioritarias del análisis a toro pasado. Los gestores de ingeniería de cada departamento revisan esta lista con regularidad.

Proceso del análisis a toro pasado

Llevar a cabo el proceso de análisis a toro pasado incluye crear una incidencia de análisis a toro pasado, convocar una reunión de análisis a toro pasado, capturar acciones, conseguir la aprobación y (de manera opcional) comunicar el resultado.

El propietario del análisis a toro pasado es responsable de llevar a cabo las siguientes tareas:

1. Crear un análisis a toro pasado y vincularlo con el incidente.

2. Editar la incidencia de análisis a toro pasado, leer las descripciones de los campos y completar los campos.

3. Para determinar el origen del problema del incidente, utilizar la técnica de los "cinco porqués" con el fin de atravesar la cadena de causalidad hasta encontrar el origen verdadero y real del problema. 

4. Programar la reunión de análisis a toro pasado. Invitar al equipo de entregas, a los equipos afectados y a las partes interesadas, mediante la plantilla de invitación a reuniones.

5. Reunirse con el equipo y revisar la programación de la reunión que se incluye más adelante.

6. Realizar un seguimiento con el responsable de los gestores de desarrollo para obtener el compromiso de realizar acciones específicas que evitarán esta clase de incidente.

7. Crear una actividad de Jira para cada acción del backlog de los equipos que las poseen. Vincúlalas desde la incidencia del análisis retrospectivo como "Priority Action" (Acción prioritaria) (para correcciones de origen del problema) o "Improvement Action" (Acción de mejora) (para otras mejoras).

8. Buscar los aprobadores adecuados en Confluence y añadirlos al campo "Approvers" (Aprobadores) del análisis retrospectivo. 

9. Seleccionar la transición "Request Approval" (Solicitar aprobación) para solicitar la aprobación a los aprobadores designados. La automatización realizará comentarios sobre la incidencia que incluyan instrucciones para los aprobadores. 

10. Realizar el seguimiento necesario hasta que se apruebe el análisis a toro pasado.

11. Cuando se aprueba el análisis a toro pasado, la automatización crea un blog de análisis a toro pasado de borrador en Confluence para editarlo y publicarlo. Mediante la creación de blogs de análisis a toro pasado se comparten las lecciones aprendidas con esfuerzo, lo que multiplica su valor.

Una vez terminado el proceso de análisis a toro pasado, el equipo de desarrollo prioriza las acciones como parte de su backlog habitual, según el SLO del equipo.

Reuniones de análisis a toro pasado

Hemos descubierto que reunir al equipo para tratar lo aprendido de manera conjunta se consigue un análisis más profundo de los orígenes del problema. A menudo se lleva a cabo mediante videoconferencia debido a la dispersión de nuestros equipos y, a veces, se realiza en grupos en casos en los que los incidentes afectan a grandes grupos de personas.

Agenda recomendada:

1. Recuerda al equipo que los análisis a toro pasado son irreprochables y por qué lo son

2. Confirma el cronograma de los eventos

3. Confirma el origen del problema

4. Genera acciones con "creatividad": "¿Qué podríamos hacer para evitar que esta clase de incidente se produzca en el futuro?"

5. Pregunta al equipo qué fue bien, qué pudo haber ido mejor y en qué aspecto tuvisteis suerte.

Plantilla de reserva de calendario sugerida:

Te invito a unirte a mí en un análisis a toro pasado irreprochable sobre <vínculo al incidente>, en la que <resumen del incidente>.

Campos de incidencia del análisis retrospectivo

Nuestra incidencia de análisis a toro pasado posee una gran variedad de campos para favorecer la recopilación de toda la información importante relativa al incidente antes de celebrar la reunión de análisis a toro pasado. A continuación incluimos algunos ejemplos sobre cómo completar estos campos.

Origen del problema y causas inmediatas

Cuando estás escribiendo o leyendo un análisis a toro pasado, es necesario distinguir entre el origen del problema y las causas inmediatas

• Las causas inmediatas son los motivos que han llevado directamente a este incidente.

• El origen del problema es el motivo que se encuentra en el lugar óptimo de la cadena de eventos sobre el que si se aplica un cambio se evitará esta clase completa de incidente.

Un análisis retrospectivo tiene el objetivo de descubrir el origen del problema y decidir cómo mitigarlo. Encontrar ese lugar óptimo de la cadena de eventos es la auténtica razón de un análisis retrospectivo. Usa una técnica como la de los cinco porqués para "subir por la cadena" y descubrir el origen del problema. 

A continuación te mostramos unos ejemplos seleccionados de causas inmediatas y orígenes del problema:

Categorías de orígenes del problema y sus acciones

Usamos estas categorías para agrupar las causas raíz y debatir las posibles acciones en cada caso.  

Causas raíz con dependencias

Cuando tu servicio tiene un incidente porque una dependencia falla, el lugar del fallo y el origen del problema dependerán de si la dependencia es interna de Atlassian o de terceros y de qué se puede esperar razonablemente del rendimiento de la dependencia.

Si es una dependencia interna, pregúntate cuál es el objetivo de nivel de servicio (SLO)  de la dependencia:

• ¿La dependencia ha incumplido su SLO? 

  • El fallo reside en la dependencia y deben aumentar su fiabilidad.

• ¿La dependencia se ha mantenido en el SLO, pero el servicio ha fallado igualmente? 

  • Tu servicio debe aumentar su resistencia.

• ¿La dependencia no tiene un SLO?

  • ¡Necesita uno!

Si es una dependencia de terceros, pregúntate qué se puede esperar razonablemente de la disponibilidad, latencia y demás características de esta dependencia de terceros.

• ¿La dependencia de terceros ha excedido nuestras expectativas (en sentido negativo)?

  • Nuestras expectativas eran incorrectas. 

    • ¿Estamos seguros de que no volverá a suceder? P. ej., hemos revisado su RCA (Análisis de origen del problema) y estamos de acuerdo con él. En este caso, la acción es su RCA.

    • ¿Necesitamos ajustar nuestras expectativas? En este caso, las acciones son aumentar nuestra resistencia y ajustar nuestras expectativas.

    • ¿Son nuestras expectativas ajustadas inaceptables? En este caso, necesitamos solucionar la desconexión entre requisitos y solución de algún modo, como por ejemplo, buscando otro proveedor.

• ¿La dependencia de terceros se ha mantenido dentro de nuestras expectativas, pero el servicio ha fallado igualmente? 

  • En este caso, tu servicio debe aumentar su resistencia.

• ¿Realmente no tenemos expectativas?

  • El propietario de la dependencia de terceros debe establecerlas y compartirlas con los equipos para que conozcan el nivel de resistencia que deben crear en sus servicios dependientes.

* ¿Por qué "expectativas"? ¿No tenemos acuerdos de nivel de servicio (SLA) con terceros? En realidad, los acuerdos de nivel de servicio (SLA) contractuales con terceros son demasiado bajos para ser útiles al determinar el fallo y la mitigación. Por ejemplo, AWS no publica casi ningún acuerdo de nivel de servicio (SLA) para EC2. Por lo tanto, cuando dependemos de un servicio de terceros, tenemos que tomar una decisión con respecto al nivel de fiabilidad, disponibilidad, rendimiento o cualquier otra métrica clave que esperamos recibir de ellos de manera razonable. 

Acciones de análisis a toro pasado

Sue Lueder y Betsy Beyer, de Google, tienen una presentación y artículo excelentes sobre los elementos de acción del análisis a toro pasado, que usamos en Atlassian para realizar preguntas al equipo.

Trabaja con las siguientes preguntas para ayudarte a garantizar que la revisión tras incidentes (PIR) cubre las correcciones a corto y largo plazo:

"Mitigar futuros incidentes" y "Evitar futuros incidentes" son tu fuente de acciones más probable para abordar el origen del problema. Asegúrate de obtener al menos una de estas.

Asimismo, utilizamos el consejo de Lueder y Beyer sobre cómo formular nuestras acciones de análisis a toro pasado.

Formulación de las acciones de análisis a toro pasado:

La manera correcta de formular una acción de análisis a toro pasado puede marcar la diferencia entre una ejecución sencilla y el retraso indefinido debido a la inviabilidad o a la procrastinación. Una acción de análisis a toro pasado bien elaborada debe tener las siguientes propiedades:

Práctica: expresa cada acción en forma de frase que comience por un verbo. La acción debe traducirse en un resultado útil, no en un proceso. Por ejemplo, "Enumera la lista de dependencias críticas" es una buena acción, mientras que "Investiga las dependencias" no lo es.

Específica: define el alcance de cada acción de la forma más precisa posible, dejando claro qué se incluye en el trabajo.

Delimitada: formula cada acción de manera que se pueda indicar cuándo se ha finalizado, en oposición a dejar la acción en curso o sin fin definido.

Aprobaciones del análisis a toro pasado

Atlassian utiliza el workflow de Jira con un paso de aprobación para garantizar que se aprueben los análisis a toro pasado. Por lo general, los aprobadores son propietarios de servicios u otros gestores con responsabilidad para la gestión de un servicio. La aprobación de un análisis a toro pasado indica:

• el acuerdo con los hallazgos de la revisión posterior al incidente, incluido el origen del problema; y

• el acuerdo con que las acciones "Priority Action" (Acción prioritaria) vinculadas constituyen una manera aceptable de abordar el origen del problema.

Nuestros aprobadores a menudo solicitarán acciones adicionales o que se identifique una cadena determinada de causalidad que no hayan abordado las acciones propuestas. De este modo, vemos que las aprobaciones añaden mucho valor a nuestro proceso de análisis a toro pasado en Atlassian.

En equipos con menos incidentes o una infraestructura menos compleja, las aprobaciones de análisis a toro pasado pueden no ser necesarias.

Análisis retrospectivos sin acusaciones

Cuando algo va mal, la tendencia humana natural es buscar a alguien a quien culpar. Para Atlassian es beneficioso evitarlo; sin embargo, cuando estás ejecutando un análisis a toro pasado tienes que superarlo constantemente. Asumimos que nuestro personal tiene buenas intenciones y nunca culpamos de los fallos a las personas. El análisis a toro pasado debe examinar de manera objetiva y honesta las circunstancias que provocaron el fallo, para poder encontrar los orígenes reales del problema y mitigarlos. Culpar a los individuos pone esta labor en peligro por los siguientes motivos:

• El sentimiento de una persona al ver el riesgo de su prestigio en los ojos de sus compañeros o de su trayectoria profesional supera normalmente a los beneficios empresariales de su empleador en su jerarquía personal, por lo que probablemente oculte la verdad para proteger sus necesidades básicas.

• Aunque una persona realizara la acción que provocase directamente un incidente, lo que deberíamos preguntar no es "por qué el individuo X hizo esto", sino "por qué el sistema le ha permitido hacerlo o le ha hecho pensar que era lo más adecuado".

• Culpar a las personas es cruel y, si se repite lo suficiente, creará una cultura de miedo y desconfianza. 

En nuestros análisis a toro pasado, utilizamos las siguientes técnicas para crear seguridad personal para todos los participantes:

• Comienza la reunión del análisis retrospectivo haciendo saber que se trata de un análisis retrospectivo sin reproches y explica el motivo 

• Dirígete a los individuos según su función (p. ej., "el ingeniero de mecanismos incorporados de guardia") en lugar de por nombres (dejando los hechos claros y perfectamente definidos)

• Asegúrate de que el cronograma, la cadena de casualidad y las mitigaciones del análisis a toro pasado se enmarquen en el contexto de sistemas, procesos y funciones, no en individuos.

La inspiración de los análisis a toro pasado irreprochables y el práctico concepto de "segunda historia" viene del influyente artículo de John Allspaw.

Obtén el manual en versión impresa o PDF

Tenemos un suministro limitado de versiones impresas de nuestro Manual de gestión de incidentes, que enviamos de forma gratuita. También puedes descargar una versión en PDF.

Consigue el manual