AIOps
Detectar es fácil. Hallar la causa raíz exige contexto
En el artículo “Su operación monitorea todo. ¿Entonces por qué sigue recibiendo tantas alertas?”, compartí una reflexión sobre un problema que se volvió cada vez más común en las operaciones modernas de TI. A medida que ampliamos la cobertura del monitoreo, pasamos a ver muchas más señales sobre el comportamiento de los entornos, pero eso no significó, necesariamente, una comprensión más rápida de los incidentes.
Un único problema puede producir decenas o incluso cientos de alertas repartidas entre distintas herramientas. Cada plataforma registra correctamente lo que logra observar y cumple muy bien el papel para el cual fue diseñada. El desafío comienza cuando la operación necesita transformar ese conjunto de información en una explicación coherente sobre lo que realmente está ocurriendo.
Es justamente en ese momento cuando surge una pregunta importante.
Si hoy logramos detectar un incidente en pocos segundos, ¿por qué todavía tardamos tanto en descubrir dónde comenzó?
Esta cuestión merece atención porque, en muchos entornos, la etapa más demorada ya no es percibir que existe un problema. El verdadero desafío pasó a ser comprender su origen antes de que aumente el impacto para el negocio.
Detectar es solo el comienzo
Imagine una situación relativamente común en una gran empresa.
Son las dos de la madrugada y una aplicación crítica empieza a presentar lentitud. En pocos segundos, el monitoreo registra aumento en el uso de CPU en algunos servidores. La plataforma de observabilidad identifica un crecimiento en el tiempo de respuesta de las aplicaciones. La solución de experiencia digital detecta degradación en el recorrido de los usuarios. El sistema de ITSM empieza a recibir tickets y, poco después, otras aplicaciones pasan a presentar un comportamiento similar, aunque estén alojadas en entornos diferentes.
En menos de un minuto, la operación ya sabe que existe un incidente relevante.
Lo curioso es que, en ese momento, nadie sabe exactamente cuál es el problema.
El equipo responsable de la infraestructura verifica rápidamente el uso de los servidores y no encuentra ninguna anormalidad capaz de explicar el comportamiento observado. La base de datos sigue respondiendo dentro de los parámetros esperados. La red parece estable. Los servicios en la nube no registran indisponibilidades. Cada equipo pasa a analizar los componentes bajo su responsabilidad mientras siguen llegando nuevas informaciones.
La presión aumenta. Los gestores quieren una previsión de normalización. Las áreas de negocio preguntan qué servicios fueron afectados. Los usuarios siguen abriendo tickets. Mientras tanto, los equipos técnicos aún intentan responder una pregunta mucho más básica: ¿qué ocurrió de hecho?
Esta situación es mucho más común de lo que parece.
Durante muchos años, creímos que ampliar el monitoreo significaría reducir automáticamente el tiempo necesario para resolver incidentes. En cierta forma, eso realmente ocurrió. Hoy detectamos problemas con mucha más rapidez que en el pasado.
Pero los entornos también cambiaron.
Las aplicaciones dejaron de depender solo de servidores físicos y pasaron a operar sobre infraestructuras distribuidas, servicios en la nube, APIs, microservicios, bases de datos replicadas, plataformas de mensajería y diversos componentes compartidos. Al mismo tiempo, surgieron nuevas herramientas especializadas para monitorear cada una de esas capas.
Esta evolución trajo avances importantes en escalabilidad, visibilidad y confiabilidad. En contrapartida, aumentó significativamente la cantidad de información producida durante un incidente.
Si antes una operación analizaba pocas fuentes de eventos, hoy debe lidiar simultáneamente con plataformas de monitoreo de infraestructura, observabilidad, APM, logs centralizados, monitoreo de red, experiencia digital, nube, contenedores, Kubernetes, herramientas de seguridad, ITSM, CMDB y diversas soluciones específicas de fabricantes.
Cada una de ellas observa el entorno desde una perspectiva diferente.
Cada una produce eventos, métricas, logs, indicadores y alertas que tienen sentido dentro de su propio contexto.
Cada una describe correctamente lo que logra ver.
El problema es que ninguna de ellas fue concebida para explicar, por sí sola, un incidente que atraviesa todas esas capas.
Es exactamente ahí donde la complejidad de las operaciones modernas empieza a aparecer.
Antes de encontrar la causa, hay que construir contexto
Volvamos al incidente.
Después de casi cuarenta minutos de investigación, alguien percibe que todas las aplicaciones afectadas comparten el mismo servicio de autenticación. Pocos minutos antes del inicio de los problemas se había desplegado una nueva versión de ese componente.
A partir de ese momento, varios acontecimientos que parecían independientes empiezan a tener sentido.
Los errores de autenticación dejan de verse como un problema aislado. La lentitud observada en otras aplicaciones pasa a interpretarse como consecuencia del mismo fallo. Los tickets registrados por el Service Desk presentan exactamente la misma hora de inicio. La secuencia temporal de los eventos empieza a indicar una relación clara entre la actualización realizada y los síntomas percibidos por los usuarios.
Note lo que ocurrió.
La operación no encontró inmediatamente la causa raíz.
Antes de eso, logró reconstruir la historia del incidente.
Esa diferencia parece pequeña, pero ayuda a explicar por qué tantas investigaciones consumen tanto tiempo.
En la práctica, reconstruir esa historia significa mucho más que reunir alertas en una sola pantalla. Significa comprender cómo se relacionan entre sí las informaciones producidas por distintas plataformas y cómo cada una de ellas representa solo una parte de la realidad.
Un aumento en el uso de CPU puede ser solo consecuencia de un fallo anterior. Un error registrado en la aplicación puede tener origen en un servicio compartido utilizado por decenas de otros sistemas. Una degradación percibida por los usuarios puede haber comenzado varios minutos después del cambio que realmente inició el incidente. Un gran volumen de tickets puede ser solo el reflejo de un problema que ya venía propagándose silenciosamente por el entorno.
Ninguna de estas informaciones es suficiente, por sí sola, para explicar lo que ocurrió.
Es justamente cuando esas evidencias empiezan a correlacionarse que la operación pasa a construir el contexto del incidente.
Ese contexto no nace de una única herramienta ni de una única fuente de datos. Al contrario. Depende de la capacidad de integrar información proveniente de múltiples plataformas e interpretarla de forma conjunta.
Las alertas de monitoreo deben relacionarse con métricas de observabilidad. Los logs deben confrontarse con cambios recientes realizados en el entorno. La información del ITSM ayuda a identificar el impacto percibido por los usuarios. La topología revela dependencias entre aplicaciones. El historial de incidentes similares ofrece referencias importantes. La secuencia temporal muestra qué eventos ocurrieron primero y cuáles surgieron solo como consecuencia.
Por separado, esos elementos representan apenas fragmentos de la realidad.
Cuando se analizan en conjunto, pasan a construir una narrativa coherente sobre el comportamiento del entorno.
Eso es lo que llamamos contexto operacional.
Contexto no significa simplemente consolidar dashboards ni centralizar eventos de distintos fabricantes. Tampoco significa solo reducir el número de alertas mostradas a la operación.
Construir contexto significa correlacionar información heterogénea hasta que explique el comportamiento del entorno. Significa comprender qué alertas representan solo síntomas, cuáles pertenecen al mismo incidente, qué componentes comparten dependencias, qué cambios pueden haber iniciado el fallo y qué evidencias realmente ayudan a dirigir la investigación hacia su origen.
Este quizá sea uno de los cambios más importantes por los que están pasando las operaciones de TI.
Durante mucho tiempo, creímos que producir más datos sería suficiente para tomar mejores decisiones.
Hoy percibimos que el verdadero diferencial no está en la cantidad de información disponible, sino en la capacidad de transformarla rápidamente en comprensión.
El diferencial de las operaciones más maduras
Existe una idea bastante difundida de que las operaciones maduras son aquellas que monitorean más activos, tienen más dashboards o utilizan herramientas más sofisticadas.
Sin duda, todo eso es importante.
Pero, acompañando proyectos en distintas organizaciones a lo largo de los últimos años, pasé a percibir que el verdadero diferencial suele aparecer en otro momento.
Aparece en la velocidad con que la operación logra construir contexto.
Esta quizá sea una de las competencias menos discutidas y, al mismo tiempo, una de las más importantes de las operaciones modernas.
Cuanto más complejo se vuelve el entorno, mayor tiende a ser la cantidad de plataformas especializadas y, en consecuencia, mayor también es el número de fuentes que producen información sobre un mismo incidente. El problema es que cada una utiliza su propio lenguaje, sus propios modelos de datos y su propia forma de representar lo que está ocurriendo.
Mientras una herramienta registra eventos, otra trabaja con métricas. Una tercera produce logs. Otra presenta traces distribuidos. El ITSM registra tickets. La CMDB describe relaciones. Las plataformas de nube informan cambios en la infraestructura. Las soluciones de seguridad identifican comportamientos sospechosos.
Cada una de esas informaciones tiene valor.
Pero ninguna de ellas explica, por sí sola, un incidente que atraviesa todas esas capas.
En la práctica, el trabajo de la operación pasó a ser mucho menos encontrar datos y mucho más descubrir cómo se relacionan esos datos.
Es exactamente por eso que construir contexto se volvió una capacidad tan estratégica.
Cuando la operación logra correlacionar información proveniente de múltiples fuentes, deja de ver decenas de eventos independientes y pasa a comprender un único incidente.
Lo que antes parecía una sucesión de problemas desconectados empieza a revelar relaciones de causa y efecto. Las alertas dejan de competir entre sí. Los síntomas pasan a diferenciarse del origen del fallo. Las dependencias entre aplicaciones ayudan a eliminar hipótesis improbables. Los cambios recientes pasan a formar parte de la investigación desde los primeros minutos. El historial de incidentes similares ofrece referencias que difícilmente se percibirían analizando una sola herramienta.
Note que esta transformación no ocurre porque hayan surgido más datos.
Ocurre porque los datos pasaron a tener sentido en conjunto.
Quizá esa sea la mejor definición de contexto operacional.
El contexto es lo que transforma datos en comprensión.
Esta comprensión cambia por completo la forma en que trabajan los equipos.
En lugar de que cada especialista interprete solo la parcela del entorno que logra ver, la operación pasa a compartir una visión común del incidente. La conversación deja de girar en torno a decenas de alarmas y pasa a concentrarse en lo que realmente importa: cuál fue la primera desviación observada, cómo se propagó por el entorno, qué servicios fueron impactados y qué evidencias apuntan al origen del problema.
Esto no elimina la necesidad de profesionales experimentados.
Mucho menos significa que la causa raíz se identificará automáticamente.
Los entornos críticos seguirán exigiendo conocimiento técnico, capacidad de análisis y juicio humano.
Lo que cambia es el punto de partida.
En lugar de iniciar cada investigación intentando organizar manualmente cientos o miles de informaciones dispersas, los equipos pasan a trabajar sobre una comprensión mucho más clara del escenario que enfrentan.
Esta diferencia produce efectos que van mucho más allá de la identificación de la causa raíz.
Los equipos correctos se movilizan antes. Los síntomas dejan de tratarse como incidentes independientes. La comunicación entre las áreas se vuelve más objetiva porque todos pasan a trabajar sobre la misma interpretación de los hechos. El tiempo dedicado a discutir hipótesis improbables disminuye y la energía de la operación se dirige a lo que realmente necesita resolverse.
Quizá sea justamente esta la transformación más importante por la que estén pasando las operaciones de TI.
Durante muchos años, nuestro principal objetivo fue ampliar la capacidad de detectar fallos.
Hoy esa capacidad ya es prácticamente un requisito básico.
Lo que empieza a diferenciar a las operaciones verdaderamente maduras es la rapidez con que logran construir contexto, transformando miles de informaciones producidas por múltiples fuentes en una comprensión consistente de lo que realmente ocurrió.
En el próximo artículo de la serie, “La observabilidad no es una herramienta. Es una nueva forma de operar.”, profundizaremos esta discusión y analizaremos por qué la observabilidad va mucho más allá de la recolección de métricas, logs y traces. Su verdadero valor está en la capacidad de ampliar la comprensión de las relaciones entre aplicaciones, infraestructura y servicios, enriqueciendo el contexto operacional necesario para que las decisiones se tomen con mucha más rapidez y seguridad.
Para reflexionar
Cuando ocurre un incidente relevante en su operación, ¿cuánto tiempo se dedica a corregir el problema y cuánto se consume simplemente intentando entender dónde comenzó?
¿Los distintos equipos logran construir rápidamente una visión común del incidente o cada uno trabaja, inicialmente, con una interpretación diferente basada solo en la herramienta que utiliza?
¿La información producida por el monitoreo, la observabilidad, los logs, el ITSM, las plataformas de nube y las demás soluciones realmente se correlaciona o sigue analizándose de forma aislada?
¿Los cambios recientes, las dependencias entre aplicaciones, la topología de la infraestructura, el historial de ocurrencias similares y el impacto para el negocio forman parte de la investigación desde los primeros minutos o solo pasan a considerarse después de un largo análisis?
Responder a estas preguntas quizá revele que el mayor desafío de las operaciones modernas ya no está en detectar incidentes.
Está en construir, con rapidez, el contexto necesario para comprender lo que realmente ocurrió.
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.