Operazioni e → Predizione incidenti

Prevedere gli incidenti

1) Perché è necessario

Gli incidenti raramente esplodono dal nulla. Prima dell'abbandono, la piattaforma lancia segnali: crescita accelerata del p99, aumento lento del budget errato, lame di code, crescita dei retro su un particolare downstream, avvicinamento delle quote del provider. La previsione sistemica degli incidenti traduce le reazioni da «spegnimento dell'incendio» a «intervento precoce», riducendo MTTR, Change Failure Rate e le perdite di fatturato.

• Identificare i pattern precursori e avviare automaticamente azioni preventive.
• Riduce la quota di P1/P2 spostandosi a sinistra.
• Incorporare le previsioni nei processi di release, faulover e capaccity.

2) Mappa dei segnali (lead indicatori)

• Accelerazione p95/p99 (sfumatura), «coda» ritardi, aumento della variazione.
• Code/striam: crescita «lag» e derivato positivo lag; L'HPA è al massimo.
• Database/cache: "active _ conns/max _ conns'," replication _ lag "," evictions ", caduta" cache _ hit ".
• Rete: errori di mTLS/handshake, altezza 5xx/timeout verso l'esterno.

• 'outbound _ errò _ rate '/' retry _ rate', a un provider specifico, 'circuit _ open', 'quota _ usage> 0'. 9`.
• Provider SLA: finestre pianificate, degrado.

• Carico anomalo (campagne/partite), corse RPS/TPS, mix di regioni/canali insoliti.
• La conversione dei depositi/tassi scende con l'aumento di p99 → di quasi-proxy incidente.

• Burn-rate budget> soglia (ad esempio> 4 x per 10-15 min).
• Frequenti piccoli disturbi SLO (micro-degrado) come marcatore di guasto imminente.

3) Origini e vetrine dei dati

Telemetria online: Prometheus/OTel (metriche, logi, roulotte).
Eventi di incidenti: ticetti/statuti/postmortem (verità target).
Il piano/i fatti di cambiamento sono i comunicati, i ficcoflagi, le migrazioni, le finestre dei provider.
La mappa delle dipendenze, le quote, i proprietari.
Snapshot DWH - Unità di apprendimento/convalida (finestra sincrona!).

Requisiti di qualità: ≥99%, allineamento orario/minuto TZ, definizioni p95/p99 uniche.

4) Approcci di previsione

4. 1 Non parametriche/regole (partenza rapida)

Gli alert di soglia per la velocità di variazione sono «deriv (p99)», «z-score» per le finestre corte.
Condizioni composite: 'lag↑ + HPA = max + circuito _ aperto (to = «PSP-X»)'.
SLO-burn-gate: resi release/canarini a burn-rate> X.

4. 2 Rilevamento anomalie

Seasonal baselines (STL/Prophet-simili idee), rolling mediana + MAD.
Multiplariate: anomalia congiunturale'p99 + retry + open _ circuito + quote '.
Cambio-point detection: CUSUM/BOCPD per le variazioni di tendenza.

4. 3 modelli ML (supervised)

Classificazione «incidente in T + K»? alla finestra dei segni (ad esempio 10-30 minuti prima).
Segni: statistiche, derivati, residui stagionali, provider one-hot/regioni, bandiere di lancio.
Etichette: 'incident{severity∈[P1,P2]}' nell'intervallo [t, t + K].
Esplainability: SHAP/Permutation influence per la fiducia e l'operatività.

4. 4 Ibride SRE-first

Modello di mappatura del rischio (0-1) per la politica di azione (phicheflagi/feelover/pre-scale), con HITL per la critica.

5) Progettazione dei segni (feature engineering)

Finestre scivolanti (1/5/15 min): mean, p95/p99, std, max, slope.
Indicatori relativi: 'p99/baseline _ 1d', 'error _ rate _ delta'.
Files coorte: provider, regione, tipo di gioco/partita, canale dispositivo.
File di carico: RPS, payload size, numero di WS aperti.
Di sistema: 'hpa _ desired/max', 'db _ conn _ ratio', 'redis _ evictions> 0'.
Le bandiere di evento sono «in corso di lancio», «in canarino 10%», «nella finestra del provider».

6) Meccanica predizioni e azioni

1. Correzione del rischio ogni N secondi per dominio (Payments/Bets/Games/KYC).

• Il rischio è 0. 8 + segnali di conferma del proprietario del dominio
• 0. 6–0. Otto avvisi. Preparazione delle misure.

• pre-scale (HPA), attivazione della cache, limitazione delle funzioni pesanti
• Passaggio al provider di backup/percorso
• pausa/rollback canarini;
• Il limite dei retroscena al downstream stretto.

4. HITL: una persona conferma misure di livello «cambiamento del comportamento aziendale».

7) Integrazione nei processi giornalieri

Release: gate predittivi nei canarini (confronto tra prima/dopo e rischio-scorrimento).
Feelover: preparazione automatica/riscaldamento del percorso di backup in caso di rischio del provider.
Capacity: «early uplift» quando l'headroom crolla e cresce.
Avvisi: nastro «principe-incendente» separato + annotazioni in dashboard.

8) Osservabilità e dashboard

Risk Overview: rischi per domini e provider, tendenze, contributo dei segni.
Lead Signals: top-N precursori (sfumatura p99, lag, breaker aperti).
Azioni & Outcomes: cosa è stato attivato, effetto p95/errore, incidenti annullati.
Model Health: precisione/recall/latency, segni draft, frequenza di attività automatica.

9) Metriche di qualità delle previsioni

Recall @ P1/P2.
Precision (meno «false pagelle»).
Lead Time (mediana «quanti minuti prima del fatto»).
Intervention Win-rate (percentuale di casi in cui l'azione ha ridotto i rischi/costi).
Alert Fatige Index (alert/cambio/persona).
Drift Score (stat. differenze tra le distribuzioni dei segni vs del periodo di apprendimento).

Gli obiettivi di default sono Recall (P1) a 0. 7, Precision ≥ 0. 6, Lead Time mediana 8-10 minuti

10) Gestione dei rischi modello (ML Ops/Governance)

Versioning dei dati/codice/manufatti, riproduzione.
Campione/Challenger: il nuovo modello va in parallelo, confronto offline/online.
Deriva: divergenza PSI/KL, ridefinizione automatica delle soglie, alert modello obsoleto.
Esplainability: per ogni decisione, conservare l'importanza dei segni e il riferimento ai dati.
Sicurezza/etica: accessibilità, occultamento PII, controllo delle attività automatiche delle regole.

11) Esempi di regole e regole

policy:
if slo_burn_rate{service="payments"} > 4 for 10m and release_phase in ["canary", "post-deploy_30m"]:
action: pause_release_and_rollback notify: squad-payments

risk_psp_x = sigmoid(
1. 2z(outbound_p99_ms) +
1. 5z(outbound_error_rate) +
0. 8z(retry_rate) +
1. 0I(quota_usage>0. 9) +
0. 7I(circuit_open=1)
)
if risk_psp_x > 0. 8 for 5m -> route_to_psp_y + reduce_features

if (consumer_lag > 5e6 and deriv(consumer_lag) > 5e4) and hpa_desired == hpa_max:
action: scale_consumers + throttle_producers + enable_batching

12) Assegno foglio di implementazione (30-60 giorni)

• Catalogo dei segnali e della «verità» sugli incidenti (severity, timeline).
• Linee di base e stagionalità per le metriche chiave (prima/dopo il lancio).
• Regole dei segnali iniziali (sfumature p99, lag, burn-rate).
• Dashboard Risk/Lead Signals/Action.
• Integrazione con phicheflag/canarini, pre-scale HPA.
• Pilota di classificatore ML su un unico dominio (ad esempio Payments).
• Criteri HITL e Registro attività automatiche.
• Metriche di qualità e alert sulla deriva/modello di salute.

13) Anti-pattern

Palloncini di cristallo: modello ML complesso senza linee di base o regole semplici.
No actionability: prevediamo «male», ma non facciamo nulla automaticamente.
Ignorare la stagionalità/calendario eventi (partite/tornei) è un falso allarme.
La miscelazione delle zone temporali ha creato finestre di metriche/incidenti sbagliate.
La mancanza di esplainability ha causato la diffidenza, la disattivazione dei comandi.
Una sola soglia globale per tutti i domini/regioni è scarsa precisione.

14) Dominio specifico (iGaming)

Payments: provider/quote, crescita «retry _ rate» e «circuito _ open» → un feelover precoce.
Bets: ritardi nell'aggiornamento dei coefficienti, crescita WS-Fan-Out e limite di trasmissione.
Giochi/Live: picchi di connessioni, limiti di studio, degrado UI/cache.
KYC/AML: ritardi webhook, code di convalida HITL e elaborazione ritardata.

15) Esempi di metriche e alert (idee)

ALERT PreIncidentRiskHigh
IF risk_score{domain="payments"} > 0. 8 FOR 5m
LABELS {severity="critical", team="payments"}

ALERT LeadSignalP99Slope
IF deriv(api_p99_ms{service="bets"}[5m]) > 15 AND api_p99_ms > baseline_1d 1. 2 FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderEarlyQuota
IF usage_quota_ratio{provider="psp_x"} > 0. 85 FOR 10m
LABELS {severity="info", team="integrations"}

ALERT StreamLagStorm
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND hpa_desired == hpa_max FOR 10m
LABELS {severity="critical", team="streaming"}

16) Programma di predizione KPI

Principe-Incident Detect Rate (percentuale di incidenti evitati/attenuati).
Avg Lead Time prima dell'incidente.

Reduction in P1/P2 kw

MTTR (previsto per il primo contesto).
False Alarm Rate/Alert Fatige (stabile).
Cost Avoidance (valutazione perdite evitate/multe/overskale).

17) Partenza rapida (ricetta)

1. Includere regole sfumature su p99/lag e SLO-burn;

2. Aggiungere condizioni composite ai provider;

3. Collegare il predico con i ficcoflagi e pre-skale;

4. Rapporto «predizione, azione e effetto»;

5. Pilota ML in un unico dominio; Scalare dopo la crescita Precision/Recall.

18) FAQ

Come iniziare senza ML?
A: Linee di base stagionali + sfumature + regole composite. Questo dà una notevole crescita di Recall senza complicazioni.

Come non annegare in un fols positivo?
A: Combinare i segnali, immettere isteresi e tempi di conferma, regolare le soglie per dominio/regione, valutare Precision e Alert Fatige.

Q: Quali azioni automatizzare per primi?
A: Sicuro e reversibile: pre-scale, accensione cache/degrado, pausa/rollback canarini, cambio provider a segnali confermati.