Proceso de análisis retrospectivo de incidentes: seguimiento, documentación y mejora

PRINCIPALES CONCLUSIONES

• Los análisis retrospectivos de incidentes ayudan a los equipos a entender qué ha ocurrido, por qué y qué necesita cambiar para evitar que las incidencias se repitan.

• Al combinar Jira Service Management, Confluence y Jira, se crea un flujo de trabajo interconectado de respuesta, documentación y seguimiento.

• Una plantilla de análisis retrospectivo bien elaborada contribuye a que las revisiones de incidentes sean más fáciles de documentar y comparar, y permite aprender de ellas a lo largo del tiempo.

• Convertir las acciones correctivas en actividades de Jira con personas propietarias y fechas límite ayuda a los equipos a transformar las lecciones aprendidas en mejoras reales. 

Cuando algo sale mal en la fase de producción, la solución es solo el comienzo, ya que es igual de importante entender por qué ha ocurrido y asegurarse de que no vuelva a repetirse. 

Un análisis retrospectivo de un incidente constituye una revisión estructurada de un incidente de principio a fin, que abarca qué ha fallado, cómo ha respondido el equipo y qué se debe cambiar en el futuro.

Si tu equipo se guía por una plantilla de plan de respuesta ante incidentes, podrá documentar cada incidente de manera uniforme para que no se pase por alto nada importante y que cada revisión conduzca a mejoras reales.

Funcionamiento: ejecutar incidentes y elaborar análisis retrospectivos

Una buena gestión de incidentes no consiste solo en apagar incendios, sino en crear un sistema donde cada incidente contribuya a mejorar los procesos, las herramientas y la preparación para la próxima vez. La combinación de Jira Service Management, Confluence y Jira brinda a tu equipo un flujo de trabajo interconectado que abarca todo el ciclo de vida de respuesta ante incidentes, desde el momento en que se activa una alerta hasta el análisis retrospectivo y la actividad de seguimiento. 

Este enfoque permite documentar todos los incidentes de manera uniforme y establece una cadena de responsabilidad clara. En lugar de tener los detalles del incidente desperdigados por mensajes de Slack, correos electrónicos y la memoria de la gente, todo se encuentra en un ecosistema único y conectado donde se puede revisar, consultar y abordar. Esa uniformidad también significa que tu plantilla de plan de respuesta ante incidentes constituye un elemento fundamental del proceso en lugar de ser algo que el equipo completa cuando tiene tiempo para hacerlo. 

Este es el desglose del proceso en cada etapa:

Ejecutar el incidente en Jira Service Management

Jira Service Management es el lugar donde comienza la respuesta ante incidentes. En cuanto llegue una incidencia, regístrala en JSM, establece el nivel de gravedad y asigna a las personas encargadas de responder adecuadas. 

Durante el incidente, los equipos pueden usar JSM para lo siguiente:

• Hacer un seguimiento de las acciones, decisiones y derivaciones en tiempo real

• Llevar un registro claro de quién ha participado y qué ha cambiado

• Recopilar la información que más adelante servirá para elaborar el análisis retrospectivo

• Mantener informadas a las personas responsables sin interrumpir a aquellas encargadas de responder

Dado que JSM se integra con Confluence y Jira, los datos recopilados durante el incidente pueden fluir directamente hacia la documentación del análisis retrospectivo y la actividad de seguimiento. En el caso de los equipos que usan JSM como parte de una configuración más amplia de software de ITSM, los datos del incidente también se integran en el panorama más amplio de la gestión de servicios.

JSM también admite una sólida comunicación de incidentes durante todo el proceso de respuesta, ya que ayuda a los equipos a lo siguiente:

• Mantener al día a los clientes, los equipos de soporte y las partes interesadas

• Reducir la confusión durante incidentes activos

• Proporcionar visibilidad del estado y el impacto

• Comunicarse con mayor claridad durante eventos muy graves o situaciones de gestión de crisis

Para cuando el incidente esté resuelto, el equipo ya dispondrá de un registro detallado de cómo se ha desarrollado, lo que hace que el análisis retrospectivo sea más fácil de documentar y más útil de cara a las futuras mejoras.

Elaborar el análisis retrospectivo en Confluence

Una vez que se resuelva el incidente, documéntalo mientras los detalles aún estén frescos, a ser posible en un plazo de 24 a 48 horas. Cuanto más esperes, más información se te irá olvidando y más utilidad restarás al análisis retrospectivo. 

