Simulazioni di incidenti

1) Perché eseguire simulazioni

• Riducono MTTD/MTTA/MTTR, aumentano la sicurezza nei ripristini e nei feelovers;
• identificano le lacune nei processi (escalation, comunicazioni) e le debolezze architettoniche;
• entrano nel sistema e migliorano la documentazione (runbook/SOP);
• confermano la disponibilità ai requisiti SLA/regolatori/verifiche.

2) Formati di simulazione

Tabletop (desktop) è uno script di conversazione su bacheca/chat, economico, veloce, perfetto per ruoli e comunicazioni.
Game Day (esercizi di stage/vendita limitati) - passaggi pratici per i playbook; In vendita, solo azioni sicure e reversibili con gate chiare.
Chaos Engineering - Guasti gestiti (disattivazione di dipendenze/reti/nodi) per verificare la stabilità e i gate SLO.
Esercitazioni DR (Disaster Recovery) - Guasto AZ/regione, ripristino da backup, cambio di provider.
Comms-drill - Interamente comunicazioni: stato-pagina, modelli di messaggio, PR/Legale.

3) Ruoli e responsabilità

Incident Comment (IC) - Prende decisioni, guida il piano, disinnesca.
Tech Lead (TL) - Diagnostica, input e ipotesi tecniche.
Comms Lead (CL) - update interni/esterni, pagina di stato.
Scribe - protocollo (timeline, azioni, soluzioni, manufatti).
Osservatori/Assessors - registrano le metriche e la conformità.
Red Team - Consente di immettere input imprevisti.

4) Metriche di successo simulazioni

MTTD/MTTA/MTTR per incidente sintetico.
Comm SLA: tempestività e qualità degli update.
SLO-guardrails: risposta corretta al burn-rate, quorum di campioni esterni.
Runbook fidelity:% passaggi completati per documento, senza improvvisazione.
Escalation latency - Velocità di connessione del ruolo/provider desiderato.
Checklists pass-rate: «pronto/accettato/chiuso».
Noise & Fatige: alert extra, surriscaldamento on-call.
CAPE competition - Percentuale di azioni eseguite dopo la simulazione.

5) Preparazione: cosa serve prima della partenza

Scopo e ipotesi: cosa testiamo (processi, architettura, esseri umani).
Lo scenario e le iniezioni sono una sequenza di sintomi/eventi con i tyming.
Restrizioni di sicurezza: divieto di modifiche irreversibili; punti di annullamento.
I dati e gli stand sono: traffico sintetico, flag fich degrado, chiavi sicure.
Documenti: collegamenti runbook/SOP, escalation, contatto-foglio dei provider.
Osservabilità: dashboard/alert pre-contrassegnati, test-canarini.
Logistica: tempo/durata, membri, war-room canale, scrittura.

6) Simulazione: fasi

1. Brief (5-10 min): IC ricorda obiettivi, ruoli, regole di sicurezza, criteri di completamento.
2. T0 - Iniezione di sintomi: alert (s), caduta di SLI aziendale, stato esterno del provider.
3. Triage e escalation: assegnazione di SEV, release freeze, connessione dei ruoli desiderati.
4. Diagnostica: ipotesi, controllo DNS/TLS/CDN/Database/crash/pneumatici, annotazioni di rilascio.
5. Azioni mitiganti: flag, flag di degrado, failover provider, limiti/retrai.
6. Comunicazioni: update regolari (formato:). update).
7. Recupero e convalida: sintetico esterno + SLI nella zona verde N intervallo.
8. Debrief (AAR): 15-30 min - fatti, conclusioni, CAPA.

7) Esempi di script (directory)

Riduzione del successo dei pagamenti: il provider A è degradato in un paese; le azioni previste sono ridistribuzione del traffico, inclusione di UX semplificato, comunicazione.
Errore DNS - Errore di scrittura/TTL, alcuni utenti non tagliano il dominio. i passi previsti sono fissi/folback, pulizia CDN, stato-update.
Certificato TLS scaduto: la stretta di mano si rompe per i clienti più vecchi; in attesa dell'estensione di emergenza e del controllo della catena.
Kafka lag: aumento del ritardo negli eventi KYC/AML; Le aspettative sono ridimensionare i concimatori, limitare i produttori.
Database p99 e crescita 5xx: indici stretti, limite di connettività; attesa - flag fich, limiti, hotfix/ritorno.
Guasto regionale: disattivazione del sistema; attesa - GSLB/Anycast failover, controllo dati e SLO.
Comunication Drill è tutto verde, ma controlla modelli, intervalli e allineamento con Legale/PR.

