Sistem de alarmă și notificare

1) Rol și obiective

Sistemul de semnal nu este „trimiterea de mesaje”, ci un circuit decizional: evidențiază abaterile în timp, oferă acțiuni și menține un echilibru între promptitudine și tăcere.

• Reduceți MTTD/MTTR prin prioritizare și registre de redare clare.
• Reduceți oboseala de alertă prin anularea zgomotului.
• Dă acțiuni direct din notificare (ack, snooze, runbook, auto-acțiune).
• Respectați confidențialitatea și consimțământul (opt-in/opt-out, log storage).

2) Taxonomia evenimentelor și nivelurilor

2. 1 Tipuri de evenimente

Valori/anomalii (SRE, produs, finanțe).
Reguli de afaceri (limite, fraudă, KYC, plăți).
Sistem (implementare, degradare, licențe).
Utilizator (declanșatoare comportamentale, RG/joc responsabil).

2. 2 Niveluri de severitate

Răspuns critic - imediat, risc de pierdere/siguranță.
Deteriorarea semnificativă a KPI/SLO.
Mediu - Acțiune necesară în timpul programului de lucru.
Low/Info - observare/context, auto-convoluție în digestii.

2. 3 Prioritate

"Impact × Urgency 'matrix → P1..P4. Link către canale și reacții SLA.

3) Arhitectură și fire

Producătorii de semnale Sheena de evenimente Normalizare (îmbogățire, dedup) Corelație Corectat (motor de politică) Rutare Canala livrări Centrul de preferințe Jurnale/Analytics.

• Enricher: adaugă link-uri chiriaș, rol, regiune, playbook.
• Deduper-Group recurente evenimente de cheie.
• Corelator: Semnale legate de lipici într-un incident.
• Motor de politică: reguli YAML/DSL, ore liniștite, escaladări.
• Livrare: în aplicație, e-mail, push, SMS, webhook, integrare chat.

4) Reguli și politici (exemplu YAML)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) Deduplicarea, corelarea, suprimarea flappingului

Dedup: group ID 'dedup _ key = hash (serviciu' metric 'dim)'; TTL ≥ Flapping fereastră.
Corelație: combină semnalele conexe prin topologie (servis→zavisimost), timp (± N min) și context (eliberare, incident).
Flapping: praguri „N evenimente pe M minute” → un semnal „clapare detectat” cu o propunere de a ridica histerezis sau suprima.

6) Rutare și RACI

Responsabil: cine primește prima notificare/tragere.
Responsabil: cine escaladează după SLA.
Consultat: cine să menționeze în canalul de fir/chat.
Informat: cine va părăsi digestia/rezultatele.
Atribuiți după rol și context (chiriaș, regiune, flux de produse).

7) canale de livrare și nuanțe

Retrai: 5xx/429/timeout → backoff + jitter; Respect pentru „Retry-After”. Idempotence: 'X-Notification-Id' pe webhooks.

8) Centrul de preferințe

Opt-in/Opt-out după tipul de eveniment, nivel, canal.
Ore liniștite, amânare manuală pentru 15/30/60 min.
Prag/sensibilitate (de exemplu ≥ 3 σ anomalie).
Limba/locale, timp/format valutar.
Obligativitatea rolului: presetări pentru SRE/Produs/Finanțe.
Transparență: arată de ce utilizatorul a primit semnalul (link către regulă).

9) Design de conținut: structura mesajului

• Titlu: Scurt, cu declanșator: „[P1] [PSP _ TR] Creștere bruscă a eșecurilor 3DS (+ 12%)”.
• Context: perioadă, segmente/regiune afectate, sursă de date.
• Motivul/ipoteza: „Asociat cu eliberarea PSP_X 18:20 UTC”.
• SLA/termen limită: „Escaladarea în 10 min”.
• CTA: „Open playbook”, „Enable allback” PSP_Y, „Ack (30 min)”.
• Link-uri: grafic, incident-thread, metrics, runbook.
• Metadate: 'trace _ id',' incident _ id', 'dedup _ key'.

Ton: fapte, fără dramatizare; Numerele și unitățile evită abrevierile fără decodare.
Localizare: variabile → înlocuitori, traducerile sunt stocate în resurse; numere/date - după locale.

10) Acțiuni din notificări (Actionable)

Ack/Snooze cu parametrii de timp.
Atribuiți/invitați la firul incident.
Runbook-Open soluție pași cu context autocomplete.
Un singur clic de remediere (în cazul în care în condiții de siguranță): comutați ruta, ridica limita, reporni locul de muncă (cu confirmare și audit).
Creați bilet (Jira/GitHub) cu câmpuri autocomplete.

11) Calitatea semnalului: valori și obiective

Precizie ≥ 80% pentru P1/P2.
Rechemare (proporția incidentelor detectate în rândul tuturor incidentelor) ≥ de 70%.
Zgomot: semnale medii/oră pe utilizator (plafonul țintă).
Ack-time p50/p95, Rata de escaladare, Rata de snooze (ca indicator de zgomot).
MTTD/MTTA/MTTR (în termeni de domenii și canale).
Tăcut-dar-ar trebui-alertă (lacune din cauza regulilor) este un tablou de bord separat.

