De la disponibilidad a la experiencia: el cambio impulsado por IA en la observabilidad moderna

En 2001, IBM redactó un manifiesto de TI autónoma. La visión de la computación autonómica desglosó la autogestión en cuatro pilares: autooptimización, autorreparación, autoconfiguración y autoprotección. Yo estaba en Microsoft cuando IBM presentó esta visión de TI. Reaccionamos proponiendo ideas tecnológicas como el centro de datos autónomo, pero al final, era un sueño muy adelantado a su tiempo. No había una forma práctica de llevar esa visión a la realidad.

En mis días en Microsoft, formaba parte del equipo detrás de Clippy. Aunque el asistente de clip de papel animado era infamemente intrusivo, la idea subyacente era sólida: los ordenadores deberían ayudar activamente a los humanos a realizar su trabajo. Simplemente no teníamos la potencia de cálculo ni la IA para hacerlo posible. 25 años después, finalmente lo hacemos.

Del nivel de servicio al nivel de experiencia

El concepto de observabilidad no se originó en TI. En 1960, el ingeniero e historiador húngaro-estadounidense Rudolf E. Kálmán acuñó el término “observabilidad” para describir qué tan bien se puede medir un sistema a través de sus salidas. Luego, en 2013, Twitter adoptó el término en una serie de publicaciones de blog, diciendo efectivamente que la monitorización tradicional, a través de todas las herramientas comerciales disponibles, estaba diseñada para una era tecnológica diferente y no funcionaba en arquitecturas a escala de microservicios.

Piénselo como un médico que examina a un paciente. Puede comprobar su pulso, medir su presión arterial y observar otras características externas para evaluar indirectamente la salud interna del paciente. En TI, necesitamos hacer lo mismo. Cuando hay un temblor en el pulso del paciente, debemos saber si eso indica problemas en el riñón o en el hígado. A la escala y complejidad de las operaciones que Twitter manejaba hace incluso 20 años (la empresa solo atendía a 100 millones de usuarios con tweets y feeds en tiempo real), la observabilidad requería un enfoque de herramientas y monitorización diferente.

Los sistemas actuales se han vuelto aún más grandes y complejos, con dependencias de redes de distribución de contenido, caché y distribución de mapas de bits, fuentes, archivos JavaScript, y demás en todo el mundo. Comprender verdaderamente el rendimiento de aplicaciones del mundo real no es una tarea fácil.

Cuando TI recibe una alerta a las 4 de la mañana, alguien tiene que levantarse de la cama y averiguar si el problema se debe a un sector defectuoso en un disco duro o a un actor malintencionado que intenta penetrar y causar estragos en la infraestructura. En realidad, no importa cuál sea: al final del día, su trabajo es mantener todos los sistemas en funcionamiento. Afortunadamente, para evaluar la salud de las aplicaciones hoy, podemos recopilar toda la telemetría disponible: cada dispositivo de red, cada aplicación, miles de integraciones listas para usar, el flujo de tickets a través de JIRA o Atlassian, y muchos otros indicadores.

Aquí es donde entran los Objetivos de Nivel de Experiencia (XLOs). Probablemente haya escuchado hablar de los Acuerdos de Nivel de Servicio (SLAs) y los Objetivos de Nivel de Servicio (SLOs), pero los XLOs dan el siguiente paso al medir si sus clientes y empleados están obteniendo el nivel de experiencia que desean. Se trata de calidad, no solo de disponibilidad. Desde una perspectiva técnica, la única forma de lograr los XLOs es contar con visibilidad desde la NIC hasta el dispositivo del usuario final.

El pasado octubre, AWS US‑EAST‑1 se cayó. Catchpoint detectó el problema 16 minutos antes de que Amazon lo reconociera públicamente. Los clientes con esa visibilidad pudieron reaccionar antes de que sus usuarios sintieran las consecuencias de la interrupción.

La promesa de la observabilidad es como ser Smokey Bear: detectar dónde hay humo antes de que haya fuego. Si se hace correctamente, la observabilidad le permite apagar un incendio en la pradera antes de que se convierta en una conflagración que arrase los Palisades en California. Smokey es el sistema de alerta temprana que puede detectar esos pequeños rastros de humo sin importar de dónde provengan: un problema de AWS, un problema de Oracle, un problema de GCP, un problema de Microsoft Azure o algo fuera de lugar en su infraestructura.

La IA escala los sistemas de seguridad

Ningún operador humano puede vigilar los sistemas de infraestructura actuales. La única forma de monitorizar sistemas a gran escala, ingiriendo petabytes de datos de registro y billones de métricas al día, es usar IA.

Por ejemplo, suponga que desea rastrear el rendimiento de lectura/escritura en un disco o los desbordamientos de búfer de entrada/salida o paquetes dentro de su entorno de red. Puede usar un umbral dinámico para definir cómo se ve lo normal, o una forma determinista de observar series temporales de datos de la semana, mes, año o cualquier período que desee, y establecer umbrales de rendimiento normales. Una vez que tenga este análisis estadístico, puede fijar niveles a dos desviaciones estándar de la media, de modo que cuando algo ocurra fuera de ese rango, reciba una alerta de que el rendimiento podría ser anormal.

Sin embargo, los sistemas altamente complejos pueden recibir miles de alertas al día. Los paneles comienzan a parpadear y la gente empieza a ser pagada. Filtrar todas esas alertas no es un buen uso del tiempo humano. De hecho, Vectra estima que las organizaciones reciben un promedio de 2.992 alertas de seguridad al día, de las cuales el 63 % quedan sin atender.

Las herramientas de IA pueden reducir esos miles de alertas diarias a solo unas decenas. Recuerdo un caso en el que un solo problema en una única NIC de una única máquina generó 2,000 alertas posteriores. Gracias a la IA, el cliente pudo realizar la correlación de alertas y llegar a un análisis de causa raíz mucho más rápido, lo que a su vez concluyó que un solo problema en ese momento estaba provocando que todo el panel de la empresa se volviera rojo.

La IA está haciendo que TI sea emocionante de nuevo

Me tomé un tiempo libre después de que Cisco adquirió Splunk en 2023. Durante los dos años siguientes, vi cómo mis amigos y excolegas fundaron empresas para usar IA de maneras que no eran posibles ni siquiera hace cinco años. (Recuerda que si ChatGPT fuera un niño humano, tendría tres años).

Los equipos de TI necesitan ayuda para detectar humo antes de que suene la alarma, no más paneles frente a los cuales quedarse mirando. Ellos. De alguna manera, este es el mismo problema que IBM, Twitter e incluso Microsoft con Clippy han estado intentando resolver.

Esta es la razón por la que decidí volver a involucrarme. La tecnología finalmente ha alcanzado un punto en el que podemos cumplir la promesa original de observabilidad y TI autónoma.