AIOps sin humo: qué datos necesita y qué esperar el primer año

AIOps llegó a las conversaciones de operaciones con una promesa amplia: plataformas que aprenden solas, detectan problemas antes de que ocurran y reducen los incidentes a una fracción. La realidad es más modesta y, bien planteada, más útil. Lo que estas herramientas hacen hoy con fiabilidad es aplicar análisis estadístico y aprendizaje automático sobre los datos operativos para correlacionar eventos, reducir el ruido de alertas, detectar comportamientos anómalos en métricas y ayudar a acotar la causa probable de un incidente.

Ninguna de esas capacidades funciona sin datos de calidad, y casi ninguna da resultados visibles en las primeras semanas. Este artículo propone qué preparar antes de comprar o activar una plataforma, qué esperar trimestre a trimestre durante el primer año y qué conviene no prometer.

Qué hace AIOps y qué no hace

Conviene separar cuatro capacidades, porque maduran a ritmos distintos y dependen de datos distintos:

• Reducción de ruido. Deduplicar alertas repetidas, suprimir las que derivan de un mismo síntoma y agrupar por servicio. Es la capacidad más madura y la que antes muestra resultados.
• Correlación de eventos. Agrupar alertas de distintas herramientas que pertenecen al mismo incidente, usando tiempo, topología y atributos comunes. Depende directamente de que la topología sea confiable.
• Detección de anomalías. Aprender el comportamiento normal de una métrica, incluidos sus ciclos diarios y semanales, y señalar desvíos. Es útil en métricas con patrones estables y ruidosa en métricas erráticas o con poco historial.
• Apoyo al análisis de causa raíz. Proponer el componente o el cambio más probable detrás de un grupo de alertas. Es una sugerencia para el equipo resolutor, no un diagnóstico.

Lo que AIOps no hace es reemplazar el criterio del equipo de operaciones, corregir una arquitectura mal instrumentada ni compensar procesos de incidentes que no existen. Si cada equipo abre tickets a su manera y nadie registra la causa al cerrar, la plataforma no tiene de qué aprender.

El capítulo "Monitoring Distributed Systems" del libro de SRE de Google insiste en algo que aquí aplica igual: alertar sobre síntomas que afectan a los usuarios y mantener las reglas simples y comprensibles. Una capa de AIOps sobre reglas de alerta mal diseñadas solo agrupa mejor el ruido. Si tus alertas todavía no se basan en objetivos de nivel de servicio, empieza por ahí; lo tratamos en alertas sin fatiga.

Los datos que necesita antes de empezar

La calidad de los resultados depende menos del algoritmo que de cuatro conjuntos de datos. Recomendamos revisarlos antes de cualquier evaluación de herramientas.

Eventos y alertas normalizados

Cada herramienta de monitoreo emite eventos con su propio formato, severidad y nomenclatura. Para correlacionarlos hace falta un modelo común: un campo de severidad con valores acordados, un identificador del componente afectado que coincida con el de la CMDB, marca de tiempo sincronizada y un estado claro (abierta o resuelta). Sin esto, dos alertas del mismo servidor con nombres distintos se tratan como problemas distintos.

Topología y CMDB confiables

La correlación por topología necesita saber qué depende de qué: qué aplicación corre en qué servidor, qué servicio llama a qué base de datos. Si la CMDB tiene relaciones desactualizadas, la plataforma agrupará alertas que no tienen relación y separará las que sí la tienen. Las fuentes automáticas ayudan, como el descubrimiento de la propia plataforma de monitoreo y las trazas distribuidas. OpenTelemetry, cuya especificación de trazas alcanzó la versión 1.0 estable este año, ofrece una forma abierta de capturar las dependencias reales entre servicios.

Registro de cambios

Muchos incidentes siguen a un cambio. Para que la plataforma pueda sugerir "este grupo de alertas empezó diez minutos después de este despliegue", los cambios deben registrarse con la hora real de ejecución, los componentes afectados y el resultado. Los cambios hechos fuera del proceso son invisibles para el análisis.

Incidentes etiquetados

Para evaluar si la correlación acierta, y para ajustar los modelos que la producen, hace falta un historial de incidentes con el servicio afectado, la causa registrada al cierre y la relación con problemas conocidos. Aquí la práctica de gestión de problemas de ITIL 4 aporta lo que ninguna herramienta trae de fábrica: causas documentadas y errores conocidos.

Checklist de datos previos

Revísala con los dueños de cada fuente antes de definir el alcance:

• Todas las herramientas de monitoreo envían eventos a un punto común con un esquema acordado.
• La severidad se expresa con una escala única y documentada.
• Cada evento identifica el componente con el mismo nombre que usa la CMDB.
• Los relojes de los sistemas están sincronizados.
• Los servicios críticos tienen sus dependencias registradas y validadas recientemente por su dueño.
• Los cambios en producción se registran con hora de ejecución y componentes afectados.
• Los incidentes cerrados tienen servicio, causa y categoría completos, y sabes en qué proporción.
• Tienes una línea base: volumen de alertas por día, porcentaje de alertas sin acción y tiempos medios de detección y resolución.

