Lo hemos visto una y otra vez, un ticket llega a la mesa de ayuda, un cliente se queja de una aplicación lenta o de una mala calidad de voz durante una llamada. Empezamos a investigar el problema, tal vez sacamos algunos registros, tomamos algunos datos de rendimiento del NMS. Todo lo que encontramos no es concluyente, y cuando volvemos a consultar al cliente los síntomas han pasado. El problema ha desaparecido y hay otro ticket en la cola, así que seguimos adelante, sin saber qué causó el problema, sabiendo que volverá a aparecer.
El proceso de llegar al núcleo o raíz de un fallo o problema se denomina Análisis de Causa Raíz (ACR). El Análisis de la Causa Raíz no es un proceso único y estricto, sino un conjunto de pasos, a menudo organizados específicamente por tipo de problema o industria, que pueden personalizarse para un problema concreto. Cuando se trata de identificar la causa raíz de un suceso relacionado con las TI, puede emplearse una combinación de análisis basado en procesos y en fallos. Aplicando un proceso de ACR y corrigiendo los problemas para evitar que se produzcan en el futuro, los equipos de ingeniería reactivos pueden transformarse en proactivos, que resuelven los problemas antes de que se produzcan o se agraven.
En este artículo intentaré esbozar un proceso general para la resolución de problemas relacionados con la red, es decir, aquellos problemas que afectan directamente al rendimiento de una red informática o de una aplicación y que tienen un impacto negativo en la experiencia del usuario. Aunque utilizaré las soluciones de Opmantek en los ejemplos, estos pasos pueden aplicarse a cualquier colección de herramientas NMS.
Introducción al análisis de la causa raíz
Describir el proceso del ACR es como pelar una cebolla. Cada paso del proceso se compone a su vez de varios pasos. A continuación se incluyen los tres pasos principales del proceso de ACR. Los dos primeros pasos suelen completarse en tándem, ya sea por un individuo o por un equipo en una reunión de revisión de incidentes post-mortem.
- Identificar correcta y completamente el evento o problema,
- Establezca un calendario desde el funcionamiento normal hasta el evento,
- Separar las causas fundamentales de los factores causales
Identificar el evento o el problema
La identificación completa y precisa del problema o evento es quizás la parte más fácil del ACR cuando se trata de problemas de red.
Así es, he dicho más fácil.
Es fácil porque todo lo que tienes que hacer es preguntarte ¿Por qué? Cuando tengas una respuesta a la pregunta Por qué, pregúntate por qué ha ocurrido esa cosa. Sigue preguntándotepor qué hasta que ya no puedas hacerlo más, lo que suele ocurrir entre 4 y 5 veces. Este proceso se conoce a menudo como los 5 porqués.
Muchos ingenieros recomiendan utilizar un diagrama de Ishikawa o de espina de pescado para ayudar a organizar las respuestas a los 5 porqués. A mí me gusta esto, y a menudo utilizo una pizarra y notas adhesivas mientras trabajo en el problema. Si prefieres utilizar una herramienta de diagramación de software, está bien, pero utiliza lo que te resulte más cómodo.
Ejemplo - El poder del porqué
Este es un ejemplo del mundo real que el equipo de Servicios Profesionales de Opmantek encontró mientras realizaba una formación in situ sobre el funcionamiento del sistema. Un usuario interno llamó a la mesa de ayuda del cliente e informó de una mala calidad de audio durante una GoToMeeting con un cliente potencial.
- ¿Por qué? - Un usuario informó de la mala calidad de la voz durante una GoToMeeting (primer motivo)
- ¿Por qué? - La interfaz del router que da servicio al escritorio del usuario experimenta un alto ifOutUtil (segundo motivo)
- ¿Por qué? - Las copias de seguridad del servidor se realizan durante el horario laboral (tercera razón)
- ¿Por qué? - El trabajo cron que ejecuta los scripts de copia de seguridad está configurado para que se ejecute a las 21:00 horas de la zona horaria local (cuarta razón)
- ¿Por qué? - El servidor que ejecuta el trabajo cron está configurado en UTC (quinta razón)
El equipo comenzó con el problema inicial, tal y como se informó, y se preguntó por qué estaba ocurriendo esto. A partir de ahí, rápidamente se plantearon varias comprobaciones puntuales y sacaron datos de rendimiento del conmutador al que estaba conectado el escritorio del usuario y del router de subida de ese conmutador; esto identificó un cuello de botella de ancho de banda en el router y nos dio nuestra segunda razón.
Una vez identificado el cuello de botella del ancho de banda, los ingenieros utilizaron nuestras soluciones para identificar de dónde procedía el tráfico a través de la interfaz del router. Esto les dio el servidor de copia de seguridad, y una rápida comprobación de las tareas en ejecución identificó el trabajo de copia de seguridad - y allí se identificó el tercer Porqué.
Las copias de seguridad del sistema eran gestionadas por una tarea cron, que estaba programada para las 9 de la noche. Un comentario en la tarea cron sugería que se trataba de las 21:00 horas de la zona horaria local (EST) de la ubicación física del servidor. Esto le dio al equipo la cuarta razón.
Una comprobación de la fecha y la hora del servidor indicaba que el servidor estaba configurado para UTC, lo que nos daba el quinto Porqué.
No todos los análisis de problemas serán tan sencillos o directos. Al organizar sus preguntas sobre el porqué y sus respuestas en un diagrama de espina de pescado, identificará las causas (y los factores causales) que conducen a la definición del problema y a la causa raíz. En resumen, siga preguntando por qué hasta que no pueda seguir preguntando: ahí es donde suele empezar el problema.
Establecer un calendario
Al establecer una línea de tiempo es importante investigar tanto lo micro (la ocurrencia de este evento) como lo macro (si este evento ocurrió en el pasado). Pensando en las matemáticas de la escuela primaria, dibujo una línea de tiempo, una línea horizontal, a través de mi pizarra. En el centro coloco un punto: es T0 (tiempo cero), cuando ocurrió el acontecimiento.
A la derecha de T0añado marcas para cuando se descubrieron detalles adicionales, cuando el usuario informó del problema y cuando recogimos información de rendimiento o NetFlow. También añado marcas para cuando se produjeron o se informaron otros síntomas, y para cualquier evento adicional del NMS.
A la izquierda del T0, coloco todo lo que hemos aprendido al preguntarnos el Por qué: ¿cuándo empezaron las copias de seguridad, cuándo deberían haber empezado? También reviso mi NMS en busca de eventos que conduzcan al problema de rendimiento; ¿la utilización de la interfaz fue aumentando lentamente o se disparó de forma espectacular?
Una vez que he trazado la micro-línea de tiempo para esta ocurrencia, empiezo a mirar hacia atrás a través de mis datos. Aquí es donde resulta útil disponer de una buena cantidad de información de rendimiento relacionada con el tiempo. El sistema de información de gestión de redes (NMIS) de Opmantek puede almacenar datos de sondeo detallados de forma indefinida, lo que permite un rápido análisis visual de los eventos recurrentes basados en el tiempo.
Ejemplo - El poder del tiempo
A medida que los ingenieros trabajaban en sus preguntas del porqué y construían un diagrama de espina de pescado, también creaban una línea de tiempo del evento.
Empezaron definiendo T0 como el momento en que se notificó el suceso, pero a medida que fueron recopilando datos lo ajustaron al momento en que empezó realmente el impacto en la red.
A la derecha de T0, añadieron cuándo el usuario informó del problema, cuándo iniciaron el análisis de eventos, cuándo se recopilaron los datos de rendimiento del conmutador y el enrutador, y la información de NetFlow del recopilador de NetFlow. También añadieron en las marcas cuando otros usuarios informaron de impactos en el rendimiento, y cuando NMIS levantó eventos para el aumento de ifOutUtil en las interfaces del router y del servidor de respaldo.
A la izquierda de T0, añadieron cuándo se iniciaron las copias de seguridad, así como cuándo deberían haberse iniciado. Revisaron NMIS y encontraron los eventos iniciales menores, mayores y de advertencia para el aumento de ifIOutUtil en la interfaz del router.
Una vez que se completó la línea de tiempo, el equipo de ingenieros pasó a buscar sucesos anteriores de este evento. Ampliando la escala de los gráficos de la interfaz del router, los ingenieros pudieron ver al instante que esta interfaz había estado informando de un elevado ifOutUtil a la misma hora todos los días de la semana durante varias semanas. Este comportamiento cíclico sugería que se trataba de un proceso cronometrado y no de un evento único relacionado con el usuario.
Causas fundamentales frente a factores causales
A medida que vaya construyendo y respondiendo a sus preguntas de por qué, inevitablemente descubrirá varios puntos finales posibles, cada uno de ellos una causa raíz potencial. Sin embargo, algunos de estos puntos serán simplemente un problema causado por la causa raíz -un factor causal- y no la causa raíz en sí.
Para mejorar el rendimiento de la red a largo plazo, es fundamental que estos factores causales se identifiquen como lo que son, y no se presenten erróneamente como la causa principal.
Ejemplo - Distraído por un factor causal
El equipo de ingenieros se dio cuenta rápidamente de que todos los servidores habían sido configurados, en algún momento del pasado, para las zonas horarias locales y sólo recientemente se habían estandarizado a UTC. Aunque se había establecido un proceso para identificar los horarios, como este trabajo cron, y actualizarlos para el cambio a UTC, este se había pasado por alto.
Algunos miembros del equipo querían detenerse aquí y arreglar la programación del cron. Sin embargo, el grupo más amplio preguntó: ¿Por qué un trabajo cron para un proceso crítico, en un servidor crítico, se perdió en el proceso de actualización?
Al extraer la lista de procesos y expedientes de los registros del equipo de actualización, se comprobó que este expediente HABÍA sido identificado y actualizado, y que las pruebas se habían completado y verificado. Esto trajo la siguiente pregunta: ¿Por qué se cambió el trabajo cron actualizado, por quién/qué proceso?
Aunque se pueden abordar los factores causales, a menudo son sólo una solución temporal para el problema mayor. A veces esto es todo lo que se puede hacer en ese momento, pero si no se identifica y se aborda completamente la causa raíz, cualquier solución temporal que se aplique a los factores causales se romperá con el tiempo.
Ejemplo - Encontrar la causa raíz
Al investigar más a fondo, los ingenieros descubrieron que la tarea cron se había actualizado correctamente, pero una versión archivada más antigua de la tarea cron se había copiado en el servidor a través de un proceso de DevOps. Se reunió un Equipo Tigre para investigar el archivo DevOps y determinar el alcance del problema. El equipo Tiger informó al grupo de ingeniería al día siguiente; se encontraron otros archivos de programación obsoletos y también se corrigieron. El equipo de ingeniería trabajó con los ingenieros de DevOps para poner en marcha un proceso que mantuviera actualizado el archivo de archivos de DevOps.
Clausura del evento
En este punto, ha completado el Análisis de Causa Raíz y ha identificado el problema principal que causa la degradación del rendimiento reportada. Dado que ha abordado la causa raíz, este problema no debería volver a producirse. Sin embargo, no puede detenerse aquí: hay dos pasos de seguimiento que son críticos para su futuro éxito como organización de ingeniería
- Documentar el problema
Me gusta utilizar un wiki centralizado, como Confluence de Atlassian, para capturar el conocimiento de mi organización en un repositorio central disponible para todo el equipo de ingeniería. Aquí documentaré todo el evento, lo que fue reportado por el usuario, la información de rendimiento que capturamos, el proceso de RCA y el resultado final - cómo y qué hicimos para evitar que esto suceda de nuevo. Utilizando herramientas como Opmantek's opEvents, puedo relacionar esta entrada del wiki con el servidor, el router, las interfaces y el evento ifOutUtil, de modo que si se repite, los futuros ingenieros tendrán esta referencia disponible.
- Seguimiento
Se ha identificado la causa raíz, se ha puesto un remedio y se ha desarrollado un proceso para evitar que vuelva a ocurrir. Sin embargo, esto no significa que hayamos terminado con la resolución de problemas. Hay veces en las que lo que suponemos que es la causa raíz es, de hecho, sólo un factor causal. Si ese es el caso, este problema se reafirmará de nuevo, ya que la solución sólo sería una solución para el verdadero problema. La solución es poner en marcha un proceso, normalmente a través de un grupo de trabajo o una reunión del equipo de ingeniería, para discutir los eventos que impactan al usuario y determinar si se relacionan con los procesos RCA abiertos o remediados.
Lo que he presentado aquí es un proceso simplificado de análisis de la causa raíz. Hay otros pasos que pueden darse en función del tipo de equipo o proceso de que se trate, pero si se empieza por aquí siempre se puede hacer crecer el proceso a medida que el equipo vaya asimilando el proceso y la metodología.
Lo mejor,
