Análisis causa raíz y herramientas de monitorización: pareja perfecta
El análisis de causa raíz y las herramientas de monitorización han estado relacionadas durante mucho tiempo, pero, ¿sabes qué es realmente el Análisis de Causa Raíz (ACR) y cómo se aplica en el mundo de la monitorización de aplicaciones y redes?
El análisis de causa raíz es un método de resolución de problemas que intenta resolver problemas de la forma más efectiva, evitando que vuelvan a ocurrir. Para ello hay que determinar la causa de raíz y tomar medidas para eliminarlo.
ACR es esencialmente un método reactivo. Esto significa que, ante cualquier problema, los procedimientos de ACR comienzan a identificar las causas de raíz para evitar que se repita el mismo problema. Sin embargo, una vez se ha implementado y con una ejecución constante, ACR se transforma en un método predictivo de problemas.
Pero ACR también implica un procedimiento de consulta reiterativo. Es decir, con un problema bien identificado, haremos un primer análisis de las causas sabiendo dos cosas; en primer lugar, que este primer enfoque no identificará la causa raíz real, haciendo absolutamente necesario un proceso de consulta persistente. Una técnica iterativa interrogativa que encaja bastante bien con ACR y que puede mencionarse como un ejemplo para el punto anterior es la técnica de los 5 por qué, ampliamente utilizada por niños molestos.
Cuando nos encontramos con un problema, nos hacemos una primera pregunta: ¿Por qué ha sucedido? Inmediatamente tomaremos la respuesta; esto ha sucedido porque… “Causa 1” como base para la segunda pregunta: ¿por qué ocurrió la “causa 1”? Y así sucesivamente, hasta completar cinco porqués. En teoría, la “causa 5” es la causa raíz. Más allá de esta técnica, la idea es que, para ser eficaz, la ACR se debe realizar sistemáticamente, profundizando en el problema hasta que se alcance la causa raíz. Para seguir mencionando las bases para la implementación de ACR, debemos tener en cuenta estos tres puntos destacados:
- Definir y describir adecuadamente el problema. Es importante definir el problema o describir el evento con hechos, incluyendo la magnitud, la ubicación y el tiempo. La conclusión es simple: lo primero es entender el problema.
- Establecer una línea de tiempo desde la situación normal hasta el fallo. La idea es ver cada comportamiento, condición y acción relacionados con el problema, en una secuencia de línea de tiempo.
- Distinguir entre factor causal y causas de raíz. Mirando la línea de tiempo, tenemos que clasificar las causas en dos categorías: factores causales que se relacionan y contribuyen con el problema y las causas que realmente interrumpen la secuencia cuando se eliminan.
Podemos encontrar en la literatura especializada muchos ejemplos exitosos de implementaciones de ACR en diferentes áreas, desde el mundo de la seguridad con análisis de accidentes hasta el mundo médico con análisis de negligencia médica. Ahora, ¿qué puede hacer un método de resolución de problemas como ACR para aquellos que están interesados en el mundo del análisis y en la monitorización de redes y aplicaciones?
Cada lista de objetivos para una plataforma de análisis y monitorización incluye la detección y prevención de fallas que pueden afectar el rendimiento o la caída de los servicios.
Es aquí, en la búsqueda del objetivo, donde una buena relación entre el análisis de causa raíz y las herramientas de monitorización podrían ser útiles.
Imagina que tienes una plataforma bien monitorizada y una aplicación web que se ejecuta en varios servidores. Para uno de esos servidores, la capacidad del disco está alcanzando un nivel peligroso, por encima de nuestro umbral. Nuestra plataforma de monitorización produce una alarma. Así es posible recibir la alarma y tomar las medidas correctas para evitar un problema de rendimiento o una caída del servicio web.
En este caso, la monitorización basada en recursos para verificar el comportamiento de cada elemento de la red y los servidores funcionan perfectamente y es una plataforma simple; aquí la implementación de ACR no es realmente necesaria.
Sin embargo, la historia no es tan simple cuando hablamos de plataformas complejas con múltiples aplicaciones que se ejecutan en servidores propios, en la nube, en servidores virtualizados, en esquemas de comunicación Wan con diferentes tecnologías y proveedores, etc.
Pensemos en este escenario: una compañía tiene una plataforma compleja pero bien monitorizada. Algún día, el departamento de marketing lanza una campaña promocional. Decidieron utilizar el espacio publicitario de un programa de televisión, orientado a su mercado objetivo. El programa de televisión se transmite de 9:00 a 10:00 de la noche. El lanzamiento es un éxito, por lo que la aplicación web registra un aumento del 100% en las solicitudes de acceso.
Desde las 9.30 p. M. recibimos varias alarmas de un grupo de servidores, conmutadores de red, enrutadores y aplicaciones. Decidimos probar nuestra aplicación web y verificar el tiempo de respuesta, y sí, es demasiado alto. Sabemos que nuestros clientes están frustrados y la compañía está perdiendo dinero.
La primera respuesta a este problema de rendimiento podría ser: “nuestra plataforma no pudo soportar este aumento en la demanda web”. Obviamente, esta respuesta no es suficiente, así que en este punto podemos usar ACR para luchar con diferentes factores causales.
La clave a la pregunta está aquí: ¿Cuánto tiempo es necesario para hacer un análisis de raíz y cuánto soporte ofrece nuestra plataforma de monitorización? En serio, a más apoyo de nuestra plataforma de monitorización menos tiempo para identificar la causa raíz.
Entonces, ¿sobre qué base pueden funcionar las herramientas de monitorización y análisis causa raíz?
Vista por servicios
Para poder realizar un análisis causa raíz de manera eficiente debemos verificar todo el grupo de elementos relacionados con el servicio problemático. Si nuestra plataforma de monitorización puede ofrecernos en una vista integrada el estado de todos esos elementos, podría ser grandioso reducir el tiempo de análisis que podría tomar.
Considere las dependencias entre elementos
Tomemos un ejemplo clásico para ilustrar este punto: tenemos un conmutador de red y cinco servidores conectados a él. En un punto, nuestro interruptor falla; realmente no necesitamos las cinco alarmas de cada servidor diciendo que no son alcanzables, solo necesitamos ver una sola alarma, la alarma del interruptor.
La solución podría comenzar con un mapa de dependencias entre los elementos, pero sería aún mucho mejor si además de la solución tuviéramos información sobre el tipo de tráfico compartido entre elementos o midiendo la respuesta temporal en cada paso.
Información histórica
Como mencionamos al principio, ACR es esencialmente un método reactivo; por lo tanto, mantener los datos históricos es imprescindible. El esfuerzo y los costes relacionados con el mantenimiento de este tipo de datos podrían justificarse para otras actividades, como la planificación de capacidad, entre otras. Podría ser muy interesante si pudiéramos mantener una base de datos de conocimiento con la relación entre el problema y sus causas principales.
Como se mencionó, la relación entre el análisis de causa raíz y las herramientas de monitorización ya existe; tal vez podamos verificar más de cerca esas implementaciones en otra publicación. Sin embargo, podemos ver este área como una de las próximas fronteras que posiblemente se conquistarán en el mercado de la monitorización.
