Gestione degli incidenti

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

La gestione degli incidenti è un processo ripetuto per ripristinare rapidamente il valore utente e ridurre al minimo i danni aziendali. Basi - Ruoli chiari (Incident Manager, Tech Lead, Comms), gate SLO, scalate, processi ChatOps, runabook preparati e scansioni post-incidenti con items misurabili.

1) Obiettivi e principi

Velocità e sicurezza: diagnosi rapide, stabilizzazione sicura e ripristino sostenibile.
Unico proprietario: l'Incident Manager (IM) assegnato adotta le soluzioni di processo.
Comunicazione come prodotto: update prevedibili per gli stakeholder e gli utenti.
Dati> opinioni: SLO/metriche/roulotte/logi è la fonte della verità.
Blameless: analizzare le cause senza accuse personali; Focus sui miglioramenti di sistema.

2) Classificazione degli incidenti (Severity/Impatto/Urgency)

• SEV1 (critico): danni gravi ai ricavi/TTW/pagamenti,> 20% utenti o regioni intere; SLA violato/minaccia PII.
• SEV2 (alto): degrado parziale dei flussi chiave (deposito/tasso/avvio giochi), impatto 5-20%.
• SEV3 è una notevole degradazione dei servizi secondari.
• SEV4 (basso): minore, effetto limitato, senza influenza SLO/SLA.

Impatto: chi è colpito (tutto/regione/tenante/canale). Urgency: velocità di degrado (fast-burn/slow-burn sul bilancio degli errori).

3) Ciclo di vita dell'incidente

1. Detect è un segnale da alert/SLO/sintetici/reperti.
2. Acknowledge - on-call conferma l'accettazione, assegna IM.
3. Triage - Valutazione SEC/Impatto, raccolta di ipotesi, apertura di War-Room.
4. Mitigate - Stabilizzazione (reimpostazione/cambio di rotta/ficcoflagi/ridimensionamento).
5. Communicate è uno status-update regolare (dentro/fuori).
6. Recover: ripristino completo di SLO/metriche aziendali.
7. Close - Fissazione cronologia, raccolta manufatti, PIR (RCA + action items).

4) Ruoli e responsabilità (diagramma RACI)

Input Manager (IM) - Proprietario del processo, assegna ruoli, controlla il tempo, adotta soluzioni di processo (R).
Technical Lead (TL) - Gestisce la diagnosi/ipotesi/record, coordina gli ingegneri (A/R).
Comunicazioni (Comms) - stato-update, collegamento con supporto/business/PR, stato-pagina (R).
Scribe - protocollo (timeline, decisioni, collegamenti, manufatti) (R).
Stakeholders - prodotto/pagamento/provider di giochi/sicurezza (C/I).

Minimo per SEV1: IM + TL + Comms + Scribe. SEV2 consente l'abbinamento dei ruoli.

5) War-Room и ChatOps

I singoli canali sono «# incident-warroom- <id>», «# incident-status» (solo update).
I comandi modello sono: '/incident start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot allinea il contesto: le ultime release, i dashboard, gli alert collegati, trace excempars, gli schemi delle dipendenze.
Regole di comunicazione: brevemente, secondo i fatti, un portavoce (TL), IM modernizza.

6) Trigger e gate

SLO-gate: fast/slow burn, calo della conversione dei pagamenti, TTW p95> soglia, p99 API ↑, code di pagamento «brucia».
Attività automatiche: stop canary, rollback, attivazione modalità degrade (limitazione delle funzioni), attivazione sintetica ad alta frequenza.
Freeze: tutti i rilasci/migrazioni stop a stabilizzazione e PIR.

7) Script tipici (runabook-pattern)

A) Pagamenti: aumento di timeout/rifiuto da PSP

1. Stop promote e congelamento delle release del circuito di pagamento.
2. Sposta il percorso PSP a quello di riserva, alza il timeout/retrai per criteri.
3. Verifica delle transazioni in sospeso, ripetizione con chiavi idipotenti.
4. Comunicazione Comms-zapport, la riserva funziona? ETA.

B) API e 5xx dopo il lancio

1. Ripristina (blue-green/canary).
2. Controlla la cache hit, la profondità delle code, i punti caldi del database/provider di giochi.
3. Ridimensionamento temporaneo, limitazione dei file pesanti attraverso la feature flags.

C) Il provider di giochi non è disponibile

1. Sposta il traffico agli studi/giochi disponibili, mostra il banner di stato.
2. Attivare controlli sintetici ogni 30-60s.
3. Concordare rimborsi/bonus (per la politica) - inserire nel PIR.

D) Fuga di notizie/sospetto di PII

1. Isolamento del componente, riepilogo delle chiavi/token, raccolta dei fogli (WORM).
2. Allineamento della comunicazione legale/regolamentazione.
3. Attività post-incidenti: segreto-rotazione, occultamento, accessibilità.

