Cuando una alerta deja de ser una emergencia
Cómo cambiamos la operación de infraestructura cuando le pusimos un agente entre la alerta y el equipo
Hace cuatro meses, una alerta crítica a las 3 de la mañana significaba que alguien del equipo de infraestructura se levantaba.
Hoy ya no.
No porque tengamos menos alertas. Tenemos las mismas, o más. Lo que cambió es lo que pasa entre que la alerta se dispara y el momento en que llega al equipo. En el medio, ahora, hay un agente de IA que la lee, la investiga y decide si vale la pena interrumpir a un humano.
Cómo eran las alertas antes
Las alertas críticas de nuestra plataforma llegaban al canal del equipo como un volcado de campos.
Algo así:
- Nombre de la regla
- Severidad
- Servicio afectado
- Timestamp
- Métrica que cruzó el umbral
- Algunos labels más
Eso era todo. Una pared de texto sin interpretación. El humano que la recibía tenía que hacer todo el trabajo cognitivo:
- Entender qué servicio era
- Recordar si esa alerta ya había aparecido antes
- Buscar el runbook (si existía)
- Decidir si era urgente o si podía esperar al horario laboral
- Investigar logs y métricas para confirmar el síntoma
- Recién ahí, decidir qué hacer
Una alerta cualquiera te robaba entre 15 y 40 minutos solo para entender qué estaba mirando. A las 3 de la mañana, esos 40 minutos pesan distinto.
El problema real no era la alerta
Cuando empezamos a discutir cómo mejorar esto, me di cuenta de algo.
El problema no era que llegaran muchas alertas. Era que cada alerta tenía el mismo costo cognitivo, fueran graves o triviales, fueran una recurrencia conocida o un caso completamente nuevo.
El equipo terminaba haciendo el mismo trabajo de investigación una y otra vez para problemas que ya habían pasado quince veces antes. El conocimiento institucional vivía en cabezas, no en sistemas. Y todos los humanos, eventualmente, dormimos.
La decisión: meter un agente en el medio
La idea fue simple: en vez de mandar la alerta directo al canal, la mandamos primero a un agente de IA. El agente toma el evento, lo cruza con la base de conocimiento del equipo, mira el historial de alertas similares y devuelve un diagnóstico estructurado. Recién después la card llega al canal, ya investigada.
Estructuramos el diagnóstico en cuatro secciones fijas, siempre las mismas:
- Situación — qué está pasando, en qué servicio, desde cuándo
- Impacto — qué efecto tiene del lado del negocio
- Acciones — qué se recomienda hacer ahora
- Historial — si ya pasó antes, cómo se resolvió
Esa estructura no es decorativa. Es la diferencia entre que el humano arranque investigando desde cero o arranque validando una hipótesis ya elaborada.
Lo que cambió
El cambio más visible: más de la mitad de las alertas críticas ya no llegan al equipo. El agente las clasifica, ve que son recurrencias conocidas con remediación clara, y las resuelve sin escalar. Quedan registradas en el historial, pero no interrumpen a nadie.
El cambio menos visible, pero más importante: cuando una alerta sí llega al equipo, llega con contexto. El humano que la recibe no arranca de cero. Arranca leyendo un diagnóstico que un analista senior tardaría 30 a 45 minutos en armar.
Resultado práctico: nuestro equipo de cinco personas opera con la capacidad de uno de diez o doce. Y duerme mejor.
Lo que aprendimos
El valor no estaba en automatizar la respuesta. Lo intuitivo cuando alguien dice “agentes de IA en operaciones” es pensar en agentes que actúan — que reinician servicios, escalan capacidad, hacen rollback. Esa fase nos parece interesante, pero la dejamos para más adelante. Empezamos por algo más humilde: agentes que investigan.
Los agentes que investigan tienen una propiedad muy buena: no rompen nada. Pueden equivocarse en el diagnóstico, pero el humano sigue siendo el que decide. Eso baja muchísimo la barrera para meterlos en producción.
El conocimiento institucional empieza a vivir en sistemas. Para que el agente diagnostique bien, hay que tener una base de conocimiento decente. Eso nos forzó a algo que el equipo venía postergando: documentar de verdad. Y descubrimos algo interesante: cuando la documentación tiene un consumidor que la lee siempre, en serio, los runbooks se cuidan distinto.
El UX de una alerta importa más de lo que parece. Antes pensábamos en alertas como un problema de signal-to-noise: bajar el ruido, subir la señal. Ahora las pensamos como un problema de interfaz: qué información necesita el humano, en qué orden, con qué densidad. La alerta dejó de ser una notificación para volverse un mini-reporte.
Lo que viene
El siguiente paso es que el agente no solo investigue, sino que aprenda de cómo lo resolvimos. Cada incidente que cierra un humano debería volver a alimentar la base de conocimiento, automáticamente, para que el próximo caso similar tenga un diagnóstico todavía más afinado.
También estamos empezando a explorar la posibilidad de que el agente pueda hacer remediaciones simples por sí solo, en operaciones de bajo riesgo y con guardrails claros. Pero eso es tema para otro post.
Cierre
La métrica que más me importa de todo este trabajo no es la cantidad de alertas filtradas, ni el tiempo ahorrado. Es otra: el equipo dejó de tenerle miedo a las notificaciones del celular fuera de hora.
Cuando una alerta deja de ser una emergencia, dos cosas pasan a la vez. Por un lado, el equipo recupera tiempo y cabeza. Por el otro, las alertas que sí son emergencias se vuelven más fáciles de identificar — porque ya no están enterradas entre las que no lo son.
Los agentes de IA no nos sacaron las alertas. Nos sacaron el peso.
¿Cómo manejan las alertas en tu equipo?