8) Modello di iniezione (scheda)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Sicurezza e compliance

Le simulazioni prod sono solo reversibili: flag fich, cambio di traffico a piccole quote, repliche da leggere, «shadow traffic».
Controllo di accesso/controllo: tutte le attività tramite ChatOps/pipline; registri in un archivio non modificabile.
PII/segreti - non utilizzati in manufatti didattici; i dati sono depersonalizzati.
Regolazione: se la simulazione coinvolge le comunicazioni client, contrassegna «insegnamento» nei canali privati; i post pubblici non sono simulati.

10) Valutazione e AAR RCA

AAR (After Action Review) - Subito dopo l'esercitazione, cosa si aspettava/vedeva che funzionava/no.
RCA - Per errori significativi (ad esempio, non è stata eseguita l'escalation) su un modello RCA.
CAPA è un elenco di azioni con proprietari/scadenze/metriche di effetto (modifiche a playbook, alert, architettura).
Punti di controllo - D + 14/D + 30: controllo di esecuzione, ripetuto mini-drill per le posizioni vulnerabili.

11) Documentazione e manufatti

Piano di simulazione: obiettivi, script, iniezioni, partecipanti, finestre, criteri di successo.
Timeline (UTC): T0... Tn, soluzioni IC, passaggi tecnici, update.
Foto di dashboard/unità, estratti di alert e statali.
Report finale: metriche, soluzione temporale con playbook, CAPE.
Aggiornamenti di documentazione: modifiche runbook/SOP/contatti, collegamenti a nuovi dashboard.

12) Frequenza e copertura

Tabletop: 2-4 volte al mese (per flussi e ruoli chiave).
Game Days: 1-2 volte al mese.
Caos-valigetta (prod-light): trimestrale, rigorosamente per gate.
Esercitazioni DR: 1-2 volte all'anno con cambio reale.
Comms-drill: ogni mese per l'allenamento dei modelli e degli update SLA.

13) Assegno fogli

Prima della simulazione

• Script, input, criteri di successo, finestre di sicurezza.
• Ruoli, canali, stato dei modelli concordati.
• La disponibilità di stand/bandiere/dashboard è stata verificata.
• Il piano di reversibilità è documentato.
• I rischi e l'impatto su SLO/clienti sono valutati.

Durante

• SEC assegnato, rilascio freeze (se necessario).
• Comunicazioni pianificate, formato supportato.
• Tutte le azioni attraverso gli strumenti di revisione.
• Scribe tiene un protocollo, raccoglie manufatti.
• Sicurezza: i divieti/restrizioni sono rispettati.

Dopo

• AAR completato, report salvato.
• RCA (in caso di fallimento) avviato.
• CAPE sono con proprietari/scadenze.
• Runbook/SOP/contatti aggiornati.
• È previsto un retest di luoghi vulnerabili.

14) Anti-pattern

«Improvvisazione al posto del piano» non ha scenari o criteri di successo.
I rischi senza gate e il piano di cancellazione si stanno trasformando in un incidente.
Solo la tecnica senza comunicazioni o escalation.
Assenza di AAR/RCA - il team non impara.
Caos Prod senza osservabilità e SLO Gardrail.
Diritti opachi: modifiche manuali segrete in vendita.

15) Mini modelli

Agenda Game Day (60-90 min)

1. Brief (5 min): Obiettivi, ruoli, sicurezza.
2. Copione T0 (5 min) → Somministrazione dei sintomi.
3. Triage/escalation (10 min).
4. Diagnostica + azione (30-45 min) - 1-2 «iniezione».
5. Ripristino e convalida (10 min).
6. AAR (15 min) - conclusioni, CAPA.

Modello AAR (breve)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Totale

Le simulazioni di incidenti sono una «palestra» per le persone, i processi e l'architettura. Esercitazioni regolari, sicure e misurabili trasformano le crisi in routine: il team reagisce più velocemente, i playbook funzionano davvero, l'architettura è più sostenibile e il regolatore e i clienti vedono la maturità della funzione operativa. Ciò che conta sono obiettivi chiari, gate sicuri, buone metriche e obbligatori.