Fadiga de alertas: como o NOC separa ruído de incidente real

📚 Continue aprendendo sobre este tema:

Como uma operação chega a esse ponto

Nenhuma empresa decide receber centenas de alertas por dia. Ela chega lá por acúmulo, quase sempre pelo mesmo caminho:

A ferramenta foi ligada no padrão de fábrica. Toda métrica disponível virou alerta, com o limiar que veio de fábrica, que não conhece o seu ambiente.
O limiar é instantâneo. Um pico de dois segundos de processamento dispara aviso, mesmo sem nenhum efeito para o usuário.
Cada elemento alerta por conta própria. Um link cai e trinta equipamentos atrás dele avisam que estão inacessíveis. Trinta alertas para um problema.
Não existe janela de manutenção declarada. A equipe reinicia um servidor às duas da manhã, dentro do combinado, e o monitoramento acorda o plantão.
Alerta informativo virou notificação. Backup concluído com sucesso, serviço reiniciado, disco a 60%. Informação útil em relatório, ruído no celular do plantonista.
Ninguém é dono do alerta. A regra foi criada por alguém que já saiu, ninguém sabe por que ela existe e ninguém se sente autorizado a desligar.

O resultado é sempre o mesmo. Depois de algumas semanas, o time cria uma regra mental de sobrevivência: ignorar primeiro, verificar se sobrar tempo. A partir daí, o monitoramento continua funcionando e a empresa está, na prática, sem monitoramento.

O custo real, em linguagem de diretoria

Vale traduzir o problema para o que a diretoria acompanha:

O tempo até alguém reconhecer o alerta aumenta. O aviso chegou no horário certo e ficou parado na fila junto com dezenas de outros.
O tempo de resolução aumenta junto. Quando alguém finalmente olha, o problema já cresceu e a investigação começa mais atrasada.
O SLA de disponibilidade fica ameaçado por uma falha que foi detectada e não foi tratada, o que é bem pior do que uma falha não detectada.
A confiança na TI cai. Quando o usuário avisa antes do sistema de monitoramento, a diretoria conclui, com razão, que a ferramenta não serve.

Esse é o ponto em que muitos gestores pedem uma ferramenta nova. Trocar de ferramenta sem mudar o método reproduz o mesmo problema em outra tela. O que resolve é processo, e é isso que um NOC bem operado entrega.

Camada 1: limiar com duração, tendência e contexto

A maior parte do ruído nasce de limiares mal formulados. Três ajustes eliminam boa parte do volume, sem perder visibilidade:

Exija persistência. Não alerte por um pico. Alerte quando a condição se mantiver por um período que já indique problema real, por exemplo processamento alto de forma sustentada em vez de um pico isolado. Pico é gráfico, condição sustentada é alerta.
Prefira tendência a percentual fixo em disco. Um disco a 85% estável há meses não é urgência. Um disco a 60% que cresceu depressa nos últimos dias é. O alerta útil é o que projeta quando o espaço acaba, dando prazo de ação.
Meça o que o usuário sente. Tempo de resposta da aplicação, fila de impressão fiscal, atraso na integração, tempo de login. Métrica de recurso (processador, memória) explica a causa, métrica de experiência define a urgência.

Um cuidado adicional: use a linha de base do próprio ambiente. Consumo alto em uma noite de fechamento contábil pode ser normal, enquanto o mesmo consumo em uma manhã de domingo é anomalia. Referência para as métricas que valem a pena acompanhar está em as métricas essenciais de monitoramento de servidores.

Camada 2: correlação e supressão por dependência

Correlação é o que transforma trinta avisos em um incidente. O NOC mantém um mapa de dependências: qual servidor depende de qual link, qual aplicação depende de qual banco, qual serviço depende de qual autenticação.

Com esse mapa, quando o elemento de cima falha, os alertas dos elementos abaixo são agrupados como sintoma, não emitidos como novos problemas. O plantonista recebe um único chamado: link da unidade fora do ar, com trinta itens afetados listados dentro dele.

As formas de agrupamento que mais rendem no dia a dia:

Por dependência física. Caiu o link ou o comutador, tudo abaixo dele é consequência.
Por janela de tempo. Eventos do mesmo serviço em poucos minutos viram um único incidente, com contador de repetições.
Por repetição do mesmo objeto. Um serviço que reinicia várias vezes gera um alerta com contador, não um alerta por reinício.
Por causa provável. Alertas de latência, fila e tempo de resposta que aparecem juntos são apresentados como um só evento a investigar.

O ganho não é estético. Menos itens na tela significa que o analista lê o que está escrito, em vez de rolar a lista.

Camada 3: janela de manutenção e silenciamento com prazo

Manutenção programada não pode gerar alerta. Parece óbvio e é a fonte de ruído mais fácil de eliminar. O processo tem três regras:

