Fadiga de alertas: por que sua equipe ignora notificações (e como calibrar)

Pergunte a qualquer técnico que convive com um monitoramento mal configurado quantos e-mails de alerta ele recebeu hoje. A resposta costuma ser “sei lá, uns cinquenta”. Pergunte quantos ele abriu. A resposta é “nenhum”. Esse é o retrato da fadiga de alertas: um sistema que grita o tempo todo e, de tanto gritar, ensinou a equipe a não ouvir.

O problema é que, no meio dos cinquenta alertas ignorados, um dia vem o que importa — o servidor que está de verdade morrendo, o link que caiu, o disco que encheu. E ele chega exatamente igual aos outros quarenta e nove: mais um e-mail vermelho numa caixa que ninguém lê. A falha não foi de detecção. O monitoramento viu o problema. A falha foi de calibragem: o sinal se perdeu no ruído que o próprio sistema criou.

Como um monitoramento vira uma máquina de ruído

A fadiga de alertas quase sempre nasce da configuração padrão, aquela que vem quando se instala a ferramenta e se sai clicando “ok”. Alguns padrões produzem ruído com uma consistência impressionante.

Limiares irreais são o primeiro. Um alerta de CPU que dispara a 80% de uso vai tocar toda vez que um relatório pesado roda, todo backup noturno, toda indexação — momentos em que 80% de CPU é exatamente o esperado. O sensor está certo; o limiar é que é ingênuo. Ele trata comportamento normal como emergência.

Falta de duração é o segundo. Um pico de dois segundos não é um problema — é a vida normal de qualquer servidor. Mas um alerta que dispara no primeiro segundo acima do limiar vai avisar de cada soluço momentâneo. O que importa é o que fica alto, não o que pisca.

Ausência de hierarquia é o terceiro e o mais grave. Quando tudo é “crítico” — o disco em 60%, o site fora do ar, uma impressora offline — nada é crítico. A equipe não tem como saber, olhando a caixa de entrada, o que precisa de reação agora e o que pode esperar a segunda-feira. Já falamos sobre esse ajuste fino em como configurar alertas inteligentes no PRTG; a fadiga é o preço de pular essa etapa.

Calibrar é decidir o que merece interromper alguém

Calibrar alerta não é receber menos aviso por sorte. É desenhar, de propósito, o que dispara, quando dispara e para quem. E o princípio que organiza tudo é simples: um alerta existe para provocar uma ação. Se ninguém precisa fazer nada quando ele chega, ele não deveria ter chegado.

O primeiro passo é ajustar os limiares à realidade do ambiente. Isso quer dizer olhar como cada servidor se comporta em um dia normal antes de decidir o que é anormal. Um servidor de banco que vive em 70% de CPU precisa de um limiar diferente de um que vive em 20%. Sem essa linha de base, todo limiar é chute — e chute gera falso positivo.

O segundo é somar duração e tendência. Em vez de “avise se passar de X”, o alerta vira “avise se passar de X e ficar assim por Y minutos”. O pico momentâneo some do radar; o problema real, que persiste, aparece. Métricas bem escolhidas ajudam nisso — vale ver quais métricas de rede toda empresa deveria monitorar.

O terceiro, e o que mais reduz fadiga, é a hierarquia em níveis:

• Aviso — algo digno de nota, mas sem urgência. O disco passou de 70%. Ninguém precisa acordar; alguém precisa olhar essa semana. Vai para um painel, não para o telefone.
• Alerta — algo que precisa de atenção hoje. O backup falhou, o serviço reiniciou sozinho. Vai para o e-mail de quem cuida daquilo.
• Crítico — algo que trava a operação agora. O servidor de vendas caiu, o link principal está fora. Esse pode e deve interromper alguém, inclusive fora do horário.

Quando cada nível tem um canal e um destinatário próprios, o crítico deixa de se afogar no meio dos avisos. A equipe reaprende a confiar no sistema — porque quando o telefone toca, é porque é sério.

Ter a ferramenta não calibra sozinho

Aqui volta a tese que atravessa monitoramento inteiro: a ferramenta dispara o alerta, mas quem decide o que merece disparar é gente que conhece o ambiente. Nenhuma instalação padrão sabe que 80% de CPU é normal no seu servidor de banco, nem que a impressora da recepção offline não é uma emergência. Isso não vem na caixa. Vem de mapear o ambiente, medir o comportamento normal, definir os limiares e desenhar o escalonamento — o trabalho que separa um monitoramento que ajuda de um que vira spam.

É esse desenho que a Global Data trata como um projeto de monitoramento com PRTG: calibrar cada sensor para o seu ambiente, para que o alerta que chega seja sempre um alerta que pede ação. Quando esse acompanhamento precisa ser contínuo, com alguém de plantão respondendo ao que é crítico, ele se integra ao nosso monitoramento e NOC 24x7.

O ponto

Um monitoramento que gera fadiga é pior que nenhum, porque dá a ilusão de cobertura enquanto ensina a equipe a ignorar o próprio sistema. A meta não é o maior número de alertas — é o menor número de alertas que ainda pega tudo que importa. Alerta bom é alerta raro, e todo alerta raro é levado a sério.

Perguntas frequentes

O que é fadiga de alertas?

É o esgotamento que acontece quando o monitoramento dispara tantos avisos irrelevantes que a equipe passa a ignorar todos — inclusive os importantes. O sistema continua detectando problemas, mas o sinal se perde no ruído, e o alerta que exigia ação acaba tratado como mais um.

Como reduzir falsos positivos no monitoramento?

Ajustando os limiares ao comportamento real de cada servidor, exigindo que a condição persista por um tempo mínimo antes de disparar (para ignorar picos momentâneos) e acompanhando a tendência, não só o valor instantâneo. Limiares baseados na linha de base do ambiente eliminam a maior parte dos falsos positivos.

Como organizar alertas por prioridade?

Separando em níveis com canais distintos: aviso (vai para um painel, sem urgência), alerta (vai para o e-mail de quem cuida, precisa de atenção no dia) e crítico (pode interromper alguém, inclusive fora do horário). Quando cada nível tem destino próprio, o crítico não se afoga no meio dos avisos.

Todo alerta precisa chegar para todo mundo?

Não. Alerta que chega para quem não pode agir sobre ele é ruído garantido. Cada tipo de evento deve ir para quem tem a responsabilidade e a mão para resolver — o resto só contribui para a fadiga.

A Global Data ajuda a calibrar o monitoramento que já tenho?

Sim. Avaliamos o seu ambiente, medimos o comportamento normal de cada recurso e reconfiguramos os limiares e o escalonamento para que só dispare o que pede ação. Solicite uma avaliação para acabar com o ruído sem perder o que importa.