Plantilla de análisis retrospectivo de incidentes

La claridad de la documentación es clave para la eficacia del proceso de análisis retrospectivo de los incidentes. Muchos equipos utilizan una plantilla exhaustiva para recopilar de forma homogénea los pormenores de cada revisión de análisis retrospectivo. 

A continuación, te mostramos un ejemplo de una plantilla de análisis retrospectivo de incidentes, basada en el análisis retrospectivo explicado en nuestro Manual de gestión de incidentes. Puedes cortar y pegar lo que estimes oportuno para documentar tus propios análisis retrospectivos.

"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