Crea una página de Confluence especializada mediante una plantilla de análisis retrospectivo de incidentes y trabaja en cada sección: cronograma, análisis de causas, evaluación del impacto y lecciones aprendidas. La plantilla de respuesta ante incidentes incluida en esta página proporciona un marco completo que tu equipo puede copiar y rellenar para cada nuevo incidente para que no tengas que averiguar qué documentar desde cero en cada ocasión.

Mantener los análisis retrospectivos en Confluence ofrece una serie de ventajas prácticas:

• Visibilidad para todo el equipo: cualquier persona, desde el equipo de ingeniería hasta el directivo, puede revisar lo que ha ocurrido sin tener que perseguir a la persona de guardia encargada de responder para que le resuma el incidente.

• Identificación de patrones: cuando todos los incidentes se documentan en el mismo formato, es mucho más fácil detectar errores recurrentes y deficiencias sistémicas de un trimestre a otro.

• Documentación imparcial: una plantilla estructurada de respuesta ante incidentes mantiene la conversación centrada en los sistemas y procesos en lugar de señalar culpables, lo que da lugar a informes más veraces y útiles.

• Incorporación más rápida para nuevas contrataciones: los nuevos miembros del equipo pueden leer los análisis retrospectivos anteriores para entender cómo se comportan tus sistemas bajo presión y ver qué ha aprendido ya el equipo de incidentes previos.

Para obtener directrices más exhaustivas sobre cómo realizar análisis retrospectivos productivos, lee nuestro manual de análisis retrospectivo de incidentes.

Supervisar las tareas de seguimiento como actividades de Jira

Un análisis retrospectivo solo es útil en la medida en que dé lugar a acciones. Cada acción correctiva e incidencia recurrente identificada durante la revisión debe convertirse en una actividad de Jira con una persona propietaria clara y una fecha límite. 

Este es el paso que separa a los equipos que realmente mejoran de aquellos que siguen enfrentándose a los mismos problemas. Cuando las acciones correctivas constituyen actividades de las que se puede hacer un seguimiento en Jira, las personas responsables pueden supervisar el progreso y los equipos pueden responsabilizarse mutuamente de completar las mejoras que acordaron. Esto también ayuda con la priorización. Cuando las tareas motivadas por incidentes se incluyen con el resto del backlog, resulta más sencillo sopesarlas frente a otras prioridades en lugar de dejar que queden relegadas al final de la lista.

Las herramientas de gestión de incidentes adecuadas conectan todo este flujo de trabajo de principio a fin. Cuando tus sistemas de respuesta, documentación y seguimiento están integrados, la distancia entre detectar un problema y evitar que se repita se reduce considerablemente.

Plantilla de respuesta ante incidentes

A continuación se muestra una plantilla de plan de respuesta ante incidentes que tu equipo puede copiar y adaptar a cada nuevo incidente. En ella se abordan todas las fases de un análisis retrospectivo, desde el resumen inicial y el cronograma hasta el análisis de causas, las lecciones aprendidas y las acciones correctivas. Usar una estructura uniforme para cada incidente garantiza que no se pase nada por alto y que los análisis retrospectivos sean fáciles de comparar a lo largo del tiempo.

Los ejemplos de la plantilla constituyen un punto de partida, no un guion fijo. Ajusta el idioma y el nivel de detalle al modo de trabajo de tu organización. El objetivo es documentar suficiente contexto para que cualquier persona que lea el análisis retrospectivo meses después pueda entender exactamente qué pasó y qué hizo el equipo al respecto.

"Incident summary" (Resumen del incidente)

Redacta un breve resumen del incidente. Incluye una relación de los hechos, el motivo, la gravedad del incidente y la duración de las consecuencias.

Ejemplo:

Entre las {time range of incident, e.g. 15:45 and 16:35} del {DATE}, {NUMBER} usuarios se encontraron con {EVENT SYMPTOMS}. 

El evento fue provocado por un {CHANGE} a las {TIME OF CHANGE THAT CAUSED THE EVENT}. 

