Um mergulho profundo em como auditar alertas barulhentos, definir SLOs acionáveis e fazer a transição para alertas baseados em sintomas.
O on-call não precisa ser um pesadelo de acordar às 3 da manhã por causa de avisos sem sentido. No entanto, para muitas equipes de engenharia, o pager se tornou uma fonte de angústia em vez de uma ferramenta para preservar a confiabilidade. Esse fenômeno é conhecido como fadiga de alertas, e é uma das principais causas de esgotamento para Engenheiros de Confiabilidade de Sites (SREs), profissionais de DevOps e desenvolvedores backend.
Quando os engenheiros são bombardeados por alertas não acionáveis — como picos temporários de CPU, backups de banco de dados travando linhas ou falhas transitórias de rede — duas coisas perigosas acontecem.
Neste guia, vamos detalhar o custo real da fadiga de alertas e fornecer um framework estruturado para auditar o ruído, migrar para alertas baseados em sintomas e tornar cada notificação acionável.
A fadiga de alertas ocorre quando o volume de alertas supera a capacidade dos engenheiros de investigá-los de forma significativa. Ela quebra fundamentalmente o ciclo de feedback da confiabilidade do sistema.
Historicamente, o monitoramento era construído em torno do hardware. Se um servidor atingisse 90% da capacidade do disco ou 95% da CPU, você precisava saber. Em um ambiente de nuvem moderno e elástico, os limites de infraestrutura geralmente são irrelevantes. Os grupos de autoscaling naturalmente elevam as restrições de CPU para maximizar a eficiência. Alertar sobre essas métricas de utilização gera falsos positivos que treinam os engenheiros a confirmar e voltar a dormir.
Considere a violação de dados da Target em 2013: os sistemas de monitoramento de segurança sinalizaram a intrusão com precisão, mas os avisos foram enterrados sob milhares de falsos positivos e notificações de rotina. Os alertas foram ignorados até que fosse tarde demais. O mesmo comportamento de ignorar alertas acontece com SREs em relação ao tempo de inatividade de aplicações.
Antes de consertar a infraestrutura de alertas, é preciso entender de onde vem o ruído. O princípio de Pareto se aplica fortemente aqui: tipicamente, 80% do ruído de alertas origina-se de cerca de 20% dos seus monitores.
Comece exportando os últimos 30 a 90 dias de dados de alertas da sua plataforma de gerenciamento de incidentes (ex.: PagerDuty, Opsgenie ou VictorOps). Agrupe os alertas por origem e serviço.
Identifique Alertas Oscilantes — monitores que disparam e se resolvem sozinhos em menos de 3 minutos sem intervenção humana. Esses são candidatos imediatos para remoção ou adição de um atraso (ex.: for: 5m no Prometheus).
Para monitores legados que disparam constantemente mas nunca resultam em um ticket de triagem ou post-mortem, considere a estratégia deletar e aguardar. Silencie ou delete o alerta. Se ninguém reclamar que um sistema caiu, o alerta era inútil.
A mudança arquitetural mais significativa que uma equipe pode fazer é migrar de alertas baseados em causa para alertas baseados em sintoma.
Você alerta sobre o estado da infraestrutura subjacente.
Você alerta estritamente quando a experiência do usuário realmente se deteriora.
Para garantir que um novo alerta não contribua para a fadiga, passe-o pelo teste "Posso resolver isso agora?" antes de colocar o monitor em produção.
Faça estas três perguntas:
Se um alerta é puramente informacional, ele pertence a um dashboard ou a um resumo diário no Slack — nunca ao pager.
Depois de eliminar os alertas de limites ruidosos, você deve substituí-los por Objetivos de Nível de Serviço (SLOs).
Um SLI (Indicador de Nível de Serviço) define a razão matemática de eventos bons para eventos totais. Um SLO é sua porcentagem alvo (ex.: 99,9% das requisições devem ter sucesso).
Em vez de alertar quando a taxa de erro sobe levemente, você alerta sobre a Taxa de Consumo do seu Budget de Erros. Se o budget de erros mensal está sendo consumido a uma taxa que o esgotará em 4 horas, isso gera uma notificação imediata. Se estiver vazando lentamente e esgotará em 3 dias, cria um ticket de prioridade padrão no Jira para o próximo sprint.
Nunca envie um alerta que simplesmente diga TAXA DE ERRO ALTA. Inclua contexto denso e acionável:
Vencer a fadiga de alertas exige uma mudança cultural — de medir a saúde dos servidores para medir a saúde dos usuários. Ao auditar incansavelmente os logs de alertas passados, deletar monitores inúteis e adotar SLOs baseados em sintomas, as equipes de engenharia podem recuperar o sono e restaurar a confiança no pager.
Plataformas profissionais de monitoramento sintético como o Heimdall podem ser fundamentais nessa transição. Ao executar probes externos centrados no usuário (como validação HTTP e testes de resolução DNS), o Heimdall fornece exatamente a telemetria baseada em sintomas necessária para criar alertas robustos e acionáveis que refletem com precisão a experiência real do usuário, sem o ruído das métricas de infraestrutura.
Junte-se a milhares de equipes que confiam no Heimdall para manter seus sites e APIs online 24/7. Comece com nosso plano gratuito hoje.
Comece a monitorar gratuitamente
Engenheiro de Confiabilidade de Sistemas (SRE) Sênior focado em disponibilidade, resposta a incidentes e construção de sistemas de monitoramento que antecipam problemas antes que os usuários percebam.
