Incidenti, comunicazione e postmortem

In parole semplici

Quando un bug raggiunge la produzione, debug e processo cambiano. Cinque priorità in ordine, non negoziabili:

1. Contenere: limitare l’impatto sugli utenti.
2. Comunicare: chi è colpito? chi è coinvolto?
3. Decidere: rollback o fix-forward?
4. Verificare: il contenimento ha funzionato?
5. Documentare: postmortem per imparare.

Questa lezione integra il modulo 5 (revert/fix-forward) e il modulo 6 (blameless postmortem) in una sequenza operativa per gestire incidenti.

Parole nuove

• incidente: malfunzionamento che colpisce utenti reali in produzione.
• war room: spazio (fisico o virtuale) dove si coordina la risoluzione.
• incident commander: persona che coordina, non scrive codice.
• status page: pagina pubblica dello stato del servizio.
• MTTR (Mean Time To Recovery): tempo medio di recupero.

Cosa impari

• Applicare le cinque priorità in sequenza.
• Coordinare una war room.
• Scegliere tra rollback e fix-forward.
• Aggiornare utenti via status page.

Le cinque priorità

1. Contenere

L’obiettivo dei primi 10 minuti non è capire. È fermare l’emorragia.

Strumenti di contenimento:

• Rollback del deploy (modulo 5.4).
• Kill switch / feature flag (modulo 4.2).
• Rate limit d’emergenza.
• Failover a backup.
• Bypass della funzionalità rotta.

Domanda chiave: “qual è la cosa più veloce che riduce l’impatto, anche se non risolve?”

2. Comunicare

Mentre uno contiene, un altro:

• Avvisa il team interno (Slack #incidents).
• Aggiorna status page pubblica.
• Notifica stakeholder (CTO, customer success).
• Tiene aggiornato il canale ogni 15-30 minuti.

Pattern di status page:

🟡 Investigating: Stiamo investigando segnalazioni di lentezza sul checkout.
🟠 Identified: Causa identificata, in corso di mitigazione.
🟢 Monitoring: Mitigazione applicata, monitorando.
✅ Resolved: Incidente risolto.

Frasi neutre, niente promesse di tempi precisi.

3. Decidere

Davanti al bug, davanti al contenimento, davanti agli utenti che aspettano: rollback o fix-forward?

Rollback se:

• Il commit colpevole è identificato.
• Il rollback non richiede migrazioni inverse rischiose.
• L’ultima versione stabile è “recente abbastanza”.

Fix-forward se:

• Il fix è banale e veloce (5 minuti).
• Rollback è impossibile (migrazione DB irreversibile, dati corrotti).
• La versione precedente ha altri bug critici.

Decisione presa da incident commander dopo consulto. Documentata sul canale.

4. Verificare

Mitigazione applicata != incidente risolto. Verifiche:

• Metriche tornano in range normale.
• Log non mostrano più l’errore.
• Test smoke manuali OK.
• Utenti reali confermano (se possibile).

Solo dopo: dichiara “Monitoring” e poi, dopo 15-30 minuti senza ricadute, “Resolved”.

5. Documentare

Postmortem blameless (modulo 6.5):

• Timeline.
• Causa diretta e radice.
• Cosa è andato bene/male.
• Azioni correttive con owner.
• Lezione condivisa.

Da scrivere entro 24-48 ore, quando i ricordi sono freschi.

Incident commander: il ruolo

Funzioni:

• Non scrive codice.
• Coordina chi fa cosa.
• Prende decisioni (rollback vs fix-forward).
• Comunica con stakeholder.
• Tiene la timeline.

Una persona sola. Anche per incidente piccolo. Senza commander unico, decisioni contraddittorie e confusione.

War room

In remoto: video call sempre aperta, condivisione schermo, chat parallela per appunti.

Regole:

• No multitasking: chi è in war room non fa altro.
• Speaker unico: una persona alla volta.
• Incident commander parla per ultimo: ascolta le info, decide.
• Timer di sincronizzazione ogni 15 min: sintesi dello stato.

Status page: tono e contenuto

Buono:

“Identificate richieste fallite sul checkout. Stiamo applicando una mitigazione. Aggiornamento alle 14:45.”

Cattivo:

“Stiamo lavorando sul problema, scusate per l’inconveniente! Sarà tutto risolto in pochi minuti :)”

Differenze:

• Specifico vs vago.
• Senza promesse irrealistiche.
• Niente colpe (“colpa di X”).
• Niente toni eccessivamente leggeri.

MTTR e metriche di incident

Per ogni incidente registra:

• MTTD (detect): da inizio bug a primo allarme.
• MTTA (acknowledge): da allarme a presa in carico.
• MTTR (resolve): da inizio bug a risoluzione completa.

Aggregati nel tempo permettono di vedere se stai migliorando.

Sicurezza vs disponibilità

Per incidenti di sicurezza (data leak, vulnerabilità sfruttata):

• Coinvolgi subito il responsabile sicurezza/legale.
• Non comunicare pubblicamente dettagli prima di avere il quadro.
• Conserva log e evidenze (forensics).
• Postmortem ha sezione “esposizione dati” specifica.

Esercizio guidato

Simulazione (anche da soli, scrivendo):

1. Scenario: API /checkout ritorna 500 al 30% delle richieste da 5 minuti.
2. Scrivi la sequenza delle prime 30 minuti: chi fa cosa, in che ordine.
3. Scrivi tre messaggi di status page (Investigating, Identified, Resolved).
4. Decidi: rollback o fix-forward? Motiva.
5. Dopo 24h, scrivi il postmortem (anche se finta).

Errori frequenti del principiante

• Mettere “capire” prima di “contenere”. Gli utenti continuano a soffrire mentre si indaga.
• Nessun commander. Decisioni multiple, contraddittorie.
• Status page in ritardo o troppo ottimistica.
• Saltare il postmortem. Lo stesso bug ricorre.
• Cercare colpevoli. Riduce la trasparenza nelle prossime indagini.