AIOps
Su operación monitorea todo. ¿Por qué tantas alertas?
En el artículo ¿Por qué tantas operaciones de TI siguen apagando incendios?, compartí una reflexión sobre un problema recurrente en las operaciones de TI. A lo largo de los años, ampliamos significativamente nuestra capacidad de monitorear entornos, recolectar datos y seguir el comportamiento de infraestructuras, aplicaciones y servicios. Aun así, muchos equipos siguen enfrentando dificultades para transformar toda esa información en decisiones rápidas y seguras.
Este problema se vuelve aún más evidente cuando ocurre un incidente relevante.
En pocos minutos, distintas herramientas empiezan a registrar señales de lo que está ocurriendo. La infraestructura presenta degradación. Una aplicación responde más lentamente. La base de datos aumenta el tiempo de procesamiento. Un componente de red pierde rendimiento. Los usuarios empiezan a reportar inestabilidad. Se abren nuevos tickets y, casi al mismo tiempo, surgen alertas en distintas plataformas.
Cada una de estas informaciones puede ser correcta.
El problema es que llegan de forma aislada.
Las herramientas de monitoreo fueron desarrolladas para observar partes específicas del entorno. Algunas siguen servidores y equipos de red. Otras analizan aplicaciones, bases de datos, servicios en la nube, logs o experiencia digital. Cada plataforma ofrece una visión valiosa, pero limitada al universo que logra ver.
Cuando una falla atraviesa varias capas de la operación, esas visiones fragmentadas pasan a generar una gran cantidad de eventos relacionados con el mismo problema.
Así se forma una tormenta de alertas.
Cómo se forma una tormenta de alertas
Un solo incidente puede producir decenas o incluso cientos de notificaciones. El servidor informa utilización elevada de recursos. La aplicación registra aumento en el tiempo de respuesta. La base de datos señala conexiones lentas. La herramienta de experiencia digital identifica degradación en el recorrido del usuario. El sistema de gestión de servicios recibe tickets de áreas diferentes.
Ninguna de estas señales es necesariamente falsa. La mayoría de las veces, todas describen efectos reales del mismo incidente.
La dificultad está en comprender rápidamente cómo se relacionan.
Durante muchos años, el principal desafío de las operaciones fue ampliar la cobertura del monitoreo. Había componentes importantes sin seguimiento adecuado, aplicaciones críticas con poca visibilidad y fallas que solo se percibían después de que los usuarios empezaban a quejarse.
Ese escenario llevó a las organizaciones a invertir en nuevas herramientas, ampliar la recolección de métricas y crear alertas para prácticamente todos los elementos relevantes del entorno.
Fue una evolución necesaria.
Hoy, sin embargo, en muchas operaciones, el problema ya no es la ausencia de información. Es el exceso.
Cuanto mayor es la cobertura del monitoreo, mayor tiende a ser el volumen de eventos generados durante una falla. Entornos más distribuidos, con aplicaciones que dependen de varios servicios, infraestructuras híbridas e integraciones con terceros, amplían aún más ese efecto.
La operación pasa a ver más, pero no siempre logra comprender mejor.
Esa diferencia es importante.
Monitorear no es lo mismo que comprender el incidente
Monitorear significa observar comportamientos, identificar desvíos y registrar eventos. Comprender un incidente exige relacionar esa información, reconstruir la secuencia de los acontecimientos y distinguir el origen del problema de sus consecuencias.
En la práctica, buena parte del esfuerzo de los equipos aún se concentra en esa etapa.
Cuando varias alertas surgen al mismo tiempo, profesionales de distintas áreas inician sus propios análisis. El equipo de infraestructura verifica servidores. El equipo de aplicaciones consulta logs. El equipo de base de datos evalúa consultas y conexiones. Se analiza la red. Soporte organiza los tickets recibidos.
Cada grupo intenta confirmar si el problema está bajo su responsabilidad.
Este trabajo es necesario, pero con frecuencia ocurre de forma paralela y poco coordinada. Como cada equipo observa solo una parte del entorno, el incidente puede parecer diferente según el punto de vista de quien lo analiza.
Mientras tanto, el tiempo de indisponibilidad sigue aumentando.
En algunos casos, el equipo logra restaurar el servicio rápidamente porque alguien reconoce un patrón ya conocido. En otros, la investigación depende de la experiencia de profesionales específicos que conocen profundamente el entorno y logran conectar información dispersa.
Ese conocimiento es valioso, pero no debería ser el único mecanismo capaz de dar sentido a las alertas.
Cuando la interpretación depende exclusivamente de la memoria y de la experiencia individual, la operación se vuelve vulnerable. Cambios en el equipo, crecimiento del entorno o aumento de la complejidad pueden reducir rápidamente la capacidad de respuesta.
Fatiga de alertas y pérdida de confianza
El exceso de alertas también produce otro efecto conocido por los equipos operacionales: la pérdida gradual de confianza en las notificaciones.
Cuando una alerta se dispara con mucha frecuencia y rara vez exige una acción concreta, empieza a tratarse como ruido. Se ajustan umbrales para reducir ocurrencias. Se silencian notificaciones. Algunos eventos dejan de recibir la misma atención.
Este comportamiento es comprensible. Ningún equipo logra mantener el mismo nivel de concentración ante cientos de mensajes sin prioridad clara.
El riesgo surge cuando, en medio de alertas repetitivas, aparece justamente la señal que debería haberse percibido antes.
La fatiga de alertas no ocurre porque los profesionales hayan dejado de preocuparse por la operación. Surge cuando el sistema exige atención constante sin ofrecer contexto suficiente para orientar esa atención.
Este es un punto que merece cuidado.
Muchas organizaciones buscan resolver el problema ajustando umbrales, desactivando notificaciones o reduciendo el número de reglas. Estas medidas pueden ser necesarias, principalmente cuando hay configuraciones inadecuadas o alertas sin utilidad operacional.
Pero reducir el volumen de notificaciones no resuelve, por sí solo, la dificultad de comprender los incidentes.
Una operación puede recibir menos alertas y seguir sin saber cómo se relacionan.
Correlacionar alertas para ver un incidente
El avance más importante ocurre cuando la organización deja de analizar eventos solo de forma individual y pasa a tratarlos como partes de una misma ocurrencia.
Esto exige una visión que atraviese las herramientas.
Imagine, por ejemplo, que una falla en un servicio de autenticación afecte a varias aplicaciones. Cada aplicación puede generar alertas propias. Los usuarios pueden abrir tickets distintos. Componentes de infraestructura pueden presentar cambios de comportamiento. El equipo puede, inicialmente, interpretar todas estas señales como problemas independientes.
Cuando los eventos se analizan en conjunto, el escenario cambia.
La proximidad de horario, la dependencia común entre las aplicaciones y la secuencia de los síntomas ayudan a revelar que existe un único origen para diversas ocurrencias.
El volumen de información sigue siendo el mismo. Lo que cambia es la forma en que se organiza.
En lugar de decenas de alertas disputando la atención del equipo, la operación pasa a ver un incidente principal, sus impactos y los componentes relacionados.
Este tipo de correlación representa un cambio relevante en la madurez operacional.
La pregunta deja de ser solo “¿qué alerta se generó?” y pasa a ser “¿qué está mostrando este conjunto de alertas?”.
Parece una diferencia pequeña, pero altera por completo el proceso de respuesta.
Cuando el equipo recibe contexto, logra priorizar mejor, involucrar a las áreas correctas y evitar investigaciones innecesarias. Los tickets relacionados pueden agruparse. Los síntomas dejan de tratarse como causas independientes. La comunicación entre los equipos se vuelve más objetiva.
La operación pasa a gastar menos tiempo organizando información y más tiempo actuando sobre el problema real.
Esta evolución no significa sustituir las herramientas de monitoreo existentes.
Al contrario.
Las plataformas especializadas siguen siendo esenciales porque producen las señales que permiten comprender el entorno. Métricas, logs, eventos, tickets y datos de experiencia son partes importantes del análisis.
Lo que falta, en muchos casos, es una capa capaz de conectar esa información.
Esa capa no necesita eliminar la lógica ya construida a lo largo de los años. Debe aprovechar las inversiones existentes y dar más sentido a lo que las herramientas ya producen.
AIOps, correlación y contexto operacional
Es en este punto donde los enfoques de AIOps comienzan a ganar relevancia.
El valor no está simplemente en aplicar inteligencia artificial sobre un gran volumen de datos. Está en combinar reglas, historial, topología, relaciones y patrones de comportamiento para reducir la fragmentación de la operación.
En algunos escenarios, la correlación puede basarse en relaciones conocidas y criterios objetivos. En otros, los modelos de inteligencia artificial ayudan a identificar semejanzas, recurrencias y patrones difíciles de percibir manualmente.
El mejor resultado suele surgir de la combinación de estos enfoques.
Las reglas determinísticas siguen siendo importantes cuando la relación entre los eventos es conocida. La inteligencia artificial añade capacidad de análisis en situaciones en las que el entorno es más dinámico o los patrones no son tan evidentes.
El objetivo no es sustituir el juicio de los equipos.
Es permitir que ese juicio ocurra con mejor información.
Este cuidado es importante porque el debate sobre inteligencia artificial, muchas veces, crea expectativas irreales. Ninguna tecnología elimina completamente la necesidad de conocimiento operacional. Los entornos críticos siguen exigiendo profesionales capaces de evaluar riesgos, validar hipótesis y decidir la mejor forma de actuar.
La diferencia es que esos profesionales no deberían necesitar comenzar cada incidente organizando manualmente cientos de alertas.
Cuando la tecnología logra reducir el ruido y presentar los eventos dentro de un contexto común, el equipo pasa a actuar en un nivel más estratégico.
En lugar de buscar el problema en medio de una gran cantidad de notificaciones, puede concentrar su experiencia en la evaluación de las causas más probables, de los impactos y de las acciones necesarias para restaurar el servicio.
Esta transformación también cambia la forma en que debe medirse la eficiencia de la operación.
Durante mucho tiempo, ampliar el número de ítems monitoreados se consideró un indicador de evolución. En parte, lo sigue siendo. Una operación sin cobertura adecuada permanece expuesta a fallas que pueden pasar inadvertidas.
Pero la cantidad de componentes monitoreados no revela, por sí sola, la capacidad de respuesta.
Es posible monitorear miles de elementos y aun así depender de largas reuniones para entender un incidente.
Es posible mantener dashboards detallados y seguir investigando síntomas de forma aislada.
Es posible recibir alertas en tiempo real y aun así descubrir demasiado tarde cuál de ellas realmente importaba.
Por eso, las operaciones más maduras empiezan a observar otras señales.
Evalúan cuánto tiempo tarda el equipo en comprender el impacto de un evento. Verifican cuántas notificaciones están asociadas al mismo incidente. Identifican cuántos tickets se abrieron por síntomas de una única falla. Analizan cuánto esfuerzo se gastó antes de localizar la causa probable.
Estas medidas ayudan a mostrar si el monitoreo está, de hecho, apoyando la toma de decisiones o solo ampliando el volumen de información disponible.
Monitorear mejor, no solo monitorear más
Al final, la cuestión no está en elegir entre monitorear más o monitorear menos.
Está en monitorear mejor.
Esto significa garantizar cobertura adecuada, mejorar la calidad de las alertas y, principalmente, crear mecanismos para relacionar las distintas señales producidas por el entorno.
Una operación eficiente no es aquella que deja de recibir alertas.
Es aquella que logra comprender, con rapidez, qué alertas pertenecen al mismo problema, cuáles representan solo consecuencias y cuáles realmente exigen una decisión.
La tormenta de alertas no es solo un problema de volumen.
Es un problema de contexto.
Y, a medida que los entornos se vuelven más distribuidos e interdependientes, la capacidad de construir ese contexto deja de ser una mejora deseable y pasa a ser una competencia esencial para cualquier operación que pretenda responder con velocidad y seguridad.
El próximo texto de la serie, “Detectar un incidente es fácil. Lo difícil es construir el contexto para encontrar la causa raíz.”, profundizará esta discusión. La propuesta será analizar por qué los síntomas suelen aparecer en lugares distintos del origen de la falla y cómo eso influye en el tiempo de diagnóstico y recuperación de los servicios.
Para reflexionar
Al observar su operación, vale la pena analizar si las alertas ayudan a organizar la respuesta a los incidentes o solo amplían la cantidad de información que debe interpretarse.
¿Cuántas notificaciones suele generar un solo problema?
¿Los equipos logran percibir rápidamente que distintos eventos están relacionados?
¿Las alertas indican prioridad e impacto o solo registran que algo salió del comportamiento esperado?
¿El tiempo del equipo se utiliza para resolver el incidente o para descubrir qué señales realmente merecen atención?
Las respuestas ayudan a identificar si el desafío actual está en la cobertura del monitoreo o en la capacidad de transformar eventos dispersos en una visión clara de lo que está ocurriendo.
Sobre el autor
Paulo Florêncio de Menezes es emprendedor, socio y cofundador de empresas como Target Solutions, BiPTT y ARGUS.
Es graduado en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene MBA en Gestión Empresarial por la Fundación Dom Cabral (FDC) y Máster Profesional en Economía por la Fundación Getulio Vargas (FGV).
En su investigación de máster desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.