Toda mudança planejada declara a janela no sistema de monitoramento, com início, fim e escopo exato dos itens afetados.
O silenciamento tem prazo e expira sozinho. Silenciamento sem data é como se o item tivesse sido removido do monitoramento, e é assim que uma máquina fica esquecida por meses.
Ao fim da janela, o sistema confirma que os itens voltaram ao estado normal. Se não voltaram, isso vira alerta imediato, porque uma manutenção que não terminou bem é um incidente em formação.

Vale a mesma disciplina para exceções temporárias durante um projeto: registre o motivo, o responsável e a data de reativação. Exceção sem data de revisão é o modo silencioso de desligar o monitoramento.

Camada 4: severidade que significa alguma coisa

Escala de severidade só funciona se cada nível disser, com clareza, quem é acionado, por qual canal e em quanto tempo. Se todo alerta é crítico, nenhum é.

Severidade	Definição pelo impacto no negócio	Canal	Quem atua
P1, crítica	Serviço essencial parado ou inacessível para muitos usuários. Faturamento, expedição ou ERP fora do ar	Ligação e acionamento do plantão, a qualquer hora	Analista de plantão, com escalonamento imediato ao coordenador
P2, alta	Degradação relevante ou falha em componente redundante. O serviço opera sem proteção	Notificação ativa, com prazo curto de reconhecimento	Analista de plantão, escalonando se não resolver no prazo
P3, média	Problema com impacto localizado ou risco previsível, como capacidade se esgotando em dias	Chamado na fila, em horário comercial	Equipe de sustentação, dentro do dia útil
P4, baixa	Registro para tendência, higiene e planejamento de capacidade	Relatório e painel, sem notificação	Revisão periódica, sem acionamento

Duas regras de disciplina que sustentam a tabela. Primeira: a severidade é definida pelo impacto no negócio, não pela emoção do momento nem pela cor que a ferramenta escolheu. Segunda: se um nível de severidade nunca é usado, ou é usado para tudo, a escala está errada e precisa ser revista.

A definição de severidade precisa conversar com o que está escrito no contrato de disponibilidade. Vale conferir o que o seu acordo cobre em SLA de disponibilidade e como cobrá-lo do provedor.

O teste de quatro perguntas para todo alerta

Antes de qualquer regra entrar em produção, ela passa por este crivo. Se falhar em uma das perguntas, ela não vira notificação.

Alguém precisa fazer algo agora? Se a resposta é não, o lugar disso é o painel ou o relatório semanal.
Está claro o que fazer? Se o analista precisa perguntar a outra pessoa o que significa o alerta, falta o procedimento escrito.
Qual o impacto para o negócio? O texto do alerta precisa dizer o que para de funcionar, não apenas o nome técnico do objeto.
Quem é o dono? Toda regra tem um responsável nomeado e uma data de revisão.

Runbook: o que precisa estar escrito em cada alerta

Runbook é o procedimento associado ao alerta. Ele é o que permite que o plantonista da madrugada aja com segurança sem depender da memória de um colega. O conteúdo mínimo:

Campo	O que precisa conter
Nome e significado	O que exatamente disparou, em uma frase que um plantonista entenda às três da manhã
Impacto no negócio	Que processo para ou fica degradado, e quem sente primeiro
Primeiras verificações	Os três primeiros comandos ou telas a checar, na ordem
Ação autorizada	O que o plantonista pode fazer sozinho e o que exige aprovação
Critério de escalonamento	Em quanto tempo, e para quem, se não resolver
Falso positivo conhecido	Situações em que o alerta dispara sem problema real, com o motivo
Dono e data de revisão	Quem responde por essa regra e quando ela será reavaliada

O campo de falso positivo conhecido é o que mais reduz fadiga ao longo do tempo. Ele documenta o que a equipe já aprendeu e evita que cada plantonista redescubra a mesma exceção sozinho.

Escalonamento e plantão

Alerta sem caminho de escalonamento acaba na mesma pessoa, sempre, até ela se desgastar. O desenho que funciona:

Escala publicada com antecedência, com nome, telefone e período de cada plantonista, e um substituto definido.
Reconhecimento obrigatório. O alerta precisa ser reconhecido dentro de um prazo. Se não for, ele escala automaticamente para o próximo nível.
Escalonamento por tempo e por severidade. P1 escala mais rápido e mais longe, incluindo a comunicação ao gestor de negócio afetado.
Comunicação separada da técnica. Durante um incidente grande, alguém cuida do problema e outra pessoa cuida de informar as áreas. Quando é a mesma pessoa, uma das duas coisas não acontece.
Encerramento com registro. Causa, ação tomada e ajuste necessário na regra de monitoramento, se houver.