12) Controlul zgomotului: tehnici

Histerezis și ferestre glisante pentru praguri.
Anti-aliasing (EWMA) înainte de detectare.
Agregare: în loc de 30 de mici - un lot/digera cu contribuabili de top.
Limite de context: maxim N notificări/oră/canal/utilizator.
Feedback automat: dacă utilizatorul face clic pe Snooze timp de 3 × la rând → sugerează ridicarea pragului/schimbarea canalului.

13) Securitate, confidențialitate, conformitate

Semnătură HMAC pentru webhooks, rotație de secrete, "X-Key-Id'.
RBAC/ABAC: vizibilitate semnal de rol/chiriaș.
Minimizarea PII, măști în jurnale, acțiuni de audit (ack/assign/runbook).
Consimțământul și motivele notificării (regula/politica) - în sarcină utilă.
Jurnalele de notificare retenție/TTL, Legal Hold privind incidentele.

14) Scheme și sarcini utile

Eveniment (intern)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

Notificare (canal agnostic)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) Modele UX în produs

Inboxuri: Critic/High/Alte file, insigne cantitative.
Incident de alimentare: semnale corelate, cronologie de acțiuni, „ceea ce a fost făcut”.
Filtre: rol, domeniu, regiune, timp, „numai fără răspuns”.
Acțiuni rapide în listă (ack/snooze/assign).
Explicați: „de ce o vedeți” (regulă, praguri, date).
Digestii: dimineata/seara, localizati de TZ.

16) Planul de încercare

Unitate: chei dedup, histerezis, flapping, serializarea sarcinilor utile.
Integrare: rutare, ore liniștite, escaladări, retroactive de canale.
E2E: scenariul P1 de la anomalie la închiderea biletelor; P2 în ore liniștite → digestie.
Haos: pierderea link-ului (SMTP/SMS), întârzieri, avalanșă de semnal, ceas-înclinare.
A11y/i18n: cititoare de ecran, tastatură ack/snooze, localizarea numerelor/datelor.

17) Tablouri de bord de calitate

Precizie/Rechemare după domeniu.
Ack timp p50/p95 și cota de confirmat în timp util.
Zgomot pe utilizator/oră și reguli de zgomot de top.
Rata de escaladare și „escaladări false”.
Suprimate vs livrate (cât de mult este suprimat/digerat).
Feedback utilizator :/mesaje, comentarii cu privire la zgomot.

18) Liste de verificare

Design

• Taxonomia evenimentelor și nivelurile sunt consecvente
• Sunt descrise ore liniștite/politici de escaladare
• Dedup/Corelare/Flapping configurat
• Canale, Retras, Idempotency Webhook
• Preference Center (opt-in/out, snooze)
• Șabloane de conținut și localizare
• Cărți de redare și acțiuni cu un singur clic (auditat)
• Măsurători de calitate și tablouri de bord

Funcționare

• Optimizarea pragului trimestrial

Reguli A/B (prag, ferestre, digestie)

• Regulat „zgomot de top” și comentarii CAPA
• Rotația secretă a canalului (HMAC, SMTP, SMS)
• Testul zilelor de joc programate

19) Planul de implementare (3 iterații)

Iteraţie 1 - Valoarea iniţială (2-3 săptămâni)

Taxonomie, severitate/prioritate, centru de preferințe (în aplicație + e-mail).
Dedup, corelație simplă cheie/timp, ore liniștite.
Șabloane de mesaje, cărți de redare, ack/snooze/assigned.

Iterație 2 - Fiabilitate și reducerea zgomotului (3-4 săptămâni)

Flapping/hysteresis, digests, chat integrations, and webhooks (HMACs, retrays).
Escaladarea conform SLA, tablouri de bord de calitate (precizie/rechemare, zgomot).
Remediere cu un singur clic (cu confirmare și audit).

Iterația 3 - Optimizare și scară (continuă)

Corelarea prin topologie/versiuni, auto-sugestii de praguri.
Normele A/B, previziunile „când pragul va funcționa”.
Recenzii de zgomot și zile regulate de joc.

20) Mini-Întrebări frecvente

Cum să faceți față oboselii de alertă?
Dedup, corelație, istereză, digestii și centre de preferințe + zgomot regulat și recenzii A/B.

Este ML necesar pentru anomalii?
Util, dar începe cu reguli deterministe și praguri explicabile. ML este ca un add-on, întotdeauna cu Explica.

De ce utilizatorii primesc e-mailuri „suplimentare”?
Verificați meciurile regulilor, orele liniștite, auditurile „de ce livrate”, limitele canalului/orei și digestiile.

Total

Un sistem puternic de semnal este filtrarea inteligentă și prioritizarea corectă + acțiuni cu un singur clic. Formalizați taxonomia și politicile, implementați dedup/corelație/histerezis, oferiți utilizatorilor controlul (preferințe, snooze), oferiți livrare fiabilă și transparență "de ce l-am obținut. "Atunci semnalele vor deveni un instrument de control, nu o sursă de zgomot.