El {CHANGE} contenía {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Un error en este código provocó {DESCRIPTION OF THE PROBLEM}. 

El evento se detectó a través de {MONITORING SYSTEM}. El equipo empezó a trabajar en el evento aplicando {RESOLUTION ACTIONS TAKEN}.

Este incidente de gravedad {SEVERITY LEVEL} afectó a un {X%} de los usuarios.

Hubo más consecuencias, como se observó por el hecho de que se generaran {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} en relación con este incidente. 

"Leadup" (Suceso previo)

Explica la secuencia de acontecimientos que provocaron este incidente, por ejemplo, cambios anteriores que hayan introducido errores que todavía no se hubieran detectado.

Ejemplo:

A las {16:00} del {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), se introdujo un cambio en {PRODUCT OR SERVICE} para {THE CHANGES THAT LED TO THE INCIDENT}. 

Este cambio resultó en {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

"Fault" (Fallo)

Explica por qué el cambio implementado no funcionó conforme a lo previsto. Si dispones de pantallazos de visualizaciones de datos pertinentes que ilustren el error, adjúntalos.

Ejemplo:

Se enviaron {NUMBER} respuestas por error a un {XX%} de las solicitudes. Esto se produjo durante {TIME PERIOD}.

Consecuencias

Explica cómo afectó el incidente a los usuarios internos y externos durante el incidente. Incluye la cantidad de casos de soporte generados.

Ejemplo:

Durante {XXhrs XX minutes} entre las {XX:XX UTC and XX:XX UTC} del {MM/DD/YY}, {SUMMARY OF INCIDENT} nuestros usuarios experimentaron este incidente.

Este incidente afectó a {XX} clientes (un X % de los usuarios de {SYSTEM OR SERVICE}), que experimentaron {DESCRIPTION OF SYMPTOMS}.

Se enviaron {XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}.

Detección

¿Cuándo detectó el equipo el incidente? ¿Cómo supieron que se estaba produciendo? ¿Cómo podríamos mejorar el tiempo de detección? Plantéate lo siguiente: ¿cómo podríamos haber reducido ese tiempo a la mitad?

Ejemplo:

Este incidente se detectó cuando se desencadenó la alerta {ALERT TYPE} y se avisó a {TEAM/PERSON}. 

Después, se avisó a {SECONDARY PERSON}, porque {FIRST PERSON} no tenía la titularidad del servicio que estaba escribiendo en el disco, lo que retrasó la respuesta {XX MINUTES/HOURS}.

{TEAM OWNER OF THE IMPROVEMENT} implementará {DESCRIBE THE IMPROVEMENT} para que {EXPECTED IMPROVEMENT}.

Respuesta

¿Quién respondió al incidente? ¿Cuándo respondió y qué hizo? Deja constancia de todos los retrasos u obstáculos para responder.

Ejemplo:

Después de recibir un aviso a las {XX:XX UTC}, {ON-CALL ENGINEER} entró online a las {XX:XX UTC} en {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Este ingeniero no tenía experiencia con {AFFECTED SYSTEM}, por lo que se envió una segunda alerta a las {XX:XX UTC} a {ESCALATIONS ON-CALL ENGINEER}, quien entró en la sala a las {XX:XX UTC}.

Recuperación

Explica cómo se restableció el servicio y se consideró que el incidente había terminado. Detalla cómo se restableció correctamente el servicio y cómo averiguaste cuáles eran los pasos necesarios para la recuperación. 

Dependiendo de la situación, plantéate estas preguntas: ¿cómo podrías mejorar el tiempo de mitigación y cómo podrías haber reducido ese tiempo a la mitad?

Ejemplo:

Adoptamos un enfoque triple para la recuperación del sistema: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Ejemplo: Al ampliar el tamaño de BuildEng EC3 ASG con el fin de aumentar el número de nodos disponibles para asistir en la carga de trabajo y reducir la probabilidad de programar sobre nodos con suscripción excesiva.

• Deshabilitar el autoescalador Escalator para evitar que los clúster se reduzcan de manera agresiva

• Deshacer el programador de Build Engineering a la versión anterior.

Cronograma

Detalla el cronograma del incidente. Recomendamos usar UTC para estandarizar los husos horarios.

Incluye cualquier evento de origen digno de mención, los inicios de actividad, la primera consecuencia conocida y las escalaciones. Toma nota de todos los cambios o decisiones efectuados, así como la fecha de finalización del incidente, junto con cualquier evento significativo posterior al efecto causado. 

Ejemplo:

Todas las horas están en formato UTC.

11:48 - Actualización a K8S 1.9 del plano de control completada. 

12:46 - Actualización a V1.9 completada, incluidos el autoescalador de clúster y la instancia del programador de BuildEng. 

14:20 - Build Engineering informa de un problema a KITT Disturbed.

14:27 - KITT Disturbed empieza a investigar los errores de una instancia específica de EC2 (ip-203-153-8-204). 

14:42 - KITT Disturbed acordona el nodo. 

14:49 - BuildEng informa de que el problema afecta a más de un nodo. 86 instancias del problema demuestran que los errores son más sistémicos. 

15:00 - KITT Disturbed sugiere cambiar al programador estándar. 

15:34 - BuildEng notifica un fallo en 200 pods. 

16:00 - BuildEng cierra todas las compilaciones fallidas con informes de CPU agotada (OutOfCpu). 

16:13 - BuildEng informa de que los fallos se repiten constantemente con las nuevas compilaciones y no eran temporales. 

16:30 - KITT reconoce los fallos como incidente y los ejecuta como tal. 

16:36 - KITT deshabilita el autoescalador Escalator con el fin de evitar que este elimine el proceso para disminuir el problema.

16:40 - KITT confirma que ASG es estable, la carga de clúster es normal y el impacto de cliente se ha resuelto.

PLANTILLA:

XX:XX UTC - ACTIVIDAD DEL INCIDENTE; MEDIDA TOMADA

XX:XX UTC - ACTIVIDAD DEL INCIDENTE; MEDIDA TOMADA

XX:XX UTC - ACTIVIDAD DEL INCIDENTE; MEDIDA TOMADA

Identificación del origen del problema: los cinco porqués

Los cinco porqués son una técnica de identificación del origen del problema. A continuación, te explicamos cómo los puedes usar:

• Empieza con una descripción de la consecuencia y pregunta por qué ocurrió. 

• Anota la repercusión que tuvo.  

• Pregunta por qué ocurrió y por qué tuvo la repercusión consiguiente. 

• Después, sigue preguntando "por qué" hasta que llegues a la causa raíz.

Haz una lista de los "porqués" en la documentación de tu análisis retrospectivo.

Ejemplo:

1. La aplicación se interrumpió porque la base de datos estaba bloqueada.

2. La base de datos se interrumpió porque se produjeron muchas escrituras en ella.

3. Porque insertamos un cambio en el servicio y no esperábamos la gran cantidad de escrituras.

4. Porque no tenemos un proceso de desarrollo establecido para la prueba de carga de los cambios.

5. Porque nunca pensamos que la prueba de carga era necesaria hasta que llegamos a este nivel de escalado.

"Root cause" (Origen del problema)

Toma nota del origen definitivo del incidente: lo que has identificado que hay que cambiar para que este tipo de incidentes no vuelvan a producirse más.

Ejemplo:

Un error en

"Backlog check" (Comprobación de backlog)

Revisa el backlog de ingeniería para averiguar si hubo algún trabajo imprevisto que pudiera haber evitado este incidente o, al menos, haber reducido su repercusión. 

Una evaluación con criterio del backlog puede arrojar luz sobre las decisiones pasadas relativas a la prioridad y al riesgo.

Ejemplo:

No hay ningún elemento en particular en el backlog que pudiera haber mejorado este servicio, pero sí una nota sobre las mejoras en la tipificación de los flujos, que eran tareas en curso con los flujos de trabajo establecidos.  

Se han enviado tickets para mejorar las pruebas de integración, pero hasta ahora no han tenido éxito.

"Recurrence" (Recurrencia)

Ahora que conoces el origen del problema, ¿puedes mirar atrás y detectar otros incidentes que pudieran tener el mismo origen? En caso afirmativo, toma nota de lo que se intentó hacer para mitigar dichos incidentes y pregúntate por qué este sí se volvió a producir.

Ejemplo:

Este mismo origen del problema tuvo como resultado los incidentes HOT-13432, HOT-14932 y HOT-19452.

Lecciones aprendidas

Analiza qué fue lo que salió bien en la respuesta ante incidentes, qué podría haberse mejorado y dónde hay oportunidades de mejora.

Ejemplo:

• Es necesario realizar una prueba de unidad para verificar que el limitador de velocidad del trabajo cuenta con un mantenimiento adecuado

• Se deben revisar las cargas de trabajo de operaciones en masa que no son comunes en el funcionamiento habitual

• Las operaciones en masa deben iniciarse poco a poco, supervisarse y aumentar cuando las métricas de servicio sean nominales

"Corrective actions" (Acciones correctivas)

Explica la medida correctiva ordenada para evitar que este tipo de incidentes se produzcan en el futuro. Deja constancia de quién tiene que hacerse cargo de esa tarea y de cuándo tiene que hacerla, así como de dónde se va a supervisar.

Ejemplo:

1. Establecimiento de un límite de velocidad de autoescalación temporal para limitar los fallos

2. Limitación de velocidad de reintroducción de trabajo y prueba de unidad

3. Introducción de un mecanismo secundario para recopilar la información sobre la velocidad distribuida en el clúster con el fin de guiar los efectos de ampliación