Plantillas para análisis post mortem de incidentes y
RCA para equipos de TI

Así es como Zylker llevó a cabo el análisis posterior al incidente. El equipo de TI de Zylker comenzó designando a John Clarke como responsable del análisis posterior al incidente. John formaba parte del equipo de respuesta a incidentes y tenía conocimiento de primera mano sobre la interrupción del servicio. Prepara el siguiente informe post mortem para Zylker.

Uno de los pasos más importantes en el análisis posterior al incidente es el análisis de causas raíz (RCA).

Un RCA es un método sistemático para encontrar las razones subyacentes de un incidente. El equipo recopila y analiza toda la información disponible, como logs de eventos, configuraciones del servidor, etc., y determina la causa raíz. Esto ayuda a la organización a aprender del incidente y garantizar que no se produzcan incidentes similares en el futuro.

Estos son algunos de los métodos que Zylker utilizó en su RCA:

Método de las cinco preguntas

El método de las cinco preguntas es una técnica para analizar un incidente repitiendo la pregunta "¿por qué?" hasta identificar la causa raíz, normalmente en unos cinco porqués.

En el caso de Zylker, veamos cómo su equipo de TI identificó la causa raíz:

• ¿Por qué no pudieron realizar pedidos los clientes? Porque el sistema de gestión de pedidos no estaba disponible.
• ¿Por qué no estaba disponible el sistema de gestión de pedidos? Porque el servidor de la base de datos se desconectó de los servidores de aplicaciones.
• ¿Por qué se produjo la desconexión? Porque la versión actualizada de Microsoft SQL Server era incompatible con el código base de la aplicación.
• ¿Por qué se actualizó la base de datos sin un análisis adecuado? Porque la CMDB no se actualizó para reflejar las últimas relaciones de dependencia, por lo que el análisis realizado no reflejaba el entorno en tiempo real.
• ¿Por qué no se actualizó la CMDB con las últimas relaciones de dependencia? Debido a que las fallas en la comunicación dentro del equipo hacen que ya no se siga el procedimiento operativo estándar para la asignación de dependencias.

Diagrama de espinas de pescado

A veces conocido como diagrama de Ishikawa o diagrama de causa y efecto, esta herramienta visual identifica los posibles factores contribuyentes clasificados por causas raíz, como personas, procesos, tecnología y entorno.

El equipo de respuesta a incidentes crearía un diagrama de espinas de pescado con el problema central como "Interrupción del sistema de gestión de pedidos". Cada una de las ramas representarían una categoría de causa raíz potencial:

Método Kepner-Tregoe (KT)

Este enfoque estructurado para la resolución de problemas utiliza una serie de preguntas para definir el problema, analizar las posibles causas y desarrollar medidas correctivas.

A continuación, se explica cómo se aplicó el modelo KT para encontrar la causa raíz:

• Definir el problema: El sistema de gestión de pedidos sufrió una interrupción, lo que provocó una pérdida significativa de ingresos.
• Analizar las causas potenciales: basándose en la información recopilada en el análisis posterior y en la lluvia de ideas del diagrama de espinas de pescado, el equipo identifica las causas potenciales, como fallos de comunicación y análisis de configuración incompleto.
• Desarrollar y probar soluciones: A continuación, el equipo evalúa y prioriza las soluciones para cada causa potencial. Esto podría suponer la implementación de una CMDB en tiempo real con asignación detallada de dependencias, políticas de CAB actualizadas, flujos de trabajo de gestión de cambios revisados y la instauración de períodos de congelación de cambios.

Mediante el empleo de estos tres métodos de RCA, Zylker identificó la causa raíz de la interrupción del servicio. Recuerde que un RCA es un paso crucial en el análisis postmortem al incidente y orienta los esfuerzos de gestión de problemas que se llevarán a cabo en caso de incidentes repetidos o interrupciones mayores.

En las organizaciones que no participan activamente en el ejercicio de postmortem exhaustivo de incidentes, sus equipos de TI pierden la valiosa oportunidad de volver sobre sus pasos durante la respuesta a incidentes e identificar información que podría hacer o deshacer su estrategia de gestión de incidentes y problemas. Sin embargo, entre los equipos que realizan evaluaciones postmortem a los incidentes, el ejercicio puede convertirse rápidamente en un juego de acusaciones. Para que la evaluación postmortem de un incidente y la RCA sean realmente valiosas, los equipos de TI deben realizar ambos ejercicios de forma objetiva, sin dirigir la culpa hacia nadie, y aprovechar la experiencia del incidente como un conocimiento que puede ayudar a infundir resiliencia a sus servicios de TI.