Operazioni e → Prevenzione incidenti

Prevenzione degli incidenti

1) Perché è necessario

La risposta migliore all'incidente è la sua assenza. Per iGaming/Fintech ogni minuto di inattività - tassi/depositi persi, multe da provider, rischi di reputazione. La prevenzione sistemica riduce il Cambio Failure Rate, stabilizza lo SLO e rilascia il tempo di sviluppo dei comandi anziché spegnere gli incendi.

• Ridurre al minimo la possibilità di incidenti su vie critiche (deposito, puntata, avvio del gioco, conclusione).
• Intercettare il degrado prima di colpire lo SLO e il portafoglio.
• Limita il raggio di errore (blast radius) e velocizza il ripristino.

2) Principi di base per la prevenzione

1. SLO-first e errore budget: le modifiche non vengono rilasciate se si rischia di eliminare lo SLO e bruciare il budget.
2. Defence in depth - I livelli di blocco vanno dai diagrammi di dati e configurazioni alle regole di rete e ai ficheflag.
3. Design for failure: breaker, timeout, retrai con jitter, idampotenza, degrado.
4. Small & reversibile changes - Piccoli incantesimi + rapido ritorno (feature flags/canarino).
5. Osservabilità by design: metriche/logi/trailer per ogni passo e collegamento critico.

3) Mappa dei rischi e dei percorsi critici

Mappare il dolore in base ai domini Payments, Bets, Games, KYC, Promotions, Jackpots, Content.

• Metriche aziendali (conversione, GGR, assegno medio).
• SLO tecnico (latency p95/p99, uptime, success rate).
• Dipendenze (interne/esterne), limiti/quote.
• Comportamento «Safe mode» (che disattiviamo/semplifichiamo).
• Runbook del proprietario.

4) Guardrail (barriere di protezione)

Timeout e breaker: il servizio chiamante ha un timeout più breve dell'importo interno; il breaker si apre quando crescono gli errori/latitanza.
Isolamento bulkhead - singoli pool di connessioni/worker per downstream.
Rate limit & backpressure - Protezione da valanga e tempeste retrae.
Phicheflagi di degrado: modalità minima - risposte facili, cache-replai, disattivazione dei fili pesanti.
Multi-venditore e feelover: alternative PSP/KYC, cambio di rotta.
Convalida configure: diagrammi/liner/regole per modificare i limiti e i fili in modo sicuro.

5) Gestione delle modifiche

Pre-release gates: test, sicurezza, CDC (consumer-driven contracts), compatibilità degli schemi.
Rilascio canario + autogate: 1% → 10% → 100%; auto-stop in crescita p99/error rate/budget di combustione.
Feature flags: reimpostazione immediata/cambio di comportamento senza deploy.
Release calendar: Evitate le finestre di punta dello sport/tornei e la maintenance presso i provider.
Post-deploy checks: messaggio automatico, confronto tra le metriche «prima/dopo» e le soglie.

6) Test come misura preventiva

Unità/contract/integrazione - Contratti OpenAPI/AsyncAPI, CDC contro provider/moke.
Load & stress - profili di traffico per prime time; test per i limiti connettivi/iOPS/quote.
Soak/long-haul: fuga di risorse, aumento dei ritardi nell'orizzonte ore/giorni.
Chaos/game-days: la caduta del broker/PSP/KYC, la rottura della regione, il «fornitore lento».
Disaster Recovery Drills - Regolare allenamento di cambio di regione e ripristino del database.

7) Rilevamento precoce della degradazione

Capacity-alerts: headroom, colli di coda, connettori di database, eviction nella cache.
SLO-burn-rate - Segnale a velocità pericolosa di «bruciare» il budget.
Soglie adattive: stagionalità/modelli giornalieri per ridurre i falsi.
Gli alert composti: «lag s' + HPA at max + open circus» sono ad alto rischio.
Vendor health: quote/timeout/errori per ogni provider + costo delle chiamate.

8) Operazioni con provider esterni

