Escalation degli incidenti

1) Scopo e principi

L'escalation degli incidenti è un processo gestito per attirare rapidamente i ruoli e le risorse corrette per ridurre al minimo l'impatto sugli utenti e sulle metriche aziendali.

• La velocità è più importante dell'idealità. Meglio fissare l'incidente prima e disinnescarlo che arrivare tardi.
• Un unico comando. Un responsabile della soluzione è Incident Comment (IC).
• Trasparenza. Chiari stati e canali di comunicazione per gli stakeholder interni ed esterni.
• Documentabile. Tutti i passaggi, le soluzioni e le timeline sono fissati per il controllo e i miglioramenti.

2) Grado di serietà (SEV/P)

• SEC-0/P0 (cruciale) - Totale indisponibilità della funzione chiave (login/pagamento), perdita di dati, rischio legale. Immediata programmazione dell'intero kernel on-call, rilascio freeze.
• SEC-1/P1 (alto) - Degrado p95/p99, aumento della percentuale di errori/guasti nel processo chiave, indisponibilità della regione/provider.
• SEC-2/P2 (media) - degrado parziale per coorti limitati (regione, fornitore), c'è un percorso di aggiramento.
• SEC-3/P3 (basso) - non è critico per l'utente, ma richiede attenzione (ritardo ETL di sfondo, rapporto scaduto).

• Il raggio di impatto (quanti utenti/giro) x durata x sensibilità (regolatore/PR) è il livello del SEC.

3) Processo KPI

MTTD - dall'inizio dell'incidente al primo segnale.
MTTA - dal segnale alla conferma IC.
Tempo di ripristino MTTR - Prima del ripristino SLO/funzione.
Escalation Latency - Dalla conferma alla connessione del ruolo/comando desiderato.
Reopen Rate è la percentuale di incidenti riaperti dopo «risolto».
Comm SLA - Rispettare gli intervalli degli update esterni/interni.

4) Ruoli e responsabilità (RACI)

ID - Proprietario della soluzione, imposta livello, piano, freeze, escalation, disinstallazione. Non scrive registrazioni.
Tech Lead (TL) - Diagnostica tecnica, ipotesi, coordinamento degli ingegneri.
Comms Lead (CL): stato delle pagine, comunicazione client e interna, allineamento con Legale/PR.
Scribe: l'accurata fissazione dei fatti, della timeline, delle decisioni prese.
Liaisons - Rappresentanti di provider/comandi esterni (pagamenti, KYC, hosting).
Ingegneri on-call: esecuzione del piano, avvio di playbook/rimborsi.

Assegnare grafici di servizio e backup per ciascun ruolo.

5) Canali e manufatti

Canale war-room (ChatOps) - Un unico punto di coordinamento (Slack/Teams) con un modello di annotazioni automatiche (versioni, flag, canarini).
Il video per la SEV-1 +.
Tiquet incidente (one-pager): ID, SEC, IC, partecipanti, ipotesi/diagnosi, passi, ETA, stato, impatto, riferimenti grafici.
Pagina di stato pubblica/interna; pianificazione degli update regolari (ad esempio, ogni 15-30 minuti per le SV-1 +).

6) Time box e intervalli standard

T0 (min 0-5) - IC assegnato, SEC assegnato, rilascio freeze (se necessario), war-room aperto.
T + 15 min: primo messaggio pubblico/interno (che è stato colpito, workaround, prossima finestra di update).
T + 30/60 min: escalation del livello successivo (piattaforma/database/sicurezza/provider) a meno che non ci sia una dinamica sostenibile.
Update regolari: EV-0: ogni 15 minuti; SEC-1: ogni 30 minuti SEC-2 +: ogni ora.

7) Regole di escalation automatica (regole di attivazione)

• Burn-rate budget errori sopra la soglia in finestre corte e lunghe.
• Quorum di campioni esterni: le regioni registrano una degradazione HTTP/TLS/DNS.
• Business SLI (successo pagamenti/iscrizioni) scende sotto SLO.
• Firme di sicurezza: sospetto di fuga/compromissione.
• Segnale di provider: webhook di stato «major outage».

8) Processo da rilevamento a soluzione

1. Dichiarazione incidente (IC): SEC, copertura, freeze, avvio playbook.
2. Diagnostica (TL) - Ipotesi, isolamento del raggio (regione, provider, file), controlli (DNS/TLS/CDN/DATABASE/cache/pneumatico).
3. Azioni mitiganti (vittorie veloci): ritorno/canarino, flag flag, failover provider, rate-limit, cash overlay.
4. Comunicazione (CL): stato pagina, client/partner, Legale/PR, aggiornamenti pianificati.
5. Conferma di recupero: sintetico esterno + metriche reali (SLI), rimozione freeze.
6. Disinnesco: riduzione della SEV, passaggio alla sorveglianza N minuti/ore.
7. Chiusura e RCA: preparazione post mortem, action items, proprietari e scadenze.

9) Operazioni con provider esterni