Si varios puntos fallan, el primer trimestre del proyecto será de datos, no de algoritmos. Es mejor saberlo antes de firmar.

El primer año, trimestre a trimestre

Un plan realista avanza de lo más simple a lo más exigente. Las capacidades que dependen de topología e historial llegan después de las que solo necesitan eventos bien formados.

Primer trimestre: datos y línea base

Integrar las fuentes de eventos, normalizar el esquema, depurar las relaciones de la CMDB de los servicios críticos y medir la situación de partida. El entregable no es una reducción de alertas: es un inventario de fuentes, un esquema común y una línea base con la que comparar. Es también el momento de elegir un alcance acotado, por ejemplo dos o tres servicios críticos, en lugar de toda la operación.

Segundo trimestre: reducción de ruido

Activar deduplicación, supresión y agrupación por servicio en el alcance elegido. Aquí aparecen los primeros resultados medibles: menos alertas que llegan a una persona por cada incidente real. Las reglas se ajustan cada semana con el equipo que opera, que es quien distingue una agrupación útil de una que esconde información.

Tercer trimestre: correlación asistida

Con la topología depurada y los cambios registrados, la plataforma puede proponer qué alertas pertenecen al mismo incidente y qué cambio reciente es el candidato más probable. Recomendamos que, en esta etapa, la sugerencia aparezca en el ticket y que el resolutor indique si acertó. Esa respuesta es el dato que permite medir la precisión. El método de investigación sigue siendo el del equipo: formular hipótesis y probarlas, como plantea el capítulo "Effective Troubleshooting" del libro de SRE. Lo describimos en causa raíz en sistemas distribuidos.

Cuarto trimestre: anomalías y ajuste

Activar la detección de anomalías solo en métricas con historial suficiente, patrones estables y relación directa con un síntoma que percibe el usuario. Revisar los resultados del año contra la línea base, decidir qué servicios se incorporan y qué respuestas automáticas tienen sentido. Esos casos entran al backlog con el mismo criterio que cualquier otra automatización, como explicamos en gobernar el backlog de automatización.

Qué no esperar el primer año

• Predicción de incidentes. Anticipar fallas exige historial largo, datos consistentes y fallas que se repiten con patrones reconocibles. En el primer año, lo razonable es detectar antes, no predecir.
• Causa raíz automática. La plataforma sugiere candidatos. Confirmar la causa sigue siendo trabajo del equipo y de la gestión de problemas.
• Remediación sin intervención humana. Ejecutar acciones automáticas a partir de una correlación cuya precisión no se ha medido traslada el riesgo, no lo reduce. Primero se mide; después se automatiza, empezando por acciones reversibles.
• Cobertura total. Pocos servicios bien instrumentados enseñan más que toda la operación con datos irregulares.
• Cifras de reducción prometidas por adelantado. El efecto depende del punto de partida. Si alguien te garantiza un porcentaje sin conocer tus datos, pídele que lo justifique con tu línea base.

Cómo medir si funciona

Las métricas se definen en el primer trimestre, junto con la línea base, y se revisan cada mes. Proponemos un conjunto corto:

Métrica	Qué indica
Alertas que llegan a una persona por incidente	Efecto de la reducción de ruido
Porcentaje de alertas sin acción	Calidad de las reglas de origen
Grupos de correlación confirmados por el resolutor	Precisión de la correlación
Causa sugerida aceptada al cierre	Utilidad del apoyo a la causa raíz
Tiempo medio de detección y de resolución	Impacto en el servicio
Anomalías revisadas que resultaron reales	Relación entre señal y ruido de los modelos

Dos cuidados. Primero, los tiempos medios mezclan incidentes muy distintos; conviene mirarlos por servicio y por severidad. Segundo, una reducción de alertas puede ser mala noticia si se suprimió algo que importaba. Por eso cada regla de supresión necesita un dueño y una revisión periódica.

Dónde encaja en la gestión de servicios

AIOps no es una práctica nueva, sino una capa de apoyo para prácticas que ya existen. En ITIL 4 alimenta la gestión de incidentes (detección y agrupación más rápidas), la gestión de problemas (patrones recurrentes y candidatos a error conocido) y la monitorización y gestión de eventos. En términos de SRE, ayuda a que quienes atienden la guardia reciban menos interrupciones sin valor, uno de los objetivos que el libro de Google plantea para cualquier sistema de monitoreo.

Esa perspectiva ordena la decisión de compra. La pregunta no es qué plataforma tiene más algoritmos, sino qué práctica quieres mejorar, con qué datos cuentas hoy y cómo vas a medir el cambio. Si las respuestas son claras, el primer año da resultados concretos. Si no lo son, el primer trimestre sirve para aclararlas.