Higiene contínua: a rotina que impede o ruído de voltar

Calibrar uma vez não resolve. O ambiente muda, entram sistemas novos e o ruído volta a crescer. A rotina que mantém o painel limpo:

Semanal: revisar os dez alertas que mais dispararam. Para cada um, decidir entre ajustar o limiar, correlacionar, corrigir a causa raiz ou desligar a regra.
Semanal: listar os alertas que dispararam e não geraram nenhuma ação. Esses são candidatos naturais a virar painel.
Mensal: verificar quais regras não têm runbook e quais não têm dono.
Mensal: conferir o inverso, que é o mais perigoso. Houve incidente percebido pelo usuário sem alerta correspondente? Cada caso desses é uma lacuna de cobertura.
Trimestral: revisar a escala de severidade e o mapa de dependências, incorporando o que mudou no ambiente.
A cada nova entrada em produção: nenhum sistema novo entra sem regra de monitoramento, runbook e dono definidos.

Os indicadores que mostram se essa rotina está funcionando cabem em um relatório de uma página para a diretoria, e conversam diretamente com os indicadores de TI que a diretoria cobra:

Indicador	O que ele revela
Alertas por dia, por severidade	O volume que a equipe precisa avaliar. Se cresce sem que o ambiente cresça, é ruído
Proporção de alertas que viraram ação	Mede a utilidade real do monitoramento. Proporção baixa é fadiga em formação
Tempo médio até o reconhecimento	Mostra se o aviso está chegando a alguém disponível de fato
Incidentes descobertos pelo usuário	Toda ocorrência aqui é uma falha de cobertura, não de atendimento
Alertas sem runbook	Dívida operacional que aparece justamente na madrugada
Silenciamentos ativos e há quanto tempo	Revela o que está fora do radar sem que ninguém tenha decidido isso

O que dá errado quando se pula uma etapa

Calibrar limiar sem mapear dependência: o volume cai um pouco, mas uma queda de link continua gerando dezenas de avisos simultâneos.
Correlacionar sem definir severidade: os alertas ficam agrupados e continuam todos parecendo urgentes.
Definir severidade sem runbook: o plantonista sabe que é grave e não sabe o que fazer, então liga para alguém, sempre.
Escrever runbook e não revisar: o procedimento aponta para um servidor que já foi desativado e mina a confiança no restante.
Silenciar em vez de corrigir: a solução mais rápida e a mais perigosa. O alerta some, o problema fica.

O objetivo final não é ter poucos alertas, é ter apenas alertas que merecem atenção humana. Uma operação madura pode monitorar muito mais itens do que antes e ainda assim notificar menos, porque a maior parte do que é coletado vira painel, tendência e capacidade, e só o que exige ação chega a uma pessoa.

Perguntas frequentes

Quantos alertas por dia é um número saudável?

Não existe número universal, porque depende do tamanho do ambiente. O indicador honesto é outro: a proporção de alertas que resultaram em alguma ação. Se a maior parte do que chega ao plantonista é fechada sem nenhuma providência, o volume está alto demais, seja ele qual for. Acompanhe essa proporção mês a mês, ela diz mais do que a contagem absoluta.

Desligar alertas não aumenta o risco de perder uma falha?

Desligar a coleta aumenta. Desligar a notificação de algo que não exige ação, não. A diferença é essencial: o dado continua sendo coletado, guardado e exibido em painel e relatório, e apenas deixa de acordar alguém. O risco real está em manter notificações inúteis, porque elas escondem o alerta que importa no meio do volume.

Dá para fazer isso sem contratar um NOC?

O método é o mesmo em equipe interna, e ele funciona. O que muda é a sustentação: manter reconhecimento em minutos nas 24 horas, incluindo madrugada, fim de semana e feriado, exige escala de pessoas, o que costuma pesar em equipe enxuta. Muitas médias empresas mantêm a operação de horário comercial internamente e contratam a cobertura fora do horário. O ponto inegociável é que a calibragem, o runbook e a revisão periódica existam, com ou sem NOC contratado.

Como o NOC 24x7 da BS IT Solutions trata alertas

A BS IT Solutions opera monitoramento com limiares calibrados pela linha de base de cada ambiente, mapa de dependências para correlacionar eventos, janelas de manutenção declaradas, escala de severidade acordada com o cliente e runbook por tipo de alerta, com escalonamento por tempo e por criticidade. A revisão dos alertas mais ruidosos é rotina, não exceção. Atendemos infraestrutura, servidores, nuvem e ambientes SAP, de forma presencial em São Paulo e região metropolitana e remota em todo o Brasil, com o NOC 24x7 integrado às práticas de segurança e gestão.

Fale com um especialista da BS IT Solutions e transforme o seu painel de alertas em informação acionável.