Provini personalizzati per i provider di più regioni + mirroring-esempi di richieste/errori.
Accordi di escalation (contatti, risposte SLA, priorità, webhoop di stato).
Failover automatico/reindirizzamento del traffico tramite il provider SLO.
Base di prova: timeline, sample richieste/risposte, grafici latitanti/errori, ID del ticket provider.

10) Regolazione, sicurezza e PR

Sicurezza/P0: isolamento, raccolta di manufatti, riduzione della divulgazione, notifiche obbligatorie (interno/esterno/regolatore).
Legale: negoziare la formulazione degli update esterni, registrare i contratti SLA/multe.
PR/Servizio client: modelli di risposta pronti, Q&A, rimborsi/crediti (se applicabile).

11) Modelli di messaggio

• "Stiamo indagando su un incidente SEV-1 che riguarda [funzione/regione]. I sintomi sono [brevemente]. Abbiamo attivato un percorso di bypass [descrizione]. L'aggiornamento successivo è a [ora]"

• "Diagnostica [ipotesi/conferma]. Azioni: [hanno cambiato provider/ritrattato/attivato il degrado]. Impatto ridotto a [%/coorte]. Il prossimo update è [ora]"

• "L'incidente è stato risolto. Il motivo è [radice]. Tempo di ripristino: [MTTR]. I seguenti passaggi sono [controllo/controllo N/ore]. Post mortem - [quando/dove]

12) Playbook (approssimativo)

Riduzione del successo dei pagamenti: ridurre la quota del provider A, trasferire X% in B; Abilitare degrade-payments-UX Abilitare i retrai nei limiti avvisa il team finn.
Crescita p99 API: ridurre il canarino della nuova versione Spegnere i fili pesanti ingrandire la cache TTL controllare indici database/connettori.
Problema DNS/TLS/CDN: convalida certificati/catene; Aggiorna il record passare al CDN di riserva Rivuole la cassetta.
Sospetto di sicurezza: isolamento dei nodi, rotazione chiave, attivazione delle maniglie mTLS, raccolta degli artefatti, notifica Legale.

13) Decalcolazione e criteri «deciso»

• La SLI/SLO è stabile in una zona verde a intervalli N;
• sono state eseguite azioni mitiganti e di sorveglianza senza regressione;
• per la classe di sicurezza: chiusura dei vettori confermata, chiavi/segreti rotati.

La chiusura è solo dopo aver bloccato timeline, proprietari di action items e scadenze.

14) Post-mortem (non aratale)

1. I fatti (timeline vista dagli utenti/metriche).

2. Causa radice (tecnica/processuale).

3. Che non ha funzionato durante l'escalation.

4. Misure preventive (test, alert, limiti, architettura).

5. Piano d'azione con deadline e proprietari.

6. Collegamento con error budget e revisione SLO/processi.

15) Metriche di maturità del processo

Percentuale di incidenti dichiarati prima delle lamentele degli utenti.
MTTA per livello SEC Tempo di connessione per il ruolo desiderato.
Rispetto degli intervalli degli update (Comm SLA).
La percentuale di incidenti risolti da playbook senza «creatività» manuale.
Esecuzione di action items da post mortem a tempo debito.

16) Anti-pattern

«Qualcuno faccia qualcosa» - nessun IC/ruolo.
Più voci nella war-room: discussione sulle versioni anziché sulle azioni.
La dichiarazione tardiva è una perdita di tempo per radunare le persone.
Nessuna freeze o annotazioni di rilascio - Le modifiche parallele mascherano il motivo.
La mancanza di comunicazione esterna è un'escalation di denunce/rischio PR.
Chiusura senza post mortem o azioni: ripetiamo gli stessi errori.

17) Assegno foglio IC (tessera da tasca)

• Assegnare la SEV e aprire la war-room.
• Assegna TL, CL, Scribe, controlla on-call sono presenti.
• Attiva la release-freeze (quando si esegue il SEV-1 +).
• Confermare le fonti di verità: dashboard SLI, sintetico, logi, trailing.
• Accetta azioni di mitigazione rapida (ritorno/flag/failover).
• Fornire aggiornamenti regolari come previsto.
• Fissa Criteria per la risoluzione e la sorveglianza dopo il ripristino.
• Avviare il post mortem e assegnare i proprietari di action items.

18) Incorporazione nelle operazioni giornaliere

Esercitazioni (game-days) - Simulazioni di script chiave.
Directory playbook versionata, testata, con parametri.
Gli strumenti sono i comandi ChatOps «/declare », «/page», «/status », «/rollback».
Integrazioni: ticketing, status page, post mortem, CMDB/directory di servizi.
Allineamento con SLO/Errore Budget: trigger di escalation automatica e regole freeze.

19) Totale

L'escalation è una disciplina, non solo una chiamata al responsabile. I chiari livelli di SEC assegnati a IC, le playbook pronte, i time box degli aggiornamenti e l'integrazione con le metriche SLO e le policy budget trasformano un incendio caotico in un processo gestito con esito prevedibile: ripristino rapido del servizio, rischio minimo PR/regolatore e miglioramenti di sistema dopo ogni incidente.