Plantilla de análisis retrospectivo de incidentes

"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 {intervalo temporal del incidente; p. ej., 15:45 y las 16:35} del {FECHA}, {NÚMERO} usuarios experimentaron {SÍNTOMAS DEL EVENTO}.

El evento se desencadenó por un {CAMBIO} a las {HORA DEL CAMBIO CAUSANTE DEL EVENTO}.

El {CAMBIO} contenía {DESCRIPCIÓN O MOTIVO DEL CAMBIO, como un cambio en el código para actualizar un sistema}.

Un error en este código provocó {DESCRIPCIÓN DEL PROBLEMA}.

{SISTEMA DE SUPERVISIÓN} detectó el evento. El equipo empezó a trabajar en el evento aplicando {MEDIDAS DE RESOLUCIÓN ADOPTADAS}.

Este incidente de gravedad {NIVEL DE GRAVEDAD} afectó a un {X %} de los usuarios.

Hubo más consecuencias, como se observó por el hecho de que se generaran {p. ej., el NÚMERO DE TICKETS DE SOPORTE ENVIADOS, DE MENCIONES EN REDES SOCIALES O DE LLAMADAS A LOS GESTORES DE CUENTAS} 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 {DD/MM/AAAA} ({INTERVALO DE TIEMPO ANTES DE QUE AFECTARA AL CLIENTE; p. ej., 10 días antes del incidente en cuestión}), se introdujo un cambio en {PRODUCTO O SERVICIO} para {LOS CAMBIOS QUE PROVOCARON EL INCIDENTE}.

Este cambio provocó {DESCRIPCIÓN DE LAS CONSECUENCIAS DEL CAMBIO}.

"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 {NÚMERO} respuestas por error a un {XX %} de las solicitudes durante {PERIODO}.

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:

Nuestros usuarios sufrieron este incidente durante {XX horas y XX minutos}, entre las {XX:XX UTC y las XX:XX UTC} del {DD/MM/AAAA}: {RESUMEN DEL INCIDENTE}.

Este incidente afectó a {XX} clientes (UN X % DE LOS USUARIOS DE {SISTEMA O SERVICIO}), que sufrieron {DESCRIPCIÓN DE LOS SÍNTOMAS}.

Se enviaron {XX TICKETS DE SOPORTE Y XX PUBLICACIONES EN REDES SOCIALES}.

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 {TIPO DE ALERTA} y se avisó a {EQUIPO/PERSONA}.

Después, se avisó a {PERSONA SECUNDARIA}, porque {PRIMERA PERSONA} no tenía la titularidad del servicio que estaba escribiendo en el disco, lo que retrasó la respuesta {XX MINUTOS/HORAS}.

{PROPIETARIO DEL EQUIPO DE LA MEJORA} se encargará de {EXPLICA LA MEJORA} para que {MEJORA PREVISTA}.

Respuesta

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

Ejemplo:

Tras recibir un aviso a las {XX:XX UTC}, {INGENIERO/A DE GUARDIA} se conectó a las {XX:XX UTC} a {SISTEMA EN EL QUE SE REGISTRÓ LA INFORMACIÓN SOBRE EL INCIDENTE}.

Este ingeniero no dominaba {SISTEMA AFECTADO}, por lo que se envió una segunda alerta a las {XX:XX UTC} a {INGENIERO/A DE GUARDIA PARA ESCALACIONES}, 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 LA MEDIDA QUE MITIGÓ LA INCIDENCIA, POR QUÉ SE TOMÓ Y CUÁL FUE EL RESULTADO}

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 la gestión del grupo de conexión de provocó la filtración de conexiones en condiciones de error, combinada con una falta visibilidad del estado de la conexión.

"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.

"Lessons learned" (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