Fadiga de alertas: como cortar 78% em duas semanas

A fadiga de alertas é o sintoma silencioso de qualquer operação observada por humanos — e a Helix Health era um caso de manual. A empresa roda uma plataforma de operações clínicas em 240 unidades. O time de plantão tinha 47 fontes únicas de alerta, média de 1.400 alertas por semana e taxa de acknowledgment de 6%. Pessoas dormiam durante pages.

Em duas semanas, cortamos os alertas semanais para 312 e levamos o acknowledgment a 94%. Como.

Auditando a fadiga de alertas antes de mudar regra

Não escrevemos nenhuma regra nos três primeiros dias. Só coletamos. Cada alerta dos últimos 30 dias, etiquetado com: correspondeu a um incidente real? Causou ação? Foi reconhecido em até 5 minutos?

Os números foram brutais. 11% dos alertas correspondiam a incidentes reais. 4% causaram ação. O resto era ruído. O livro de SRE do Google chama isso de “alerta sem ação” e aponta que é o principal vetor de erosão de plantão — exatamente o que estávamos vendo.

Fase de consolidação (4 dias)

A maioria dos alertas eram variantes redundantes do mesmo sinal. Latência de banco disparando 9 alertas diferentes em 6 dashboards. Colapsamos em um workflow da Luminary que assinava as 9 fontes, deduplicava e emitia um único alerta page-vale quando o threshold batia.

Três operações dessas eliminaram 64% do volume. O paralelo com outros cases que vimos no setor reforça que consolidação supera ajuste fino na maioria das vezes.

Fase de threshold (1 semana)

Em seguida, passamos por cada alerta restante com o SRE lead. A pergunta para cada um: “Se fôssemos paged às 3 da manhã por isso e nenhuma ação humana fosse necessária, quanto teria valido o alerta?” Se a resposta era zero, ou subíamos o threshold ou movíamos para um digest diário.

Esse último passo é o que não se encaixava em nenhum framework — mas cortou outros 28% do volume. Tratar fadiga de alertas como um problema de design, e não de ferramenta, é o que faz a diferença.