Tu monitoreo no tiene un problema de alertas, tiene un problema de contexto
Mil alertas por noche no son mil problemas. Cómo una regla de dos líneas convirtió el ruido de una red FTTH en incidentes sobre los que se puede actuar.
El turno noche de un NOC chico se parece siempre a lo mismo: una pantalla con cientos de líneas rojas y una persona decidiendo, a ojo, cuáles importan. No es que falte monitoreo. Sobra.
Durante nueve años estuve del otro lado de esa pantalla. Lo que aprendí es que el problema casi nunca es que falten alertas: es que cada alerta llega sola, sin nada alrededor que explique qué significa.
Una alerta no es un incidente
Un equipo que reporta pérdida de señal puede estar roto, o puede ser que alguien cortó la luz en la manzana, o que el equipo se reinició solo y volvió. Tres situaciones muy distintas que generan exactamente la misma línea roja.
El operador resuelve eso cruzando datos en la cabeza: mira si el mismo equipo tiró otra cosa hace un rato, si los vecinos también se quejan, si hay trabajo programado. Ese cruce es trabajo real, se hace a mano y se hace mal cuando hay sueño.
La pregunta que vale la pena hacerse no es “¿cómo mando menos alertas?” sino “¿qué tiene que pasar para que esto merezca que alguien se levante?”.
La regla que terminé usando
En FTTH-Copilot, el agente de diagnóstico que escribí para redes FTTH, la respuesta terminó siendo bastante aburrida, y por eso funciona:
Agrupar las alertas por dispositivo. Abrir un incidente solo cuando un mismo dispositivo reporta al menos dos tipos distintos de alerta dentro de una ventana de tiempo.
Nada más. No hay modelo, no hay umbral mágico, no hay promedio móvil.
¿Por qué dos tipos distintos? Porque el ruido tiende a repetirse igual a sí mismo. Un enlace que titila manda cien veces la misma alerta de pérdida de señal. Un equipo que de verdad se está muriendo manda cosas diferentes: primero la potencia óptica cae, después la temperatura sube, después se pierde. Dos señales distintas en el mismo lugar son mucho más difíciles de explicar por casualidad que cien señales iguales.
El código que hace esto entra en una pantalla. Está publicado en el repositorio, en packages/alerts/src/correlate.ts, y la constante que define el mínimo se llama DEFAULT_MIN_KINDS. Vale 2.
Lo que nadie te cuenta de las ventanas de tiempo
La parte difícil no es la regla, es decidir cuánto dura la ventana y cuándo se cierra el incidente.
Si la ventana es muy corta, perdés correlaciones reales: la temperatura tarda en subir. Si es muy larga, empezás a juntar cosas que no tienen nada que ver y volvés al ruido, solo que ahora el ruido viene agrupado y parece más serio.
No hay un número correcto. Lo que sí hay es un método: mirá los incidentes reales de los últimos meses, medí cuánto tardó en aparecer la segunda señal, y usá ese percentil. Si no tenés ese histórico, empezá corto y andá estirando. Es más barato perder una correlación que inventarla.
Cómo saber si está funcionando
Dos métricas alcanzan, y ninguna de las dos es “cantidad de alertas”:
- Incidentes por turno. Si baja y el tiempo de resolución no empeora, ganaste.
- Incidentes que el operador cerró sin hacer nada. Si este número crece, tu regla está agrupando ruido y dándole categoría de incidente. Es peor que no agrupar.
El segundo es el que importa. Un sistema que te miente con confianza hace más daño que uno que te grita.
Para llevarte
Si tu monitoreo te está ahogando, antes de comprar una herramienta nueva probá esto: agrupá por entidad —dispositivo, servicio, cliente, lo que tenga sentido en tu dominio— y exigí dos señales distintas antes de molestar a una persona. Es una tarde de trabajo y suele alcanzar.
La herramienta cara viene después, si de verdad hace falta. Casi nunca hace falta.