Sistema di segnalazione e segnalazione

1) Ruolo e obiettivi

Il sistema di segnalazione non è l'invio di messaggi, ma il tracciato decisionale: evidenzia in tempo le deviazioni, suggerisce azioni e mantiene un equilibrio tra tempestività e silenzio.

• Riduce MTTD/MTTR con priorità e playbook chiari.
• Riduce alert fatige (stanchezza degli avvisi) tramite rumore.
• Dà azioni direttamente dalla notifica (ack, snoose, runbook, attività automatica).
• Mantenere la privacy e il consenso (opt-in/opt-out, archiviazione del cavo).

2) Tassonomia eventi e livelli

2. 1 Tipi di eventi

Metriche/anomalie (SRE, prodotto, finanza).
Regole aziendali (limiti, frode, KYC, pagamenti).
Sistema (deposito, degrado, licenze).
Personalizzato (trigger comportamentali, RG/gioco responsabile).

2. 2 Livelli di importanza (Severity)

Critical - reazione immediata, rischio di perdita/sicurezza.
High è un peggioramento significativo di KPI/SLO.
Medium - richiede azioni durante l'orario di lavoro.
Low/Info - osservazione/contesto, allineamento automatico in digest.

2. 3 Priorità (Priority)

La matrice «Impatto x Urgency» è P1. P4. Aggancia i canali e la risposta SLA.

3) Architettura e flussi

→ → → Normalizzazione (Enrich, Deadup) → Correlazione → Regole (policy engine) → Routing → Canali di consegna → Centro Preferenze di Logi/Analisi.

• Enricher aggiunge il tenante, il ruolo, la regione, i collegamenti alle playbook.
• Deduper: raggruppa gli eventi ripetuti in base alla chiave.
• Correlator: incollare i segnali familiari in un incidente.
• Policy Engine: regole YAML/DSL, quiet hours, escalation.
• Delivery: in-app, email, push, SMS, webhook, chat-integrazione.

4) Regole e regole (esempio 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) Deduplicazione, correlazione, soppressione del flapping

Deadup: ID gruppo «dedup _ key = hash (service» metric «dim)»; La TTL ha ≥ una finestra di flapping.
Correlazione: combinare i segnali correlati in base alla topologia (servis→zavisimost), al tempo (© N min) e al contesto (rilascio, incidente).
Flapping: le soglie «N eventi in M minuti» → un segnale «flapping detected» che suggerisce di sollevare isteresi o suppress.

6) Routing e RACI

Chi riceve la prima notifica/tusk.
Accountable: chi viene scalato dopo la SLA.
Consulted: chi menzionare nel tredice/chat.
Informed a chi serve un sommergibile/riepilogo.
Assegnare in base al ruolo e al contesto (tenante, regione, prodotto stram).

7) Canali di consegna e sfumature

Retrai: 5xx/429/timeout → backoff + jitter; «Retry-After» rispettare. Idampotenza: «X-Notification-ID» sui siti web.

8) Centro preferenze (Preferences Center)

Opt-in/Opt-out per tipo di evento, livello, canale.

Grafico di silenzio (quiet hours), snoose manuale a 15/30/60 minuti

Soglia/sensibilità (ad esempio, anomalia 3).
Lingua/locale, formato tempo/valuta.
I preset per SRE/Product/Finance sono associati ai ruoli.
Trasparenza - Mostra perché l'utente ha ricevuto un segnale (riferimento alla regola).

9) Progettazione dei contenuti: struttura del messaggio

• Titolo: brevemente, con il trigger: «[P1] [PSP _ TR] Aumento drammatico dei guasti 3DS (+ 12%)».
• Contesto: periodo, segmenti/regioni interessati, origine dati.
• Motivo/ipotesi: «Collegato al comunicato PSP _ X 18:20 UTC».
• SLA/deadline: «Escalation in 10 minuti».
• CTA: Apri playbook, Attiva fallback PSP _ Y, Ack (30 min).
• I collegamenti sono: grafico, incidente, metriche, runbook.
• Metadati: 'trace _ id', 'incident _ id', 'dedup _ key'.

I fatti, senza drammatizzare; Numeri e unità Evitare gli acronimi senza decrittazione.
Localizzazione: variabili playsholder, traduzioni memorizzate in risorse; numeri/date per locale.

10) Azioni da notifica (Actionable)

Ack/Snoose con opzioni temporali.
Assign/Invite nell'incidente.
Runbook - Apre i passaggi della soluzione completando automaticamente il contesto.
One-click remediation (dove è sicuro) - Consente di cambiare percorso, alzare il limite, riavviare il jobs (con conferma e revisione).
Crea un ticket (Jira/GitHub) con il completamento automatico dei campi.

11) Qualità dei segnali: metriche e obiettivi

