Sistema di notifiche e alert

(Sezione Operazioni e Gestione)

1) Assegnazione e principi

L'obiettivo è quello di consegnare poco, ma meticolosamente, solo segnali rilevanti, a un uomo/robot responsabile e tempestivo con un chiaro next-step.

• Actionable by default - Ogni alert ha il proprietario, la priorità, la durata della reazione e il pulsante di azione.
• SLO-first: gli alert sono costruiti intorno a SLI/SLO, non intorno a metriche arbitrarie.
• Noise-control: deadup, correlazioni, soppressione della tempesta.
• Text-rich: metadati (regione, tenante, versione, trace _ id) e riferimento al runbook.
• Audit-ready - Tutti gli alert e le reazioni vengono ricevuti e salvati in un registro invariato.

2) Sorgenti di segnale

Di quelli. telemetria: disponibilità, p95/p99, errore-rate, code, limiti di risorse.
, , RTP Drift, segnali di .
Sicurezza/compilazione: violazioni soD, accesso PII, esportazione chiavi/certificati.
Pianificatore: operazioni SLA scadute, valanga DLQ, retry-storms.

3) Classificazione e priorità

Guardrails: gli alert vengono formulati in relazione al bilancio di errore SLO (burn rate).

4) Routing e escalation 24 x 7

Routing per contesto: 'region/tenant/product/provider/severity'.
Scala di escalation: on-call ingegnere di comando Duty Manager di Exec/Legale (per PI/finanza).
Turni per ruoli (SRE, App, Data, Security, Payments), contatti di riserva (chat/voce/SMS).
Finestre di silenzio notturne, comunicate, marketing; eccezioni per P1.

5) Rumore e correlazioni

Deduplicazione a «(fingerprint, region, tenant, route)» e «trace _ id».
Soppressione temporale: soppressione temporanea dei duplicati con P1 attivo.
Correlazioni: raggruppamento dei segnali intorno alla causa radice (rilascio/fich/provider).
Isteresi: ingresso/uscita dalla soglia sono diversi per evitare la sega.

6) Contenuto alert (modello)

Titolo: breve e oggetto: «EU/Checkout: p95> 250ms (SLO breach)».
I campi chiave sono priorità, ora, regione, tenante, versione, trace _ id, affected%, . il motivo.
Cosa fare ora: primi 1-3 passi + riferimento a runbook/pulsanti (Re-route, Rollback, Pausa Promo).
La seguente comunicazione è in N minuti, proprietario (IC/on-call).

7) Canali di consegna

Chat/messaggistica è il canale principale del triage (bot card con pulsanti).
Cercapersone/voce/SMS: per P1.
E-mail: report e non-urgent (P3/Info).
Integrazioni con ticketing/orchestratori.
Stato pagina: notifica esterna a client e partner.

8) Integrazioni e pulsanti di azione

Incidente-bot: crea la carta, assegna l'IC, apre il video, inizia il timer.
Руны (auto-actions): Re-route, Rollback, Raise Limit, Flush Cache, Disable Webhooks, Enable Safe Mode.
Diritti: l'avvio del run è limitato ai ruoli; tutte le azioni vengono sottoscritte e logificate.

9) Multiregion e multi-tenant

SLO/soglie indipendenti per regione; gli incidenti locali non hanno «colorato» il mondo.
Filtri visivi: i partner/tenanti vedono solo il loro.
I requisiti giurisdizionali sono testi di notifica, lingue, fuso orario.

10) Politiche, orari, finestre di silenzio

Politica degli alert: proprietari, soglie, canali, escalation, modelli.
Calendari: ore lavorative/non lavorative, finestre di lancio/marketing.
Cambio freeze - Alleggerimento delle soglie o soppressione dei non-P1 durante le grandi azioni.

11) Controllo e fissazione legale

Ricevute: per gli alert critici, «receipt _ hash» e la firma DSSE.
Registri WORM - Memorizzazione immutabile di eventi e reazioni (che ha confermato ciò che ha fatto).
Chain-of-custody - Traccia le scalate e le soluzioni.

