Reduzindo a Fadiga de Alertas no On-Call

Primeiro eu mediria antes de mexer em qualquer coisa. Eu puxaria os pages agrupados por nome do alerta, por serviço e por horário do dia, e os dividiria entre acionáveis versus auto-resolvidos. Quase sempre um punhado de alertas gera a maior parte do volume, e uma boa parte se auto-resolve antes que alguém faça qualquer coisa. Isso me diz onde focar. Depois eu trabalho na ordem de impacto: 1. Excluir ou rebaixar alertas não acionáveis. O teste é simples: se um page não exige que um humano faça algo agora, não é um page. Transforme em ticket ou painel de dashboard. Só isso já costuma cortar o pior do ruído. 2. Alertar em cima de sintomas, não de causas. Faça o page disparar com base no que os usuários sentem: taxa de erro elevada, latência acima do SLO, uma fila que está se acumulando. Não faça page em CPU a 90% ou pressão de memória, porque geralmente está tudo bem e isso dispara o tempo todo. Se CPU alta não está prejudicando os usuários, não é um incidente. 3. Adicionar guardas de duração. Uma cláusula `for:` interrompe alertas instáveis que disparam e se resolvem a cada dois minutos. Se não consegue ficar quebrado por cinco minutos, provavelmente não vale um page. 4. Agrupar e inibir. Quando uma interrupção dispara vinte alertas, o agrupamento do Alertmanager os condensa em uma única notificação, e regras de inibição suprimem o ruído downstream. Se o cluster está fora do ar, não precisa também fazer page para cada pod nele. 5. Migrar para alertas de burn-rate multi-janela para SLOs. Um limite estático ou dispara cedo demais ou tarde demais. Um par de burn rápido mais burn lento captura um consumo real de budget rapidamente, ficando quieto em picos passageiros. 6. Rotear por severidade. Só urgência genuína faz page. O resto vai para o Slack ou uma fila de tickets que é triada durante o dia. 7. Definir um orçamento e defendê-lo. Escolha uma meta, como menos de dois pages por turno fora do horário comercial, e trate ultrapassá-la como um bug com dono, revisado em cada troca de plantão. Sem uma meta, o ruído volta a se acumular. Os casos extremos que costumam pegar as pessoas: não simplesmente aumente os limites, porque isso esconde problemas reais em vez de remover ruído. Fique de olho nos alertas que se auto-resolvem, já que algo que oscila e se resolve a noite toda é um bug real disfarçado de inofensivo. E todo page que sobrar precisa ter um runbook. Se um page não tem runbook, ou ele não vale a pena, ou você deve um a ele.