Evitare la rielezione degli alert

1) Problema e obiettivo

Alert fatige si verifica quando il sistema invia troppe notifiche non rilevanti o non actionabili. Il risultato è l'ignoranza di pagelle, la crescita di MTTA/MTTR e l'omissione di veri incidenti.
Obiettivo: rendere i segnali rari, significativi e eseguibili, collegandoli a SLO e playbook.

2) Tassonomia dei segnali (canale = conseguenze)

Pagina (P0/P1) - sveglia una persona; solo quando è necessaria un'azione manuale ora e c'è un runbook.
Ticket (P2) - lavoro asincrona nelle ore/giorno; Non sveglia, ma trema per la SLA.
Dash-only (P3) - Osservazione/trend senza attività non fa rumore.
Silent Sentry - metriche/controllo in background (RCA/post mortem).

3) Progettazione dell'alert «corretto»

• Obiettivo/ipotesi (che proteggiamo SLO, sicurezza, denaro, compilazione).
• Condizioni di attivazione (soglia, finestra, quorum delle sorgenti).
• Runbook/Playbook (breve ID passo + riferimento).
• Proprietario (comando/gruppo di ruolo).
• Criteri di completamento (quando chiudere, taglio automatico).
• Classe di vulnerabilità (user-impact/platform/security/cost).

4) Monitoraggio orientato SLO

SLI/SLO: disponibilità, latitanza, successo delle operazioni aziendali.

• Il budget è breve: 5 1 in un'ora di → Page.
• Il budget è lungo il 2% in 6 ore.
• Coerenza: alert per regione/provider/segmenti VIP - meno false preoccupazioni globali.

5) Tecniche di riduzione del rumore

1. Quorum delle sonde: l'attivazione solo se le sorgenti indipendenti (regioni diverse/provider) confermano il problema.
2. Deduplicazione: raggruppamento di eventi identici (aggregation keys: service + region + code).
3. Isteresi/durata: "Nella zona rossa" N minuti "per filtrare le spine.
4. Rate-limit: non più di X avvisi/ora/servizio; se superata, una paia + riepilogo.
5. Auto-snoose/soppressione intelligente: l'alert ripetuto nella finestra T viene tradotto in Ticket prima di eliminare la radice.
6. Correlazione eventi: uno «master alert» invece di decine di sintomi (ad esempio, «database non disponibile» silenzia 5xx da microservizi).
7. Macintenance finestre - Le operazioni pianificate sopprimono automaticamente i segnali previsti.
8. Anataly + guardrails: anomalie solo come Ticket, a meno che il segnale SLO non sia confermato.

6) Routing e priorità

Le priorità sono P0 (Page, 15 min update), P1 (Page, 30 min), P2 (Ticket, 4-8 h), P3 (sorveglianza).
Routing per servizio/eng/region/tenant per corrispondenza on-call.
Accelerazione temporale: nessun ack da 5 minuti P2 da Duty Manager/IC.
Quiet Hours: orologi notturni per non ritrici; Pagina non consentita per P2/P3.
Politica Fatige: se un ingegnere> N paglia/cambio - ridistribuire su P2, scalare l'inquinamento dei segnali.

7) Qualità degli alert: accordi

Actionability 80% - La stragrande maggioranza dei cercapersone porta all'azione runbook.
False Positive 5% per i segnali di pagina.
Time-to-Fix-Alert per 7 giorni - L'alert difettoso deve essere corretto/rimosso.
Ownership 100% - Ogni alert ha un proprietario e un repository con la sua definizione.

8) Ciclo di vita alert (Alert as Code)

1. Crea PR (descrizione dell'obiettivo, condizioni, runbook, proprietario, piano di prova).
2. Sabbia/Shadow: l'ombra-alert scrive nella chat/loga, ma non il cercapersone.
3. Pubblico limitato on-call, misuriamo FP/TP.
4. Prod: attivazione con rate-limit + osservazione 2-4 settimane.
5. Review settimanale: metriche di qualità, modifiche/rimozione.
6. Deprekate: se il segnale è duplicato da un segnale più alto o non actionable.

9) Metriche di maturità (mostrate sul dashbord)

Alerts per on-call hour (mediana/95-percentile).
% actionable (ci sono passaggi completati) e false-positive rate.
MTTA/MTTR intorno al cercapersone e quota di page→ticket (non deve essere alto).
Top talkers (servizi/regole che generano il ≥20% del rumore).
Mean time to fix alert (dalla prima FP alla modifica della regola).
Burn-rate coverage: quota di servizi con alert SLO in due finestre.

10) Assegno-foglia «Igiene degli alerti»

• Alert è collegato a SLO/SLI o business/sicurezza.
• Ci sono runbook e proprietario; il contatto e il canale war-room specificati.
• Sono configurate due finestre (breve/lunga) e un quorum di sorgenti.
• Incluse deadup, rate-limit, auto-resolve e auto-snoose.
• Sono state specificate le finestre maintenance e supplence per i rilasci/migrazioni.
• Shadow/Canary superato; misurati da FP/TP.
• È stato attivato un report sulle metriche di qualità degli alert.

11) Mini modelli

Specifica alert (idea 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" ]

Testo di update standard (per ridurre il rumore)

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

12) Processi: Alert Review settimanale

1. Le regole top-rumorose (top-talkers) sono regolabili/eliminate.

2. FP/TP per i segnali di pagina regoliamo le soglie/finestre/quorum.

3. Candidati al ribasso del canale (Page→Ticket) e viceversa.

4. Stato Time-to-Fix-Alert - I ritardi vengono scalati dai proprietari dei servizi.

5. Controlla il coverage SLO-alert e la presenza di runbook.

13) Comunicazioni con i comunicati e le operazioni

Le annotazioni di release aggiungono automaticamente le soppressioni temporanee.
Cambio windows: nei primi 30 minuti successivi al lancio, solo i segnali SLO.
Le playbook contengono una fase dì abbassare o sopprimere gli alert "per concentrarsi sulla radice.

14) Sicurezza e compliance

I segnali di sicurezza (attacco/fuga/disponibilità anomale) sono canali separati, senza quiet hours.
Controllo di tutte le soppressioni/finestre silenziose: chi, quando, perché, la scadenza.
Requisito di immutabilità per gli alarmi critici (firma evento).

15) Anti-pattern

«Ogni grafico = alert» è una valanga.
Soglia «! = 0 errori» in vendita.
Una sonda/una regione come fonte di verità.
Pagina senza runbook/proprietario.
«Soppressioni temporanee» senza scadenza.
«Sistemiamo gli alert difettosi per anni».
Miscelare il rumore del lancio con gli incidenti alimentari.

16) Road map di implementazione (4-6 settimane)

1. L'inventario, scaricare tutti gli alert, mettere i proprietari e i canali.
2. SLO kernel - Immettere regole burn-rate con doppie finestre sui servizi critici.
3. Controllo acustico: attivare quorum, deadup e rate-limit, avviare una week review.
4. Copertura Runbook - Chiudi i segnali 100% Pagine con i playbook.
5. Criteri Fatig: limiti di pagella/cambio, Quiet Hours, ridistribuzione del carico.
6. Automazione: Alert-as-Code, Shadow/Canary, report sulle metriche di qualità.

17) Totale

Il silenzio non è una mancanza di monitoraggio, ma segnali qualitativamente progettati associati a SLO e processi. Quorum, doppie finestre, deadup e routing rigoroso trasformano gli alert in rari, precisi e eseguibili. La squadra dorme, gli utenti sono soddisfatti, gli incidenti sono sotto controllo.