Seu monitoramento não tem um problema de alertas, tem um problema de contexto
Mil alertas por noite não são mil problemas. Como uma regra de duas linhas transformou o ruído de uma rede FTTH em incidentes sobre os quais dá para agir.
O turno da noite de um NOC pequeno é sempre parecido: uma tela com centenas de linhas vermelhas e uma pessoa decidindo, no olho, quais importam. Não é que falte monitoramento. Sobra.
Durante nove anos estive do outro lado dessa tela. O que aprendi é que o problema quase nunca é a falta de alertas: é que cada alerta chega sozinho, sem nada em volta que explique o que significa.
Um alerta não é um incidente
Um equipamento que reporta perda de sinal pode estar quebrado, ou pode ser que alguém tenha cortado a energia no quarteirão, ou que ele tenha reiniciado sozinho e voltado. Três situações bem diferentes que geram exatamente a mesma linha vermelha.
O operador resolve isso cruzando dados de cabeça: olha se o mesmo equipamento reportou outra coisa há pouco, se os vizinhos também reclamam, se há trabalho programado. Esse cruzamento é trabalho de verdade, é feito à mão e é feito mal quando há sono.
A pergunta que vale a pena fazer não é “como mando menos alertas?”, mas “o que precisa acontecer para que isso mereça acordar alguém?”.
A regra que acabei usando
No FTTH-Copilot, o agente de diagnóstico que escrevi para redes de fibra, a resposta acabou sendo bem sem graça, e é por isso que funciona:
Agrupar os alertas por dispositivo. Abrir um incidente só quando o mesmo dispositivo reporta pelo menos dois tipos distintos de alerta dentro de uma janela de tempo.
Só isso. Sem modelo, sem limiar mágico, sem média móvel.
Por que dois tipos distintos? Porque o ruído tende a se repetir igual a si mesmo. Um enlace instável manda cem vezes o mesmo alerta de perda de sinal. Um equipamento que está realmente morrendo manda coisas diferentes: primeiro a potência óptica cai, depois a temperatura sobe, depois ele some. Dois sinais diferentes no mesmo lugar são muito mais difíceis de explicar por acaso do que cem sinais iguais.
O código que faz isso cabe em uma tela. Está publicado no repositório, em packages/alerts/src/correlate.ts, e a constante que define o mínimo se chama DEFAULT_MIN_KINDS. Vale 2.
O que ninguém conta sobre janelas de tempo
A parte difícil não é a regra, é decidir quanto dura a janela e quando o incidente fecha.
Se a janela for muito curta, você perde correlações reais: a temperatura demora para subir. Se for muito longa, começa a juntar coisas que não têm nada a ver e volta ao ruído, só que agora o ruído vem agrupado e parece mais sério.
Não existe um número certo. O que existe é um método: olhe os incidentes reais dos últimos meses, meça quanto tempo o segundo sinal levou para aparecer e use esse percentil. Se você não tem esse histórico, comece curto e vá esticando. É mais barato perder uma correlação do que inventar uma.
Como saber se está funcionando
Duas métricas bastam, e nenhuma delas é “quantidade de alertas”:
- Incidentes por turno. Se cai e o tempo de resolução não piora, você ganhou.
- Incidentes que o operador fechou sem fazer nada. Se esse número cresce, sua regra está agrupando ruído e dando a ele categoria de incidente. É pior do que não agrupar.
O segundo é o que importa. Um sistema que mente com confiança faz mais estrago do que um que grita.
Para levar
Se o seu monitoramento está te afogando, antes de comprar uma ferramenta nova tente isto: agrupe por entidade — dispositivo, serviço, cliente, o que fizer sentido no seu domínio — e exija dois sinais distintos antes de incomodar uma pessoa. É uma tarde de trabalho e costuma bastar.
A ferramenta cara vem depois, se realmente for preciso. Quase nunca é.