Prevenirea unei supraabundențe de alerte

1) Problema și scopul

Oboseala de alertă apare atunci când sistemul trimite prea multe notificări irelevante sau care nu pot fi acționate. Concluzia este ignorarea paginilor, creșterea MTTA/MTTR și sărirea peste incidentele reale.
Scopul: de a face semnale rare, semnificative și executabile prin conectarea acestora la SLO-uri și playbook-uri.

2) taxonomia semnalului (canal = consecințe)

Pagina (P0/P1) - trezește o persoană; numai atunci când acțiunea manuală este necesară acum și există un runbook.
Bilet (P2) - lucru asincron în ore/zi; nu se trezește, dar este urmărit de SLA.
Dash-only (P3) - observație/tendință fără acțiuni active; nu creează zgomot.
Silent Sentry - metrici/audit în fundal (pentru RCA/post-mortems).

3) Proiectarea alertei „corecte”

• Obiectiv/ipoteză (ce protejăm: SLO, securitate, bani, conformitate).
• Condiții de declanșare (prag, fereastră, cvorum sursă).
• Runbook/Playbook (scurt ID pas + link).
• Proprietar (echipă/grup de rol).
• Criterii de finalizare (când să închideți, rezoluție automată).
• Clasa de vulnerabilitate (user-impact/platform/security/cost).

4) monitorizarea orientată spre SLO

SLI/SLO → semnale primare: disponibilitate, latență, succesul operațiunilor de afaceri.

• Scurt: 5% din buget într- 1 oră → Page.
• Lung: 2% din buget în 6 ore → Bilet.
• Cohortă: Alerte pe segmentul Region/Provider/VIP - mai puține alarme globale false.

5) Tehnici de reducere a zgomotului

1. Sondele cvorum: declanșate numai dacă ≥2 surse independente (regiuni/furnizori diferiți) confirmă problema.
2. Eliminarea duplicatelor - chei de agregare: service + regiune + cod.
3. Histerezis/durata: „în zona roșie ≥ N minute” pentru a filtra vârfurile.
4. Tarif limită: nu mai mult de X alerte/oră/serviciu; dacă este depășit, o pagină + rezumat.
5. Auto-snooze/suprimarea inteligentă: o alertă repetată în fereastra T → traducerea în Ticket până când rădăcina este eliminată.
6. Corelarea evenimentelor: o „alertă principală” în loc de zeci de simptome (de ex. „DB indisponibil” bruiaj 5xx de la microservices).
7. Ferestre de întreținere: lucrările programate suprimă automat semnalele așteptate.
8. Anomalia + guardrails: anomalii - numai ca Bilet, în cazul în care nu există nici o confirmare de către semnalul SLO.

6) Rutare și priorități

Prioritati: P0 (Pagina, actualizari 15 min), P1 (Pagina, 30 min), P2 (Bilet, 4-8 h), P3 (observatie).
Rutare dupa etichete: service/env/region/chirias → corespunzator la call.
Escaladarea timpului: fără ack în 5 min → P2 → Duty Manager/IC.
Ore liniștite: ore de noapte pentru non-critice; Pagina nu este permisă pentru P2/P3.
Politica de oboseală: dacă inginerul are> N pagini/schimbare - redistribuiți la P2, escaladați contaminarea semnalului.

7) Calitatea alertelor: aranjamente

Actionability ≥ 80%: marea majoritate a paginilor conduc la actiunea runbook.
Fals pozitiv ≤ 5% pentru semnalele Page.
Time-to-Fix-Alert ≤ 7 zile - alerta defectă trebuie corectată/eliminată.
Proprietate 100% - fiecare alertă are un proprietar și un depozit cu definiția sa.

8) Alertă ca ciclu de viață Cod

