Alert in tempo reale

1) Scopo e principi

Obiettivo: informare puntualmente, con precisione e indirizzando le persone/i sistemi giusti degli eventi che minacciano il SLO, il fatturato e la compliance e avviare le azioni corrette (manuali/automatiche).
Principi: SLO-first, riduzione del rumore, spiegabilità, contesto, priorità di impatto aziendale, «un segnale è un'azione comprensibile».

2) Tassonomia dei segnali

Segnali SLO: bilancio burn-rate degli errori su percorsi critici (login, deposito, tasso, output).
KRI: indicatori di rischio precoci (caduta auth-success in PSP per banca/GEO, crescita consumer-lag, p99↑).
Eventi: flap delle dipendenze, failover, cambio manuale, attivazione del blocco (rate-limit, WAF).
Sicurezza/compilazione: aumento delle operazioni sensibili, esportazione di PII, violazioni del sistema.

3) Livelli e avvisi SLA

4) Origini e correlazione del contesto

Telemetria: metriche/roulotte/logi, sintetico e RUM.
Cataloghi: CMDB/Servizio-mappe, proprietari, dipendenze.
Modifiche: release, ficchflags, migrazioni, operazioni pianificate.
Provider esterni PSP/KYC/Giochi studio/CDN/WAF states.
Ogni alert si arricchisce, cos'è cambiato? (rilascio/ficflag), quali dipendenze sono rosse? Quale segmento sarà influenzato? (GEO/PSP/banca/tenante).

5) Regole di alerting SLO (kernel)

Burn-rate: due finestre (veloce 1h e lento 6-24h). Cercapersone solo se superata contemporaneamente.
Guardrails: le soglie p99/error-rate sono solo i trigger dell'analisi contestuale, non sostituiscono lo SLO.
Impatto: «Percentuale di pubblico x denaro/min x regolatory» livello P1-P4.

6) Soppressione del rumore

Deduplicazione: raggruppamento per servizio/tenante/motivo Decifrare un incidente anziché dozzine di segnali.
Isteresi: N-da-M di conferma, durata minima dell'anomalia.
Silens/moti: lavoro di routine, incidenti noti, finestre follow-the-sun.
Limiti di rate e quote per sorgente/etichetta/tenante; Protezione contro la tempesta.
Riduzione della radicalità, vietato l'allert.

7) Instradamento e escalation

Routing per contesto: dominio (Payments/Games/Core), ambiente (prod/stage), regione, gravità.
Escalation: t0 - on-call L1; t0 + X - L2/proprietario di dominio; t0 + Y - IC/manuale. Il tempo X/Y dipende dalla P1-P3.
Duplicazione per canale: pager + chat per P1; chat/ticket a P3.
Cambio cambio: trasmissione automatica del contesto (timeline, azioni eseguite, ipotesi).

8) Attività auto (auto-rimediazione)

Pagamenti: failover PSP x fee x conversion, limitazione di banche/metodi, retrai con jitter.
Giochi/scommesse: abilita cache-wedge/limita operazioni write, queue-page/waiting-room sul fronte.
L'evacuazione del traffico, il restart dei worker degradati, il ridimensionamento su lag.
Protezione/Compilazione: chiudi temporaneamente l'esportazione PII, inserisci dual-control per le operazioni P1.
Qualsiasi attività automatica è dotata di criteri di ripristino e criteri di restituzione.

9) Runbook-prima esperienza

Ogni alert è associato a runbook: obiettivo, diagnostica rapida (3-5 controlli), fasi di fix/reimpostazione, contatti, riferimenti a dashboard e stato-page. La chat/cercapersone mostra una breve scheda di azione.

10) Lui-call politica

Rotazione 24 x 7, rivestimento di domini (Payments/Game Core/SRE).
«Secondo on-call» per P1, regola di due persone in una sala bar.
Quiet-hours e finestre di servizio per zone (follow-the-sun).
Formazione: esercizi trimestrali (tabletop/game-day), shadow.
Prestiti post-incidenti (p-time) per evitare bruciature.

