Finuslugi puso en marcha agentes de AI nocturnos: detectaron problemas en 1600 registros sin que saltaran las alertas

Los problemas más molestos en producción no parecen incidentes. Los gráficos principales están en verde, no saltan alertas y el servicio está disponible, pero en un paso del recorrido del usuario aumenta la proporción de operaciones fallidas o el tiempo de respuesta. Para el sistema en su conjunto, todo va bien; para una persona concreta, el producto está roto.

El equipo de registro de Finuslugi repetía manualmente el mismo recorrido cada semana: Grafana, después los logs en OpenSearch y, por último, la búsqueda de la operación de negocio problemática y del código relacionado. Esto consumía entre cuatro y ocho horas semanales, antes incluso de que un ingeniero empezara a pensar qué había que corregir. El equipo decidió automatizar precisamente esa parte: la recopilación de hechos y la preparación de una hipótesis, sin delegar la toma de decisiones.

Cómo funciona el sistema nocturno

Una programación crea una tarea —en Multica, esta función se llama Autopilot— que recoge OpenCode. A continuación entra en acción el agente coordinador: mediante MCP, lee en Confluence el catálogo de operaciones de negocio y las reglas de control de cada una. En el escenario básico de Prometheus hay 21 operaciones. El agente coordinador las distribuye entre siete agentes secundarios, tres para cada uno, que revisan sus áreas en paralelo.

El diagnóstico se divide deliberadamente en dos etapas. En la primera, un agente recopilador trabaja dentro de un único entorno de observabilidad y responde a una pregunta concreta: si existe una desviación y qué gravedad tiene. Compara los datos con el SLA y la referencia de base, y asigna el estado OK, WARNING o BREACH. El resultado es una ficha breve: operación, valor real, SLA, referencia de base y datos que respaldan el resultado. Solo los casos WARNING y BREACH pasan al agente analista. Este abre el repositorio relacionado y formula una hipótesis sobre la causa.

Si se confirma la desviación, Multica prepara un borrador de tarea en Jira. Incluye la operación de negocio, los valores de las métricas, el incumplimiento del SLA, el contexto técnico, la causa y una propuesta de corrección. La palabra clave es «borrador»: un ingeniero comprueba las conclusiones antes de incorporar la tarea al backlog.

Por qué no basta con darle todos los logs al modelo

La tentación es comprensible: «revisa todos los servicios, las métricas, los logs y el código, y encuentra algo sospechoso». En la práctica, una petición así choca con el tiempo de ejecución, el tamaño del contexto y la calidad de la respuesta. Cuanto más heterogéneos son los datos, más difícil resulta entender en qué se apoya la hipótesis.

Por eso, los SLA y la observabilidad acotan primero la búsqueda, y cada subtarea sirve a la vez como unidad de ejecución paralela y como límite del contexto. Esto aporta varias ventajas prácticas: los cálculos deterministas se mantienen separados del razonamiento del LLM, se puede volver a ejecutar por separado la parte que haya fallado y la calidad se evalúa para cada rol y cada resultado concreto.

Tres fuentes, tres capas de problemas

El sistema se amplió de forma gradual, y cada fuente respondía a una pregunta distinta.

• Prometheus muestra dónde ha cambiado algo: tasa de fallos, latencia y cumplimiento de los SLA por operación. La primera versión, basada en métricas y código, encontró problemas en aproximadamente 1000 registros.
• OpenSearch explica qué ocurrió exactamente: códigos HTTP, mensajes de error y trazas de pila. Esto permitió detectar otros 600 registros afectados, aproximadamente. Si la causa está en un servicio de otro equipo, el agente puede acceder al repositorio de ese equipo si dispone de permisos; la relación se determina a partir de las llamadas de Feign.
• Sentry aportó una nueva clase de señales: errores de frontend y velocidad de carga de las páginas. Una página sin errores que tarda un minuto en cargar no funciona para el usuario, y la tasa de fallos del backend no lo refleja.

Después de cada ronda de correcciones, los resultados se estancaban hasta que se incorporaba la siguiente fuente. Los autores exponen la conclusión con franqueza: la mejora procedía de ampliar la visibilidad, no de la «inteligencia» del modelo.

Limitaciones y qué hacer en la práctica

La tasa de fallos no se puede calcular con una única fórmula. Los códigos 500 y 401/403/422 tienen significados distintos, los errores esperados, como una sesión caducada, tienen su propio umbral aceptable y algunas operaciones tienen excepciones específicas. La utilidad del agente depende directamente de la precisión con la que el equipo haya descrito las operaciones, los SLA, la referencia de base y el significado de las señales. La AI no sustituye al modelo de observabilidad: se apoya en él.

El propio sistema de diagnóstico pasa a ser un sistema de producción, por lo que también necesita monitorización: estabilidad de las ejecuciones, proporción de falsos positivos y utilidad de los informes. Revisad también el recorrido que llevó al agente a su conclusión. Un falso positivo indica que hay que precisar el SLA o la fórmula. Si faltan datos, mejorad la observabilidad o la skill de recopilación de contexto. Si eligió el repositorio equivocado, mejorad la skill de análisis de dependencias. Si el informe contiene demasiado ruido, haced más estricto el contrato.

Si queréis reproducir este enfoque, no empecéis por el agente. Primero, formalizad qué se considera un problema y con qué se deben comparar las señales; de lo contrario, el LLM se limitará a reproducir vuestra incertidumbre. Definid el informe final como un contrato: operación, gravedad, hechos, impacto, código, hipótesis, nivel de confianza y siguiente acción.

El equipo planea acortar el recorrido entre la hipótesis y la corrección: correcciones habituales y MR en lugar de un borrador en Jira. Pero cuanto más se acerca el agente a modificar producción, más importantes son la revisión humana, el control de acceso y la reproducibilidad. Por ahora, la ventaja está en los roles acotados, los límites claros y una persona en el punto de decisión, no en un «ingeniero de AI» autónomo.