AIOps
Observabilidad no es herramienta: es nueva forma de operar
En el artículo “Detectar un incidente es fácil. Lo difícil es construir el contexto para encontrar la causa raíz.”, exploré una cuestión que considero central para las operaciones modernas de TI. Hoy logramos identificar rápidamente que algo está mal. El problema comienza cuando necesitamos comprender qué ocurrió, dónde se originó realmente la falla y cómo se relacionan las distintas señales producidas por el entorno.
Esta discusión nos lleva naturalmente a la observabilidad.
En los últimos años, pocas palabras ganaron tanto espacio en el vocabulario de las operaciones de TI. Surgieron nuevas plataformas, arquitecturas, metodologías y funcionalidades asociadas al tema. Métricas, logs y trazas pasaron a ocupar un lugar cada vez más importante en las estrategias de monitoreo, especialmente en entornos distribuidos, aplicaciones modernas, microservicios, contenedores e infraestructuras en la nube.
Esa evolución fue necesaria. A medida que los sistemas se volvieron más dinámicos e interdependientes, simplemente acompañar si un servidor estaba disponible o si una determinada métrica había superado un umbral dejó de ser suficiente.
Pero existe un riesgo cuando una idea importante gana rápidamente espacio en el mercado.
Puede terminar reducida a la herramienta utilizada para implementarla.
He observado que esto ocurre con la observabilidad. En algunas conversaciones, la pregunta “¿su empresa tiene observabilidad?” termina respondiéndose simplemente con el nombre de una plataforma.
La respuesta puede tener sentido desde el punto de vista tecnológico, pero deja de lado una cuestión mucho más importante.
¿La organización logra utilizar la información disponible para comprender, con rapidez, cómo se comportan realmente sus servicios?
Esa diferencia es fundamental.
La observabilidad no debería tratarse solo como una nueva generación de herramientas. Representa un cambio en la manera en que vemos los entornos de tecnología. En lugar de preguntar solo si determinado componente está funcionando, empezamos a preguntar por qué el servicio se comporta de esa manera, qué relaciones pueden explicar ese comportamiento y qué significa eso para los usuarios y para el negocio.
Y cuanto más complejos se vuelven los entornos, más importante se vuelve este cambio de perspectiva.
Monitorear componentes es diferente de comprender servicios
Imagine una empresa que ofrece una aplicación crítica a miles de usuarios.
La arquitectura es moderna. La aplicación utiliza microservicios, APIs, contenedores y servicios en la nube. Parte de los datos permanece en infraestructura propia, mientras que otros componentes se ejecutan en proveedores externos. Existen mecanismos de autenticación compartidos, integraciones con terceros y distintas capas de red que conectan todo este ecosistema.
En determinado momento, los usuarios empiezan a notar lentitud. La operación detecta rápidamente el problema.
Los servidores están disponibles. Los contenedores siguen activos. La base de datos responde. La red no presenta una indisponibilidad generalizada. Aun así, la experiencia de los usuarios empeoró significativamente.
Un enfoque tradicional de monitoreo podría llevar al equipo a verificar componente por componente, buscando algún indicador claramente fuera de los límites esperados. En una arquitectura relativamente simple, ese proceso tal vez fuera suficiente.
En entornos modernos, sin embargo, el problema puede estar justamente en las relaciones entre esos componentes.
Una API pasó a responder algunos segundos más lento. Ese pequeño retraso aumentó el tiempo de ejecución de otro servicio, que comenzó a acumular solicitudes. Un microservicio pasó a consumir más recursos. El número de conexiones con la base de datos aumentó. Otros servicios dependientes comenzaron a presentar degradación y, algún tiempo después, los usuarios percibieron el impacto.
Ningún componente necesariamente dejó de funcionar. El servicio, sin embargo, dejó de funcionar adecuadamente.
Esta diferencia ayuda a comprender por qué la observabilidad ganó tanta importancia.
El monitoreo tradicional sigue siendo indispensable. Necesitamos saber si los equipos están disponibles, seguir la utilización de recursos, identificar desvíos y recibir alertas cuando determinados comportamientos superan los límites definidos.
Pero eso responde principalmente a preguntas que ya conocemos.
La observabilidad amplía esa capacidad al permitir investigar comportamientos que no siempre se previeron de antemano. Las métricas muestran cómo evolucionaron determinadas variables. Los logs registran acontecimientos relevantes dentro de los sistemas. Las trazas permiten seguir una transacción mientras recorre distintos componentes de una arquitectura distribuida.
Cuando esta información se analiza en conjunto, empezamos a pasar de una visión basada exclusivamente en componentes a una comprensión más cercana al comportamiento de los servicios.
Ese es un avance importante. Pero también crea una nueva cuestión.
Cuanto más profundamente logramos observar una parte del entorno, más evidente se vuelve que muchos incidentes relevantes no respetan los límites de una única plataforma, tecnología o equipo.
Volvamos al ejemplo.
Después de algún tiempo investigando la degradación de la aplicación, el equipo responsable de la observabilidad percibe que determinado servicio comenzó a presentar un aumento en el tiempo de respuesta aproximadamente a las 10:17. Las trazas muestran que varias transacciones pasaron a esperar más tiempo por una llamada externa.
Esa es una información extremadamente valiosa. Pero todavía no explica por qué empezó a ocurrir. La respuesta puede estar en otra fuente.
Quizás ocurrió un cambio de ruta pocos minutos antes en un componente de red. Quizás un servicio externo inició una degradación. Quizás se modificó una política de seguridad. Quizás se desplegó una nueva versión de algún componente. O quizás el origen esté en un elemento de la infraestructura que ni siquiera forma parte del universo observado por la misma plataforma.
La observabilidad ayudó a acercar al equipo al problema.
El contexto completo del incidente, sin embargo, puede seguir distribuido por el entorno. Esta distinción será cada vez más importante.
Profundidad de observación y amplitud de contexto no son lo mismo.
Una plataforma puede ofrecer una visión extraordinariamente profunda de aplicaciones, infraestructura o experiencia digital y, aun así, poseer solo una parte de las evidencias necesarias para explicar un incidente que atraviesa distintos dominios tecnológicos.
No hay contradicción en eso. Hay complementariedad.
Cuantas más herramientas ven el entorno, mayor el desafío de conectar las perspectivas
Esta tal vez sea una de las ironías de las operaciones modernas.
Invertimos durante años para ampliar nuestra capacidad de ver la infraestructura y los servicios. Creamos especialización, implantamos mejores herramientas y aumentamos significativamente la cantidad y la calidad de los datos disponibles.
Y tuvimos éxito.
Hoy una gran operación puede utilizar plataformas específicas para infraestructura, aplicaciones, redes, experiencia digital, logs, seguridad, nube, contenedores, ITSM y diversos otros dominios. Cada una de esas soluciones puede ser excelente en el problema que se propone resolver.
El resultado, sin embargo, es que un mismo incidente pasa a ser observado simultáneamente desde muchas perspectivas.
Considere nuevamente la degradación de la aplicación.
La plataforma de observabilidad identifica un aumento en el tiempo de respuesta de determinados servicios. El monitoreo de red registra un crecimiento de latencia en algunos enlaces. El entorno de nube informa un cambio en el comportamiento de determinadas instancias. El sistema de experiencia digital muestra un aumento en el tiempo necesario para completar un recorrido. El ITSM empieza a registrar tickets de los usuarios. Los logs presentan errores que antes no existían y una plataforma de automatización tiene el registro de un cambio realizado poco antes del inicio del incidente.
Por separado, cada una de esas informaciones cuenta una historia. Juntas, pueden contar otra.
Es exactamente en este punto donde el concepto de contexto operacional, discutido en el artículo anterior, vuelve a ganar importancia.
El desafío ya no está solo en obtener información detallada. Está en correlacionar información proveniente de múltiples fuentes para comprender cómo se relacionan.
En el ejemplo, saber que una aplicación se volvió lenta es importante. Saber que la latencia de red aumentó en el mismo período también lo es. Descubrir que hubo un cambio de configuración pocos minutos antes añade otra evidencia. Identificar que todas las aplicaciones afectadas dependen del mismo camino de comunicación comienza a reducir significativamente el universo de hipótesis.
Ninguna de estas informaciones, aisladamente, necesita revelar la causa. Es la relación entre ellas lo que comienza a explicar el incidente.
Esto cambia también la forma en que debemos pensar sobre el volumen de datos.
Durante algún tiempo, pareció razonable imaginar que cuantos más datos recolectara una operación, mayor sería su capacidad de comprender los problemas.
En la práctica, existe un límite para esa lógica.
Más métricas pueden significar más visibilidad, pero también más información para interpretar. Más logs aumentan la capacidad de investigación, pero pueden generar millones de registros durante pocos minutos de operación. Más herramientas especializadas amplían la profundidad del análisis, pero también crean nuevas fuentes que deben consultarse y relacionarse durante un incidente.
El desafío pasa gradualmente de la recolección a la interpretación. Es posible percibirlo claramente en las llamadas war rooms.
Cuando ocurre un incidente crítico, se reúnen distintos especialistas porque cada uno conoce profundamente una parte del entorno. El equipo de aplicaciones consulta su plataforma. Infraestructura verifica sus indicadores. Redes analiza sus eventos. El equipo de base de datos busca anormalidades. Seguridad verifica cambios. El Service Desk informa el comportamiento de los tickets.
Todos tienen datos.
La reunión existe justamente porque el contexto todavía necesita construirse.
Las personas empiezan a comparar horarios, buscar dependencias, descartar hipótesis y reconstruir la secuencia de los acontecimientos. Muchas veces, una información que parecía poco relevante en una herramienta pasa a ser decisiva al compararla con un evento observado en otra.
Este proceso puede funcionar muy bien, principalmente cuando hay profesionales experimentados involucrados. Pero también revela una limitación importante.
Cuanto mayor es el número de fuentes y mayor el volumen de información que producen, más difícil se vuelve construir ese contexto manualmente a la velocidad que exige el negocio.
Este no es un problema causado por las herramientas. Es una consecuencia natural de la complejidad.
Por eso creo que la evolución de la observabilidad necesita ir acompañada de una evolución igualmente importante en la manera en que integramos e interpretamos lo que observamos.
La observabilidad debe llevar a comprensión, no solo a más datos
Es en este punto donde, en mi percepción, la observabilidad deja de ser solo una discusión tecnológica y pasa a ser una discusión sobre la propia forma de operar.
Una organización puede adquirir una excelente plataforma de observabilidad y seguir trabajando de manera fragmentada.
Puede tener trazas extremadamente detalladas, pero analizarlas por separado de los eventos de infraestructura.
Puede recolectar millones de logs, pero no relacionarlos automáticamente con cambios recientes.
Puede conocer profundamente el comportamiento de una aplicación y, aun así, tardar mucho en descubrir que el origen de su degradación estaba en un componente externo.
La tecnología crea la posibilidad de comprender mejor. La operación necesita transformar esa posibilidad en capacidad real de decisión.
Esto exige un cambio de perspectiva.
En lugar de organizar la investigación solo en torno a las herramientas, necesitamos organizarla en torno al incidente. Parece una diferencia pequeña, pero no lo es.
Cuando la investigación comienza por la herramienta, cada equipo pregunta: “¿qué está mostrando mi plataforma?”.
Cuando comienza por el incidente, la pregunta pasa a ser: “¿qué información, independientemente de dónde esté, ayuda a explicar lo que está ocurriendo?”.
Esta segunda pregunta naturalmente atraviesa fronteras.
Puede exigir datos de observabilidad, monitoreo, red, nube, ITSM, experiencia digital, topología, cambios, automatización o cualquier otra fuente relevante para ese incidente.
En este modelo, ninguna plataforma pierde importancia. Al contrario.
Cuanto mejor sea la información producida por cada una, mejor será el contexto que la operación podrá construir.
Esta es una distinción importante porque existe una tendencia natural a imaginar la evolución tecnológica como una sucesión de sustituciones.
Una herramienta nueva sustituye a la anterior. Una nueva categoría vuelve obsoleta a la anterior. Una plataforma más abarcadora elimina la necesidad de las demás.
La realidad de las grandes operaciones suele ser diferente.
Los entornos complejos acumulan tecnologías porque distintos problemas exigen distintos niveles de especialización. Una herramienta de observabilidad puede convivir con monitoreo de infraestructura, ITSM, soluciones de red, experiencia digital y plataformas específicas de fabricantes porque cada una cumple una función importante.
La cuestión deja de ser cuál de ellas posee toda la verdad. Probablemente ninguna la posee.
La pregunta más relevante pasa a ser cómo transformar las distintas perspectivas producidas por ese ecosistema en una comprensión compartida del incidente.
Este cambio también ayuda a explicar por qué algunas organizaciones, aun utilizando plataformas semejantes, presentan niveles muy distintos de eficiencia operacional.
La diferencia puede no estar en la cantidad de datos recolectados ni en la sofisticación de las herramientas.
Puede estar en la velocidad con que logran conectar la información disponible y transformarla en contexto.
Volvamos una última vez al incidente de la aplicación.
Imagine dos empresas con arquitecturas semejantes y prácticamente las mismas herramientas.
En ambas, la observabilidad detecta rápidamente la degradación.
En la primera, cada equipo inicia su propia investigación. Aplicaciones analiza trazas. Redes verifica la latencia. Infraestructura sigue los recursos. El Service Desk consolida tickets. Se convoca una reunión y, durante los cuarenta minutos siguientes, los especialistas comparan información hasta percibir que un cambio realizado en la red poco antes del incidente alteró el comportamiento de un camino utilizado por varios servicios.
En la segunda empresa, esa misma información se relaciona desde los primeros minutos. El aumento del tiempo de respuesta se asocia temporalmente con el cambio. Los servicios afectados comparten la misma dependencia. Los eventos de red aparecen dentro de la misma ventana temporal y los tickets de los usuarios confirman el impacto.
Las dos empresas tenían prácticamente los mismos datos. Las dos detectaron el problema. Las dos tenían profesionales calificados.
Lo que cambió fue el tiempo necesario para transformar información dispersa en comprensión.
Esa diferencia puede representar decenas de minutos de indisponibilidad, cientos de usuarios afectados y, dependiendo del servicio, impactos financieros significativos.
Por eso creo que la discusión sobre observabilidad necesita avanzar.
El próximo salto no vendrá simplemente de la capacidad de recolectar aún más datos. Vendrá de la capacidad de utilizar mejor lo que ya logramos observar.
Esto significa combinar profundidad con amplitud. Necesitamos ver profundamente el comportamiento de los componentes, pero también comprender las relaciones que atraviesan distintas tecnologías, plataformas y dominios operacionales.
En otras palabras, la observabilidad genera aún más valor cuando deja de ser una isla de información y pasa a contribuir a la construcción de un contexto operacional más amplio.
Esta visión también cambia la pregunta que los gestores deberían hacerse al evaluar la madurez de sus operaciones.
Quizás no sea suficiente preguntar:
“¿Tenemos observabilidad?”
Una pregunta más interesante sería:
“Cuando ocurre un incidente crítico, ¿logramos conectar rápidamente lo que nos dicen nuestras distintas plataformas?”
La respuesta revela mucho más sobre la capacidad real de la operación.
En el próximo artículo de la serie, “El MTTR comienza antes de la resolución del incidente”, pretendo avanzar exactamente sobre esta cuestión. Analizaremos cuánto del tiempo total de un incidente se gasta realmente corrigiendo el problema y cuánto se consume intentando comprenderlo, localizar su origen, movilizar a los equipos correctos y decidir qué acción debe tomarse.
Porque reducir el MTTR quizás dependa menos de ejecutar la solución más rápido y mucho más de llegar antes a la decisión correcta.
Para reflexionar
Al observar su operación, vale la pena analizar si la observabilidad representa solo una nueva fuente de información o si realmente cambió la manera en que se comprenden los incidentes.
Cuando una aplicación presenta degradación, ¿los equipos logran relacionar rápidamente los datos de observabilidad con eventos de infraestructura, red, ITSM, experiencia digital, cambios y otras fuentes relevantes?
Durante un incidente crítico, ¿los profesionales trabajan sobre una visión compartida del problema o cada equipo sigue investigando principalmente lo que su propia plataforma logra ver?
Y, quizás la pregunta más importante: cuando todas estas herramientas producen información al mismo tiempo, ¿quién construye el contexto que permite comprender el incidente como un todo?
Las respuestas pueden revelar que el próximo paso de la observabilidad no está necesariamente en observar más.
Puede estar en conectar mejor lo que ya logramos ver.
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.