11) Integrazioni

Gestione incidente: creazione automatica di schede, nastri di update, ruolo IC/CL, timer.
Stato pagina - Pubblica P1/P2 (tramite Comms Lead) con i modelli e la localizzazione.
Release-gates per SLI, auto-stop/rollback per alert.
Cataloghi: proprietari, CMDB, contatti provider.

12) Esempi di alert (iGaming)

1. Auth-success di PSP-1 in TR↓ al 25% in 10 minuti

P2→P1 con copertura> 30% transazioni.
Azione automatica: ridistribuire il traffico PSP-2/3; Abilitare 3DS semplificato alert Partner Manager.

2. p99 «stavka→settl»> 3 x standard in EU

Motivi: lag replica, coda worker.
Azione automatica: scale-out worker, warmup cache, spegnere temporaneamente i file non critici.

3. Export PII spikes

P1 in assenza di ticket/approvazione.
Azione automatica: unità di caricamento, notifica Compliance, verifica SoD.

13) Metriche di alerting (KPI/KRI)

MTTA-Comms/MTTA-Ops: tempo fino alla reazione/prima azione.
Precision/Recall (incidente alert), False Alarm Rate.
Lead-time prima della violazione SLO, TTD (tempo di rilevamento).
Pager fatige: alert/uomini/ned, chiamate notturne, percentuale di «vuoti».
Auto-fix rate - Numero di problemi chiusi da una risposta automatica senza persona.
Aging: quota P3/P4 pendenti> X giorni.

14) Gestione del costo

Quote di alert/sorgenti, taglio di etichette in eccesso.
Downsampling e aggregazione delle metriche, tracciati di sempling; Retenze di classe.
Normale cost-review: $/alert, $/SLI-dashboard, serie «pesante».

15) Privacy e compliance

Senza PII nel testo degli alert e delle etichette; Tornizzazione degli identificatori.
Criteri di accesso (RBAC/ABAC) impostati sulla configurazione degli alert.
Controllo delle modifiche alle regole, versioning, test e diff.

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

Ned. 1-2: catalogo SLI/KRI, mappa dei proprietari, livelli P1-P4, prime regole SLO (burn-rate).
Ned. 3-4: deadup/isteresi/silens, integrazione con il sistema di incidenti e chat, raccordi runbook.
Ned. 5-6: attività auto per Payments/Queues, release-gates, fide di stato.
Ned. 7-8: contesto (release/ficchflagi/provider), schede di calore PSP x bank x GEO, esercitazioni P1/P2.
Ned. 9-10: FinOps di alerting, KPI-Dashboard, revisione delle soglie e delle quote, formazione di lui-colla.

17) Manufatti e modelli

Alert Spec: metrica/condizione, finestre, soppressione, proprietario, runbook, attività auto.
Routing Map, contatti di riserva.
Silenzio Policy - Le regole del mute (incidenti pianificati/noti) di chi può includere.
On-call Handbook: rotazioni, cambio di turno, assegno P1/P2, canali.
Post-Incident Pack - Caricamento di alert/linee temporali, analisi della qualità dei segnali.

18) Antipattern

Il cercapersone «crude» p95/p99 senza lo SLO è un rumore e stanchezza.
Decine di segnali sulla stessa cosa (nessuna deduplicazione/correlazione).
Nessun runbook o proprietario dell'alert.
Soglia «in pietra» senza stagionalità/segmentazione (GEO/PSP/banca/ora).
Nessun ritorno dopo un'azione automatica (nessun criterio roll-back).
Le etichette PII e le userId → i rischi e l'esplosione della cardinalità.

Totale

Un alerting davvero utile è una catena di montaggio SLO-centrica: regole contestuali con burn-rate, soppressione intelligente del rumore, routing chiaro e escalation, runbook-prima esperienza e attività auto sicure. Questo tracciato cattura gli eventi critici prima degli utenti, riduce l'MTTR, protegge i ricavi e allo stesso tempo protegge l'evento dal cercapersone.