Evitar a reeleição de alertas

1) Problema e alvo

Alert fatiguue ocorre quando o sistema envia demasiadas notificações não recorrentes ou não actionable. O resultado é ignorar pagas, crescimento do MTTA/MTTR e omissão dos verdadeiros incidentes.
O objetivo é tornar os sinais raros, significativos e executáveis, ligando-os a SLO e playbooks.

2) Sinais de taxonomia (canal = consequências)

Page (P0/P1) - desperta a pessoa; apenas quando uma ação manual é necessária agora e há um runbook.
Bilhete (P2) - Trabalho asincrônico em horas/dia; Não desperta, mas treme pela SLA.
Dash-only (P3) - observação/tendência sem ação; Não faz barulho.
Silent Sentry - métricas/auditoria em background (para RCA/pós-mortem).

3) Projetar alert «correto»

• Objetivo/hipótese (que protegemos: SLO, segurança, dinheiro, complacência).
• Condições de execução (limiar, janela, quórum de fontes).
• Runbook/Playbook (breve ID de passo + referência).
• Dono (comando/grupo de papel).
• Critérios de conclusão (quando fechar, auto-ressalvas).
• Classe de vulnerabilidade (user-impact/platch/security/cost).

4) Monitoramento orientado SLO

O SLI/SLO → os sinais primários de disponibilidade, latência, sucesso das operações de negócios.

• Curto, 5% do orçamento em 1 hora → Page.
• Longo: 2% do orçamento em 6 horas → a Sac.
• Alertas por região/provedores/segmentos VIP - menos falsas preocupações globais.

5) Técnicas de redução de ruídos

1. Quórum das sondas: A activação só se as fontes independentes (diferentes regiões/provedores) confirmarem o problema.
2. Deduplicação: agrupamento de eventos idênticos (aggregation keys: service + region + código).
3. Histerese/duração: «Na zona vermelha ≥ N minutos» para filtrar espinhos.
4. Rate-limit: no máximo X alertas/hora/serviço; quando excedido, um paipe + resumo.
5. Auto-snoose/supressão inteligente: alert repetitivo na janela T → traduzir para o TCU antes que a raiz seja eliminada.
6. Correlação de eventos: um «mestre alert» em vez de dezenas de sintomas (por exemplo, «BD não disponível» silenciando 5xx dos microsserviços).
7. Janelas de maintenance: O trabalho programado suprime automaticamente os sinais esperados.
8. Anomaly + guardrails: anomalias - apenas como o Ticket, a menos que o sinal SLO seja confirmado.

6) Rotação e prioridades

As prioridades são P0 (Page, 15 min update), P1 (Page, 30 min), P2 (Card, 4-8 h), P3 (observação).
Routing por rótulos: service/eng/region/tenant → correspondente on-call.
Não há ack em 5 min → P2 → Duty Gerente/IC.
Quiet Hours: relógio noturno para não-ríticos; Página proibida para P2/P3.
Política de Fativue: Se um engenheiro> N page/turno - redistribuir para P2, escalar a poluição dos sinais.

7) Qualidade das alertas: acordos

Actionability ≥ 80%: A grande maioria dos pagees leva à ação de runbook.
Falso Positivo ≤ 5% para os sinais Page.
Time-to-Fix-Alert ≤ 7 dias - O alert de defeito deve ser corrigido/removido.
Ownership 100% - cada alert tem um dono e um repositório com sua definição.

8) Ciclo de vida alert (Alert as Code)

1. Criar PR (descrição do objetivo, condições, runbook, proprietário, plano de teste).
2. Caixa de areia/Shadow: A sombra alert escreve no bate-papo/loga, mas não no pagit.
3. Canário: público limitado on-call, medindo FP/TP.
4. Prod: ativação com rate-limit + observação de 2-4 semanas.
5. Review semanal: métricas de qualidade, edição/remoção.
6. Deprekate: Se o sinal duplicar um sinal mais alto ou não actionable.

9) Métricas de maturidade (mostre em dashbord)

Alerts per on-call hour (mediana/95-percentil).
% actionable (há passos concluídos) e falso-positivo rate.
MTTA/MTTR em torno do pagê e proporção de page→ticket (não deve ser alto).
Top talkers (serviços/regras que geram ≥20% de ruído).
Mean time to fix alert (desde o primeiro FP até a alteração da regra).
Burn-rate coverage: proporção de serviços com alertas SLO em duas janelas.

10) Folha de cheque «Higiene de alertas»

• Alert está ligado ao SLO/SLI ou ao negócio/segurança.
• Há runbook e dono; o contato e o canal war-room foram especificados.
• Duas janelas (curta/longa) e quórum de fontes foram configuradas.
• Incluído deadup, rate-limit, auto-resolve e auto-snoose.
• As janelas maintenance e a supressão foram especificadas nos lançamentos/migrações.
• Shadow/Canary ultrapassado; medidos pelo FP/TP.
• O relatório de métricas de qualidade de alertas foi ativado.

11) Mini-modelos

Especificação de alert (ideia YAML)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Texto de update padrão (para reduzir ruídos)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Processos: semanal «Alert Review»

1. As regras mais barulhentas (top-talkers) são → diálogos/removíveis.

2. FP/TP por sinalização Page → ajustamos liminares/janelas/quórum.

3. Candidatos a rebaixamento de canal (Page→Ticket) e vice-versa.

4. Status «Time-to-Fix-Alert» - Os atrasos são escalados para os proprietários de serviços.

5. Verificar o coverage SLO com alertas e a presença de runbook 'ov.

13) Comunicação com lançamentos e operações

As anotações de lançamento adicionam automaticamente supressões temporárias.
Mudança windows: Nos primeiros 30 minutos após o lançamento, apenas sinais SLO.
Os playbooks contêm o passo «rebaixar/suprimir alertas não-letais» para se concentrar na raiz.

14) Segurança e complacência

Os sinais de segurança (invasão/fuga/acessos anormais) são canais individuais, sem quiet hours.
Auditoria de todas as supressões/janelas silenciosas: quem, quando, porquê, prazo.
Exigência de imutabilidade para alarmes críticos (assinatura de evento).

15) Anti-pattern

«Cada gráfico = alert» → avalanche.
Limiar «! = 0 erros» na venda.
Uma sonda/uma região como fonte da verdade.
Página sem runbook/proprietário.
Supressões temporárias eternas sem prazo.
Vamos arranjar alertas defeituosas há anos.
Misturar ruído de lançamento com incidentes alimentares.

16) Mapa de trânsito de implementação (4-6 semanas)

1. Inventário, descarregar todas as alertas, colocar os proprietários e os canais.
2. Núcleo SLO: introduza regras burn-rate com janelas duplas para serviços críticos.
3. Controle de ruído: ligar quórum, dedup e rate-limit, iniciar uma review de semana.
4. Revestimento Runbook - fechar 100% dos sinais de página com playbooks.
5. Política Fatig: limites de pagê/turno, Quiet Hours, redistribuição de carga.
6. Automação: Alert-as-Code, Shadow/Canady, relatórios de qualidade.

17) Resultado

O silêncio não é uma falta de monitoramento, mas sim sinais projetados com qualidade associados a SLO e processos. Quórum, janelas duplas, deadup e rotação rigorosa transformam as alertas em raras, precisas e executáveis. A equipa está a dormir, os utilizadores estão satisfeitos, os incidentes estão sob controlo.