Está bem, amigos. Chris Wade aqui, novamente nas trincheiras digitais para agntlog.com. Hoje não estamos apenas explorando um conceito; estamos nos aprofundando em algo que, sinceramente, não me deixa dormir à noite. Não de uma forma negativa, geralmente. Mais de uma maneira tipo “e se eu perdi aquela única coisa?”. Estamos falando de alerting, em particular, de como muitas vezes erramos, e de como corrigir isso antes que nos custe mais do que apenas falta de sono.
A data atual é 29 de março de 2026. E se você é como eu, sua caixa de entrada, Slack, ou qualquer plataforma de comunicação que você utiliza provavelmente está transbordando com notificações. A maioria delas é inútil. E isso, meus amigos, é o ângulo oportuno em que vamos nos concentrar hoje. Nos tornamos tão bons em coletar dados, tão hábeis em monitorar cada pequeno movimento em nossos sistemas, que esquecemos completamente o propósito de um aviso: nos dizer quando algo realmente precisa da nossa atenção, agora mesmo.
A epidemia de fadiga por notificações: minha batalha pessoal
Sendo real por um momento. Meu primeiro trabalho de verdade após a faculdade, eu fazia parte de uma pequena equipe que gerenciava uma plataforma SaaS bastante complexa. Éramos jovens, ambiciosos e completamente convencidos de que mais avisos significavam mais controle. Oh, quão ingênuos éramos. Cada pico da CPU acima de 70%, cada alocação de memória que ultrapassava determinado limite, cada único erro HTTP 500 – tudo isso ativava um aviso. E não eram apenas indicadores no painel; eram chamadas de PagerDuty, inundações de e-mails e tempestades nos canais do Slack.
Lembro de uma manhã de terça-feira, por volta das 3 da manhã. Meu telefone vibrava na mesa de cabeceira. PagerDuty. Aviso crítico. “Uso do pool de conexões ao banco de dados acima de 80%.” Meu coração pulou. Busquei meu laptop, conectei-me com a VPN e comecei a investigar. Aconteceu que era um trabalho de backup noturno programado que temporariamente, por cerca de 15 minutos, aumentou o uso do pool de conexões. Era um comportamento completamente normal, previsto. Mas como não consideramos o contexto, como não sintonizamos nossos avisos, eu estava encarando uma tela às 3 da manhã sem nenhum bom motivo.
Esse foi um momento crucial para mim. Não se tratava apenas da falta de sono; estava relacionado à dessensibilização que se seguiu. Após algumas semanas de falsos alarmes, os avisos críticos autênticos começaram a se confundir. Essa é a fadiga por notificações. É insidiosa. Transforma seu sistema de monitoramento altamente sintonizado em ruído de fundo, e quando um verdadeiro incêndio estoura, você está menos propenso a notar, para não falar de responder de forma eficaz.
Além do limiar: o que torna um bom aviso?
Portanto, se “mais avisos” não é a resposta, qual é? Para mim, um bom aviso tem três características fundamentais:
- Acionável: Diz algo em que você realmente pode agir.
- Oportuno: Te atinge quando importa, não muito cedo, não muito tarde.
- Contextualizado: Fornece informações suficientes para entender o problema sem escavações profundas.
A maioria de nós é bastante boa na parte “oportuna”, graças às ferramentas de monitoramento modernas. Mas “acionável” e “contextualizado” são onde muitas vezes falhamos. Configuramos um aviso para “uso da CPU > 90% por 5 minutos.” Ok, acionável? Talvez. Se significar um processo fora de controle, com certeza. Mas o que acontece se for um trabalho em lote que deve maximizar a CPU por 10 minutos todo dia às 13:00? É aqui que o contexto entra em cena.
De sintomas à doença: avisar sobre os impactos
Em vez de avisar apenas sobre métricas brutas, precisamos mudar nossa forma de pensar para avisar sobre os impactos. O que significa um alto uso da CPU para seus usuários? O que um pico no pool de conexões ao banco de dados se traduz em termos de disponibilidade do serviço ou de desempenho? É aqui que os Objetivos de Nível de Serviço (SLO) se tornam incrivelmente poderosos, mesmo que você não seja um verdadeiro SRE. Eles te dão um objetivo, e você avisa quando está em perigo de não alcançá-lo.
Digamos que você tenha um SLO para sua API principal: 99,9% das solicitações devem ser concluídas em até 500 ms em um intervalo de 5 minutos. Você não avisa apenas sobre alta CPU. Você avisa quando a taxa de erro aumenta ou sua latência supera constantemente aquele limiar de 500 ms. A CPU pode ser um fator contribuinte, mas o impacto em seus usuários é o que realmente importa para você.
Aqui está um exemplo simplificado de como você poderia definir um aviso baseado em um SLO para uma fictícia API de e-commerce, talvez usando Prometheus e Alertmanager:
groups:
- name: api-slos
rules:
- alert: HighAPILatency
expr: |
(
sum(rate(http_request_duration_seconds_bucket{le="0.5", job="ecomm-api"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="ecomm-api"}[5m]))
) < 0.999
for: 5m
labels:
severity: critical
annotations:
summary: "A latência da API de e-commerce está superando o SLO"
description: "Menos de 99,9% das requisições da API são concluídas em até 500 ms nos últimos 5 minutos. Isso está impactando a experiência do usuário."
runbook: "https://your-runbook-url/api-latency-troubleshooting.md"
Este alerta não está simplesmente dizendo "algo está lento." Está dizendo "sua API está falhando em seu objetivo de performance." É muito mais significativo.
O problema do "vizinho barulhento": agrupamento e deduplicação
Uma outra fonte comum de fadiga por alertas é o problema do "vizinho barulhento". Uma causa raiz pode ativar uma cascata de alertas relacionados. Seu banco de dados caiu? De repente, todos os serviços que se conectam a ele começam a gritar por erros de conexão. Em vez de receber um alerta sobre o banco de dados, você recebe dezenas sobre os serviços a montante. É aqui que o agrupamento e a deduplicação inteligentes entram em cena.
A maioria dos modernos sistemas de gerenciamento de alertas (pense em PagerDuty, Opsgenie, VictorOps, e até em configurações sofisticadas do Alertmanager) tem a capacidade de agrupar alertas com base em atributos comuns. Se múltiplos alertas chegarem com o mesmo host, serviço ou padrão de mensagem de erro, eles podem ser consolidados em um único incidente. Isso reduz significativamente o barulho.
Diga que você tem vários microserviços, e todos dependem de uma fila de mensagens compartilhada. Se a fila de mensagens cair, cada microserviço provavelmente reportará "impossível conectar à fila de mensagens." Em vez de alertas individuais, você quer um incidente sobre a fila de mensagens que está fora do ar. Isso muitas vezes envolve a definição de regras de correlação. Por exemplo, em um sistema mais avançado, você poderia configurar uma regra que diz: "Se mais de 3 alertas com 'erro de conexão à fila de mensagens' aparecerem dentro de 1 minuto, crie um incidente intitulado 'Fila de Mensagens Indisponível'."
Exemplo: Roteamento simples do Alertmanager para problemas específicos do serviço
Embora a correlação completa seja complexa, até mesmo um roteamento simples ajuda. Aqui está um trecho que mostra como o Alertmanager pode encaminhar alertas com base em um rótulo `service`, garantindo que os alertas para um serviço não inundem o canal de outro e, potencialmente, agrupando-os se chegarem ao mesmo receptor:
route:
receiver: 'default-receiver'
group_by: ['alertname', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
routes:
- match:
service: 'payment-gateway'
receiver: 'payment-gateway-team'
group_by: ['alertname'] # Agrupa os alertas do gateway de pagamento de forma mais agressiva
- match:
service: 'user-auth'
receiver: 'user-auth-team'
Esta configuração agrupa os alertas por `alertname` e `service` como padrão, mas especificamente para o serviço `payment-gateway`, agrupa apenas por `alertname`, indicando que se chegarem mais tipos de alertas para o gateway de pagamento, eles ainda vão para o mesmo time e são agrupados juntos, reduzindo o número de notificações individuais.
Elemento humano: Runbook e resolução
Um alerta sem um caminho claro para a resolução é apenas uma reclamação. É aqui que entramos em runbooks. Todo alerta crítico deve ter um runbook associado - um conjunto de passos documentados para diagnosticar e idealmente resolver o problema. Não precisa ser um romance de várias páginas; até mesmo alguns pontos e links para dashboards ou logs relevantes podem fazer uma grande diferença.
Pense no meu incidente com o pool de conexões ao banco de dados às 3 da manhã. Se aquele alerta tivesse incluído uma nota dizendo “Se isso acontecer entre 2 e 4 da manhã, verifique os trabalhos de backup ativos. Comportamento esperado”, eu teria voltado a dormir imediatamente. O contexto e as instruções de resolução são vitais para reduzir o tempo médio de recuperação (MTTR) e, crucialmente, reduzir o estresse da disponibilidade.
Gosto de pensar nisso da seguinte forma: um alerta é uma pergunta. Um bom runbook é a resposta. Se o seu alerta pergunta “O que está acontecendo?”, seu runbook deve responder “Aqui está o que está acontecendo, e aqui está o que você deve fazer a respeito.”
Dicas práticas: Reconquiste sua saúde mental
Então, por onde começar se o seu sistema de alerta é um desastre? Aqui estão alguns passos práticos:
```html
- Audite seus avisos atuais: Revise cada aviso que você tem. Para cada um, pergunte-se:
- É acionável? Diz a alguém para fazer algo específico?
- É único? Poderia ser agrupado com outro aviso?
- Tem um runbook ou instruções claras para solução?
- Já gerou falsos avisos? Com que frequência?
- Está avisando sobre sintomas ou impactos reais (violações do SLO)?
Seja implacável. Se um aviso não passar nesses testes, desative-o ou melhore-o.
- Concentre-se em avisos baseados em SLO: Mude sua forma de pensar de métricas puramente infraestruturais para indicadores de nível de serviço. O que realmente importa para seus usuários? Avise quando estiverem em perigo.
- Implemente agrupamento inteligente e deduplicação: Configure seu sistema de gerenciamento de avisos para consolidar avisos relacionados em incidentes únicos. Esta é uma mudança fundamental para reduzir o ruído.
- Exija runbooks para avisos críticos: Torne obrigatório que cada aviso crítico criado tenha um runbook associado, mesmo que simples. Revise e atualize esses regularmente.
- Conduza post-mortem para falsos alarmes: Sempre que receber um falso aviso, trate-o como um incidente real. Faça um mini-post-mortem. Por que disparou? Como podemos prevenir que se repita? Foi um problema de sintonia? Falta contexto?
- Revise regularmente os limiares de aviso: Os sistemas evoluem. O que era um limiar crítico seis meses atrás pode ser um comportamento normal hoje. Dedique tempo trimestralmente para revisar e ajustar os limiares de aviso com base no comportamento atual do sistema.
- Políticas de escalonamento: Tenha caminhos de escalonamento claros. Nem todo aviso precisa acordar alguém às 3 da manhã. Classifique seus avisos por gravidade e assegure-se de que as pessoas certas sejam notificadas no momento certo.
Avisar não se trata apenas de configurar um monitor e pressionar "enviar". É uma arte. Requer um aperfeiçoamento contínuo, uma compreensão profunda do seu sistema e empatia pela pobre alma que é acordada por aquele pager. Sendo mais intencionais sobre o que avisamos, como agrupamos esses avisos e o contexto que fornecemos, podemos passar de uma epidemia de fadiga de avisos para um sistema que realmente nos permite manter nossos serviços saudáveis e nossos usuários felizes.
Aqui está tudo por hoje. Vá, audite esses avisos e recupere seu sono. Você merece.
```
🕒 Published: