Reazioni a incidenti e incidenti

(Sezione Operazioni e Gestione)

1) Definizioni e obiettivi

L'incidente è un evento che viola SLO/sicurezza/compliance o crea rischi per clienti, denaro, dati, reputazione.
Gli obiettivi della risposta sono ripristinare rapidamente il servizio, ridurre al minimo i danni, fissare le prove, comunicare in modo trasparente e evitare che si ripeta.

Principi chiave

Safety first: proteggere le persone/dati/denaro è più importante delle funzioni.
One throat to choke - Un unico Input Comment (IC) prende decisioni.
Actionable now: ogni ipotesi è accompagnata da un controllo/azione.
Evidence matters: tutto è logico, gli artefatti sono firmati, la timeline è dettagliata.

2) Classificazione (severity & priorità)

Trigger: violazione dello SLO, regola dell'alert, reperto manuale, incidente legale (DPO/CCO).

3) Ruoli e responsabilità (RACI)

Invident Comment (A) è il leader dell'incidente, l'elaborazione degli obiettivi, la decisione, il cambio di IC in casi di incidenti lunghi.
Tech Lead (R) - diagnostica tecnica/fissaggio, coordinamento SRE/engineering.
Comms Lead (R) - Scrive lo stato di aggiornamento (interno/esterno), proprietario della pagina.
Scribe (R) - protocollo, timeline, raccolta manufatti.
Sicurezza/Legale (C/A per i casi di security) - Valutazione dei rischi, notifiche obbligatorie.
Customer Support (C) - Modelli di risposta, routing ticket.
Partner Liaison (C) - comunicazione con provider/tenenti.
Gestione (I) - Informazioni, soluzioni aziendali (prestiti/compensi).

4) Primi 15 minuti (modello)

1. Assegna IC e apre la scheda dell'incidente (chat, video, Jira/Tracker).
2. Assegnare il SV e fissare il sintomo SLO (che è esattamente compromesso).

• Abilitare runbooks/run: circuito-breakers, trottling, cambio di rotta, pausa promo;
• durante la compromissione - kill-switch delle funzioni sensibili.
• 4. Comandi Tech Lead - Diagnostica; Comms - «Colld tecnico» (10-15 minuti dopo il primo aggiornamento).
• 5. Definire le ipotesi (tre al massimo), assegnare i proprietari, impostare i timer per il controllo (5-10 min).
• 6. Raccogli gli artefatti: schizzi di metriche, confighi, hash release, logi con «trace _ id», ricevute.

5) Prima ora (modello)

Comunicazione v1 (15-20 min): il fatto, la copertura, i sintomi che facciamo, il seguente aggiornamento. Niente speculazioni.
I limiti dell'incidente sono le regioni/tenenti/canali/versioni interessate.
Controllo dei danni: gap/restrizioni temporali, disattivazione delle integrazioni «rumorose», attivazione della modalità di degrado.
Forenzica: congelare le rotazioni dei fogli, proteggere gli artefatti (WORM/Firme).
La road map è T + 30/T + 60 con assegno.

6) Comunicazioni e stato pagina

Intervalli interni: P1 ogni 15 minuti, P2 ogni 30-60 minuti

Esterne: pagina di stato/tenenti/partner SLA.

• Ciò che si vede è «X: YY UTC aumento dei guasti checkout nella regione EU (p95> 250 ms)»
• A chi interessa: «Operatori A/B/C, il 40% del traffico»
• Cosa facciamo: "Attivato un percorso alternativo, trottling promo; Lavoriamo con il provider PSP-1"
• Dati/deadline: «prossimo aggiornamento in 15 minuti»
• Rimborsi: «Applichiamo il credito-nota SLA dopo la chiusura dell'incidente»

7) Playbook (indirizzi per iGaming/Fintech)

PriceMismatch (≠ checkout) - Forza-invalidità della cache, compressione dì fx _ variante/tax _ rule _ variante ', congelamento delle promozioni dinamiche, compensazione delle discrepanze di criterio.
WebhookLag (partner/affiliati) - Scalabilità dei worker, aumento del batch, priorità dei retrai, cappa temporanea per nuove sottoscrizioni.
Payments Outage/PSP: passaggio a PSP di backup, riduzione dei timeout client, clearing della coda manuale, transazioni «grigie» in quarantena.
RTP Draft: interruzione dei bonus, controllo delle tabelle dei pagamenti/versioni, estensione della finestra di sorveglianza, ripristino del profilo RTP.
Fraud Spike - Raffinare velocity/limiti, includere un controllo KYC aggiuntivo, l'isolamento di griffe sospette, la gelosia manuale di vincite elevate.
Data/PII Exposure: isolamento dei sistemi, notifica DPO/Legale, inventario dei record interessati, notifiche di regolazione.

