Contexto do problema: os canais de alerta crítico e de aviso (Warning) foram separados, e o recebimento por telefone foi adotado para alertas críticos. No entanto, a explosão de mais de 10 mil alertas de aviso por mês levou ao fenômeno de ignorar alertas e ao aumento da fadiga de On-call.
Insight principal: alertas excessivos fazem o mensageiro virar um simples health checker, prejudicando a visibilidade do sistema. Foi proposta a medição da 'taxa de reação aos alertas' usando emojis do Slack (👀, ✅) como indicador principal para reduzir alertas.
Processo de solução:
Ajuste e remoção de alertas cuja intenção da configuração inicial não combinava com o ambiente atual (ex.: incompatibilidade do limite de aumento de volume do EBS).
Remoção ousada de alertas sem sentido, cuja intenção dos responsáveis anteriores não podia ser identificada.
Resultados adicionais: após eliminar o ruído dos alertas, foi descoberto e normalizado que a causa do alto iowait em um servidor específico era um recordsize do ZFS configurado de forma excessiva em relação à carga de trabalho real.
Resultado: redução de 95,7% nos alertas de aviso (10.553 por mês → 453). Redução de mais de 70% no recebimento de chamadas críticas durante a madrugada e em feriados. Resolução da privação de sono no On-call e melhoria real na disponibilidade e visibilidade do sistema.
3 comentários
Logs, métricas e alertas exigem uma prática de ajustes periódicos.
Esse apelido me parecia familiar; agora entendi, é a pessoa que escreveu aquele texto divertido sobre a saída do cron no passado. Também li muito bem este artigo :D
Fico feliz que você tenha gostado da leitura, obrigado.