12) Metriche e sistemi di notifica SLO

MTTA (acknowledge): P1 5-10 min; P2 ≤ 30 minuti

Pagina rate/On-call load - I segnali di cambio sono nell'intervallo di destinazione.
False Positive%: ≤ la soglia di destinazione (solitamente <10-15%).
Correlation efficiency è l' 80% dei segnali raggruppati.
Delivery SLO Chat 99. 9%, SMS/voto ≥ 99. 5%.
Time-to-Action: p95 per avviare la runa da alert.

13) Dashboard e reporti

Operativo: incidenti attivi, burn-rate, mappa delle regioni/tenenti, fila di alert.
Qualità degli alert: rumore, FP, retesti di soglia, zone mute.
Carica on-call: frequenza del cercapersone, tempo di reazione, «out of hours».
Post - incidente, efficacia delle rune, ripetibilità delle cause.

14) Specificità iGaming/Fintech

Payments/PSP: P1 - errore del provider, aumento dei guasti delle autorizzazioni; auto-root su PSP di riserva.
RTP & Limits: alert alla deriva della RTP osservata, superamento dei limiti, pattern delle vincite sospette.
Affiliati/webhoop: back, aumento delle riprese, calo delle ricevute confermate.
Price/FX/Tax - Disallineamento del vitrina↔checkout, rassincrone delle versioni degli artefatti.
Gioco responsabile: i trigger RG e la loro tempestiva escalation in supporto/Compliance.

15) RACI

16) Assegno-foglio di implementazione

• Definire North-Star e SLI/SLO; collegare gli alert al burn-rate.
• Immettere una directory di regole: soglie, canali, scalate, finestre di silenzio.
• Implementare deadup, correlazioni, isteresi, soppressione della tempesta.
• Personalizzare regole di visibilità multi-regionali e multi-tenant.
• Collegare pulsanti di azione e runbuki limitare i permessi di avvio.
• Abilita le ricevute WORM, Trace _ id e Check-Up.
• Costruisci dashboard di qualità (noise, FP, MTTA, page rate).
• Провести GameDay: PSP outage, WebhookLag, PriceMismatch, RTP Drift.
• Rivedere regolarmente le soglie; A/B soglie su metriche mute.
• Report su carichi e miglioramenti on-call mensili.

17) Playbook (arbitro)

PSP Outage (P1) - Auto-root di riserva, riduzione dei timeout dei client, quarantena delle transazioni grigie, stato-update dopo 15 minuti

WebhookLag (P2) - Aumenta i worker/batch, la priorità delle code, la pausa temporale degli endpoint opzionali.
PriceMismatch (P1/P2) - Forza-invalidità cache, riconciliazione, compensazione.
RTP Draft (P2) - Pausa bonus/promo, controllo dei profili, estensione della finestra di sorveglianza.
Sicurezza: SoD/MFA fail (P1/P2) - Blocca l'operazione, ricontrolla JIT, forense e Legale se necessario.

18) FAQ

Come ridurre i falsi effetti?
Regole orientate SLO, correlazioni, isteresi, finestre di apprendimento e revisione regolare delle soglie.

Cosa c'è di più importante, la copertura o la precisione?
Per la P1, precisione e velocità (più piccole, ma critiche). Per P3 - copertura trend e costi.

Hai bisogno di un cercapersone telefonico?
Sì, per P1; la chat potrebbe non essere disponibile o non essere disponibile.

Come si fa a non bruciare la squadra?
Limiti di pagina rate, ridistribuzione dei carichi di lavoro, «follow-the-sun», ringhiera mensile dei rumori.

Il sistema di notifiche e alert è una catena di montaggio controllata dal segnale all'azione. Costruiscila su SLO, disattivare il rumore, instradarlo nel contesto, attivare i pulsanti di azione e fissare tutto legalmente. In questo modo si riduce MTTA, si rimuove il carico di lavoro da on-call e si migliora la stabilità aziendale anche in caso di picchi e errori dei provider.