OLA/SLA-SLO - Allinea gli accordi ai nostri obiettivi.
Playbooks feelover: percorsi PSP-X PSP-Y, cache di token, modalità di deposito grace.
Sandbox e contratti, flow di prova prima di ogni cambiamento maggiore.
Le finestre dei provider sono annotazioni su dashboard e regole suppress automatiche.

9) Dati, configi e segreti

Regole di cambiamento: code-review di due paia di occhi, convalida di schemi/JSON/YAML.
Segreti: KMS/Secret Manager, rotazione, suddivisione per ambienti/ruoli.
Flag/limiti - Modifica tramite API con l'audio e il recupero istantaneo.
Migrazioni: dual shag (expand → migrate → contract), interoperabilità totale.

10) Formazione e preparazione dei comandi

Formazioni on-call: simulazioni di incidenti, servizio shadow, runbook centralizzato e.
Formati di comunicazione unici: modelli di stato/hendover/update di incidente.
Una cultura sicura, senza accuse, ragioni meccaniche e azioni preventive.

11) Dashboard prevenzione (minimo)

Risk & Readover: SLO/Budget, headroom per strati, «top delle connessioni vulnerabili».
Cambio Safety: percentuale di canarini, ribassi, alert post-lancio, CTR autogate.
Vendor Panel: p95/error/quote/costo per ogni provider, ora di risposta dello zapport del venditore.
Chaos/DR Readehi: frequenza degli esercizi, tempo di cambio della regione, successo dei ripristini.
Config/SecOps: modifiche a bandiere, limiti/segreti, anomalie.

12) Esempi di alert preventivi

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
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"}

13) Assegno-foglia di prevenzione (giorno/prima dei picchi)

• Calendario attuale dei picchi (partite, tornei, campagne, finestre dei provider).
• Headroom API/database/cache/code, HPA/VPA pronto, riscaldamento della cache.
• Stato dei provider (quote, limiti, degrado in 24h), il feelover è configurato.
• Gate canari sono inclusi, i filicoflagi sono a disposizione dei proprietari.
• Gli alert SLO/Capacity sono attivi e la supplenza è indicata per le operazioni pianificate.
• Runbook e aggiornato, on-call confermato, i canali di escalation sono operativi.

14) Anti-pattern (da evitare)

«Grandi comunicati notturni» senza canarini e bandiere.
Pool di flusso condivisi per tutti i downstream (head-of-line blocking).
Ritai per operazioni non idonee e temporali di bottiglia.
La mancanza di isteresi negli alerti ha → una segatura alla soglia.
Fede cieca in un venditore SDK senza osservabilità e controllo dei timeout.
«Facciamolo in vendita» senza stage/sandbox e CDC.

15) KPI prevenzione

Change Failure Rate (obiettivo 10-15% o target).
Prince-Incident Detect Rate - Percentuale di incidenti evitati durante la fase di degrado.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage blocca il% dei percorsi critici con bandiere/breaker/timeout/canarino.
Chaos/DR cadence: frequenza e successo dell'esercitazione.
Tempo medio di passaggio al provider di backup.

16) Partenza rapida (30 giorni)

Settimana 1: mappa dei percorsi critici, SLO e proprietari; includere SLO-burn-alert e capacity-alert.
Settimana 2: gate canarie + ficcaflagi; script chaos di base (provider/coda).
Settimana 3: dashboard «Change Safety» e «Vendor Panel», playbook feelover.
Settimana 4: DR.-insegnamento (parziale), retrospettiva e piano di hardening'a per trimestre.

17) Modelli (sezioni)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q: Cosa implementare prima se le risorse sono ridotte?
A: SLO-burn-alert su binari critici, gate canarie e filiflagi a ritroso; poi la mappa dei rischi e il feelover dei provider.

Come si capisce che la prevenzione funziona?
A: Diminuisce la Change Failure Rate, cresce la percentuale di incidenti evitati, scende la MTTR e il rumore degli alert, diminuisce il numero di pagelle notturne.

C'è bisogno di esercitazioni chaos regolari?
A: Sì. Senza allenamento feelover e DR è quasi sempre più lungo e doloroso di quanto sembra sulla carta.