1. Creați PR (descrierea scopului, condițiile, runbook, proprietarul, planul de testare).
2. Sandbox/Shadow: shadow alert scrie la chat/jurnal, dar nu pagina.
3. Canare: audiență limitată la apel, măsură FP/TP.
4. Prod: includerea cu rată-limită + observație 2-4 săptămâni.
5. Recenzie săptămânală: valori de calitate, modificări/retrageri.
6. Depreciați: dacă semnalul duplicează unul mai mare sau nu poate fi acționat.

9) Valorile maturității (arată pe tabloul de bord)

Alerte pe oră de gardă (mediană/percentilă 95).
% acționabil (există pași finalizați) și rata fals-pozitivă.
MTTA/MTTR în jurul paginilor și a ratei de page→ticket (nu ar trebui să fie mare).
Top-talkers (servicii/reguli care generează ≥20% zgomot).
Timpul mediu pentru a repara alerta.
Acoperire burn-rate: ponderea serviciilor cu alerte SLO în două ferestre.

10) Lista de verificare „Igiena alertelor”

• Alerta este legată de SLO/SLI sau afaceri/securitate.
• Există un runbook și proprietar; sunt specificate canalul de contact și camera de război.
• Sunt configurate două ferestre (scurte/lungi) și un cvorum de surse.
• Dedup, rate-limit, auto-rezolva, și auto-snooze sunt incluse.
• Întreținerea și suprimarea ferestrelor sunt specificate pentru eliberări/migrații.
• Shadow/Canary a trecut; măsurată FP/TP.
• Alert raport de calitate incluse.

11) Mini șabloane

Specificații de alertă (idee 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" ]

Text de actualizare standard (pentru a reduce zgomotul)

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

12) Procese: Săptămânal „Alert Review”

1. Top-talkers → editați/ștergeți.

2. Semnale FP/TP pe pagină → reglați pragurile/ferestrele/cvorumul.

3. Solicitanții de downgrade (Page→Ticket) și invers.

4. Starea Time-to-Fix-Alert - întârzierile sunt escaladate la proprietarii de servicii.

5. Verificarea acoperirii cu alerte SLO și prezența runbooks.

13) Link către versiuni și operațiuni

Eliberați adnotările adăugați automat supresii temporare.
Schimbarea ferestrelor: în primele 30 de minute de la lansare - numai semnale SLO.
Cărțile de redare conțin un pas „inferior/suprima alerta non-cheie” pentru a se concentra pe rădăcină.

14) Siguranță și conformitate

Semnale de securitate (hacking/scurgeri/accesări anormale) - canale separate, fără ore liniștite.
Jurnalul de audit al tuturor supresiilor/ferestrelor liniștite: cine, când, de ce, termenul limită.
Cerință de imutabilitate pentru alerte critice (semnătura evenimentului).

15) Anti-modele

„Fiecare grafic = alertă” → avalanșă.
Pragul „! = 0 erori” în vânzări.
O sondă/o regiune ca sursă a adevărului.
Pagină fără runbook/proprietar.
Perpetuu „supresii temporare” fără termen.
„Fixați-l mai târziu” alerte defecte - se acumulează de ani de zile.
Amestecarea zgomotului de eliberare cu incidentele de producție.

16) Foaie de parcurs de implementare (4-6 săptămâni)

1. Inventar: descărcați toate alertele, puneți jos proprietarii și canalele.
2. Kernel SLO: introduce reguli de burn-rate cu ferestre duble pentru servicii critice.
3. Controlul zgomotului: activați cvorumul, deadup și limita ratei, începeți o revizuire săptămânală.
4. Acoperire Runbook: închideți 100% din semnalele Page cu cărți de redare.
5. Politica de fatig: limitele paginii/shift, ore de liniște, redistribuirea încărcării.
6. Automatizare: Alert-as-Code, Shadow/Canary, raportare privind valorile calității.

17) Linia de jos

Tăcerea nu este o lipsă de monitorizare, ci semnale bine concepute asociate cu SLO și procese. Cvorumul, ferestrele duble, dedupul și rutarea strictă transformă alertele în rare, exacte și executabile. Echipa doarme, utilizatorii sunt fericiţi, incidentele sunt sub control.