Precision (percentuale di persone rilevanti tra quelle inviate) è pari all '80% per P1/P2.
Recall (percentuale rilevata tra tutti gli incidenti) è pari al 70%.
Noise: segnale medio/ora per utente (soffitto di destinazione).
Ack-time p50/p95, Escalation rate, Snoose rate (come indicatore di rumore).
MTTD/MTTA/MTTR (nel taglio di domini e canali).
Silenced-point-should-alert (omissioni a causa delle regole) è un dashboard separato.

12) Gestione del rumore: tecniche

Isteresi e finestre scorrevoli per le soglie.
Antialiasing (EWMA) prima della rilevazione.
Aggregazione: al posto di 30 piccoli - un batch/digest con top-contractor.
I limiti contestuali non sono più di N notifiche/ora/canale/utente.
Feedback automatico: se un utente fa clic su Snoose 3 x di fila, suggerisce di alzare la soglia/modificare il canale.

13) Sicurezza, privacy, compliance

Firma HMAC per webhook, rotazione dei segreti, X-Key-ID.
RBAC/ABAC: visibilità dei segnali per ruolo/tenanti.
Minimizzazione PII, maschere nei logi, controllo delle azioni (ack/assign/runbook).
Il consenso (consent) e le ragioni della notifica (regola/regola) sono in payload.
Retention/TTL dei reparti di notifica, Legale Hold degli incidenti.

14) Schemi e payload's

Evento (interno)

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 }
}

Notifica (canale agnostico)

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) pattern UX nel prodotto

Inbox: schede Critical/High/Other, badge di quantità.
Il nastro dell'incidente, i segnali correlati, la timeline dell'azione, «cosa è stato fatto».
Filtri: ruolo, dominio, regione, tempo, solo senza risposta.
Azioni rapide nell'elenco (ack/snoose/assign).
Explorer: «perché lo vedi» (regola, soglie, dati).
Digest: mattutino/sera, localizzato in TZ.

16) Test-piano

Unità: chiavi di deadup, isteresi, flapping, serializzazione payload.
Integration: routing, quiet hours, escalation, retrai di canale.
E2E: script P1 dall'anomalia alla chiusura del ticket; P2 in quiet hours è un digest.
Chaos: perdita del canale (SMTP/SMS), ritardi, valanga di segnali, clock-skew.
A11y/i18n: screen-readers, tastiere ack/snoose, localizzazione di numeri/date.

17) Dashboard di qualità

Precision/Recall per dominio.
Ack time p50/p95 e la percentuale confermata in tempo.
Noise per user/hour e regole top-rumorose.
Escalation rate e «false escalation».
Supplessed vs Delivered (soppresso/raggruppato in digest).
User feedback :/messaggi, commenti al rumore.

18) Assegno fogli

Progettazione

• Tassonomia eventi e livelli coerenti
• I criteri quiet hours/escalation sono descritti
• Deduplicazione/correlazione/flapping configurati
• Canali, retrai, idemoticità dei webhoop
• Centro preferenze (opt-in/out, snoose)
• Modelli di contenuto e localizzazione
• Playbook e azione one-click (con revisione)
• Metriche di qualità e dashboard

Utilizzo

• Ottimizzazione soglia ogni trimestre
• A/B regole (soglia, finestre, digest)
• Recensioni regolari «top rumore» e «CAPA»
• Rotazione dei segreti dei canali (HMAC, SMTP, SMS)
• Test di allarme (game days) pianificato

19) Piano di implementazione (3 iterazioni)

Iterazione 1 - Tracciato base (2-3 settimane)

Tassonomia, severity/priority, centro preferenze (in-app + email).
Deadup, semplice correlazione chiave/tempo, quiet hours.
Modelli di messaggio, playbook, ack/snoose/assign.

Iterazione 2 - Affidabilità e rumore (3-4 settimane)

Flapping/isteresi, digest, chat-integrazioni e webhook (HMAC, retrai).
Scalate SLA, dashboard di qualità (precision/recall, noise).
One-click remediation (con conferma e revisione).

Iterazione 3 - Ottimizzazione e scala (continua)

Correlazione per topologia/rilascio, offerte auto di soglia.
A/B delle regole, la previsione «quando funzionerà la soglia».
Recensioni del rumore e game days regolari.

20) Mini FAQ

Come si combatte con alert fatige?
Deadup, correlazione, isteresi, digest e centri di preferenza + regolari recensioni del rumore e soglie A/B.

C'è bisogno di un ML per le anomalie?
È utile, ma cominciate con regole definite e soglie spiegabili. ML è come un plug-in, obbligatorio con Explorer.

Perché gli utenti ricevono email «superflue»?
Controlla le partite di regole, quiet hours, controllo «perché consegnato», regolare i limiti per canale/ora e digest.

Totale

Un sistema di segnale forte è un filtraggio intelligente e una priorità corretta + azione in un clic. Formalizzare tassonomia e regole, implementare deadup/correlazione/isteresi, dare agli utenti il controllo (preferences, snoose), garantire una consegna affidabile e la trasparenza «perché l'ho ottenuto». I segnali diventeranno uno strumento di controllo, non una fonte di rumore.