8) Comunicazioni (interne/esterne)

Velocità degli update: SEV1 ogni 15-30 minuti, SEV2 ogni 30-60 minuti

• «Depositi PSP-X».
• Chi è stato colpito da «TR/BR, il 18% degli utenti del flusso».
• «12:07 EET, SEV1».
• Cosa facciamo: «Spostiamo il percorso a PSP-Y, includiamo i retrai/limiti di puntata».
• «Tra 20 minuti».
• Contatto: IM @ duty-im, TL @ oncall-pay.

Stato pubblico (pagina/social) - abbreviato, senza PII o dettagli superflui, con ETA e link a ulteriori aggiornamenti.

9) Raccolta e controllo degli artefatti

Timeline eventi (precisione dei minuti), versioni dei servizi, flag fich, modifiche ai configh.
Le immagini dei dashboard, le piste indicative (trace _ id), i fogli «prima/durante/dopo».
Collegamenti a ticket, PR, release, runabuki.
Rapporto comunicazione (quando/chi/cosa).
Tutto è nella cartella dell'incidente.

10) Chiusura e PIR (Post-Incent Review)

• Riepilogo di cosa è successo, scala, durata, SEC.
• Impatto: utenti/regioni, SLO/SLA, fine. Effetto.
• Timeline, dettagli, minuti.
• Root Cause - Tecnico + organizzativo (perché non modificato in precedenza).
• Detection & Defenses: Che cosa ha aiutato/deluso (alert, sintetico, phicheflagi).
• Action Items: attività specifiche, proprietari, tempi (e come verificare l'effetto).
• Lessons Learned: cosa cambia nel processo/architettura/osservabilità.

Le regole sono: niente accuse, massimo fatti, follow-up obbligatorio entro le 3 settimane di verifica dei punti eseguiti.

11) Metriche di affidabilità processo

MTTD (Mean Time To Detect) - Tempo medio di rilevamento.
MTTA (… Acknowledge) - Prima della conferma on-call.
MTTR (… Restore) - Prima del ripristino SLO.
Change Failure Rate è il% dei comunicati che hanno causato incidenti.
Invio Rate per SEC, distribuzione per dominio (Payments/Games/Infra).
Alert Quality: numero di rumori/falsi, tempo prima dell'azione dopo l'alert.
Comm-SLA: rispetto della frequenza dello status-update.

12) Integrazioni con SLO e release

Gate in CD: promozione dei canarini solo con proxy SLO verdi (availability, p95, 1962, TTW).
Procedure Freeze: con fast-burn/SEV1 - Stop delle release fino a PIR.
Le annotazioni automatiche nei grafici sono visibili sui dashboard.

13) Regolazione e compilazione

PII: occultamento/alias in logi/trailer, archivio di controllo WORM, controllo degli accessi.
Regionalità: non trasferire i dati utente al di fuori delle giurisdizioni consentite.
Report: e-mail/notifiche formalizzate ai regolatori - modelli e processo di escalation.

14) Formazione e preparazione (Game-Day)

Esercizi trimestrali: «calo PSP», «fornitore giochi non disponibile», «p99 slot», «perdita chiave».
Timer su MTTA/MTTR, retro per esercizio.
Aggiorna runabook e contatti, controlla i comandi ChatOps.

15) Foglio di assegno pronto (prima dell'incidente)

1. Regole SEC e matrice di escalation concordate.
2. È stata assegnata la rotazione on-call, IM/TL/Comms/Scribe.
3. Runabook per script chiave (pagamenti, giochi, database, cache, code).
4. Scheda SLO e burn-rate alert, pagina di stato.
5. ChatOps-bot - Comandi, circuito automatico, modelli di stato.
6. Modelli PIR e schede di incidente.
7. Regolare game-day e revisioni dei contatti/diritti.
8. Regola freeze e pulsante rosso (rollback/kill-switch).

16) Antipattern

Non c'è un IM unico. La folla è in testa.
Mancanza di SLO-gate, rilevamento tardivo, alert rumorosi.
Il lancio durante l'incidente senza freeze ha causato errori a cascata.
Non ci sono abbastanza scafisti, niente manufatti, PIR debole.
La cultura accusatoria ha → gli errori nascosti, il timore di un'escalation.
La comunicazione «ispirazione» è una perdita di fiducia del business/utente.

17) Modelli (copiare nel tuo wiki)

A) Carta incidente (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Stato-apdate (interno)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (cappello)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Riepilogo

Una forte gestione degli incidenti è la struttura + disciplina: ruoli preconfezionati, gate SLO, runabook lavorati, comunicazioni trasparenti e PIR «senza vini». Questo tracciato riduce MTTA/MTTR, riduce i costi di inattività, rafforza la fiducia degli utenti e consente di rilasciare più audaci ma sicuri.