8) Strumenti e rune (auto-azioni)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Guardrail: protezione contro la sella - rimborsi limitati, registri firmati, ogni azione IC/Scribe.
Prova che le firme DSSE, gli hash di snap, i tagli Merkle dei fogli.

9) Fine dell'incidente

Criteri: SLO ripristinato, coda rimborsata, dati/soldi ridotti, rischi chiusi, comunicazioni inviate.
Rituale di chiusura: aggiornamento finale dello stato, timeline, elenco delle influenze, ipotesi preliminari di causa, data post mortem.

10) Post mortem (nessuna accusa)

Tempo: P1 - entro 3 giorni lavorativi; P2 - 5 giorni lavorativi.
Contenuto: fatti/timeline, origine (5 Whys/FRAM), impatto (SLO, finanza, clienti) che ha funzionato/no, action items (owner, tempo, effetto misurabile).
Test di efficienza: 30-60 giorni dopo: ringhiera di esecuzione e metriche (ripetitività, MTTR, rumore degli alert).

11) Metriche e gestione SLO incidente

MTTD/MTTA/MTTR, Change Failure Rate, Time to Comms v1,% autorizzati.
Alert Noise: percentuale di segnali non rilevanti, pages per on-call maiusc.
Ripeat Incidents: percentuale di ripetizioni in 90 giorni.
Post-mortem SLA: percentuale di trascorsi/chiusi entro il termine.
Risposta SLO: P1 è la prima comunicazione da 15 min; MTTR ≤ 60 min; completezza degli artefatti = 100%.

12) Diritto/compilazione/privacy

Notifiche legali: i regolatori locali per le fughe/incidenti.
Riduzioni PII: accesso al primario solo attraverso i jobs approvati; Tornizzazione/occultamento.
Conservazione di manufatti: registri WORM, periodo di conservazione giurisdizionale Controllo di accesso (RBAC/ABAC, JIT).
Contractor: SLA contrattuali, processo di escalation, ricevute di processo.

13) Organizzazione dei turni e delle escalation

24 x 7 on-call: rotazioni per ruoli (SRE, App, Data, Security, Payments).
Matrice di escalation: chi per regioni/prodotti/provider; duplicazione dei contatti (chat/voce/SMS).
Simulazioni - calo del PSP, valanga di retrai, rashincron dei prezzi, compromissione della chiave, rifiuto della regione.

14) Dashboard incidenti

Caldo (ora): stato SLO, p95/p99, mappa delle regioni/tenenti, coda di attività, manufatti raccolti/no.
Le tendenze per tipo di incidente, l'efficacia delle rune, la ricorrenza delle cause.
Controllo qualità: interezza della timeline, «coverage» post mortem, comunicazione SLA.

15) Assegno-foglio di implementazione

• Approva la scala SEC e i trigger SLO.
• Assegna ruoli (IC/Tech/Comms/Scribe/Sec/Legale) e rotazioni 24 x 7.
• Esegui un unico modello di tessera di incidente e una pagina di stato.
• Descrivi playbook (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Implementare le rune con l'audio e il pulsante rosso.
• Abilita il criterio forense: WORM/firme/raccolta artefatti.
• Regolamento delle comunicazioni (intra/esterna) , SLA aggiornamenti.
• Processo post mortem e modelli; KPI di esecuzione di action items.
• GameDays mensilmente; una panoramica trimestrale dei trend degli incidenti.
• Metriche IR sul dashbord (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

Perché l'IC One?
Un unico punto decisionale elimina il caos e accelera la reazione.

Quando lo annunci pubblicamente?
Una volta confermato il fatto e il piano di stabilizzazione. Valuti i tempi regolatori.

Cosa c'è di più importante, una fix o un rapporto?
Prima il ripristino e la sicurezza. Parallelamente, la raccolta di manufatti. Il rapporto è dopo la stabilizzazione.

È possibile automatizzare tutto?
No, ma le rune chiudono i passaggi «frequenti e semplici». Il resto è attraverso playbook e allenamenti chiari.

Riepilogo: Il forte Invident Response non è solo un canale di chat e PagerDuty. Questa è la disciplina dei ruoli, i primi 15 minuti rapidi, le rune controllate, le comunicazioni trasparenti, la forensica con la prova e il post mortem obbligatorio. Con questo tracciato si riduce MTTR, si proteggono denaro e dati e si aumenta la fiducia dei clienti e dei regolatori.