Cosa fare se qualcosa va storto in produzione

Incidenti accadono. Prima o poi, anche con tutte le precauzioni. La differenza fra incidente che dura 30 minuti e incidente che dura 8 ore è la procedura preparata in anticipo. Improvvisare sotto pressione produce decisioni sbagliate. Avere checklist riduce panico e azione errata.

Avvertenza importante: durante un incidente, ogni azione distruttiva (rollback database, reset cache condivisa, revoca chiavi) richiede massima attenzione. Verifica sempre due volte cosa stai per fare. Mai sotto pressione fare azioni che non hai mai testato.

Perché questa lezione conta

Sotto pressione, processi cognitivi si degradano. Un dev calmo conosce esattamente cosa fare. Lo stesso dev sotto pressione, alle 23 di domenica, dimentica step e fa scelte rischiose. Una procedura scritta — anche di una pagina — è la differenza fra “incidente gestito” e “incidente moltiplicato”.

Obiettivo operativo

Alla fine devi saper:

1. fare triaging di un incidente in 5 minuti;
2. eseguire azioni immediate corrette (rollback, disable, comunicazione);
3. condurre post-mortem leggero che produce miglioramenti reali.

Nucleo della lezione

1. Triaging (primi 5 minuti)

Cinque domande, in ordine:

Impatto: chi è colpito? Tutti gli utenti, sottoinsieme, solo nuovi, solo specifico tier?

Severità: down completo? Funzionalità degradata? Bug grave ma non bloccante? Visibile / invisibile?

Dati a rischio: corruzione? Perdita? Esposizione (data leak)? Modifiche errate?

Trigger: ultimo deploy? Cambio config? Errore servizio esterno? Carico anomalo? Causa nota o ignota?

Container: si propaga? Stabile? Peggiora?

Risposte → priorità delle azioni successive.

Severità tipiche:

• Sev1 (critico): down completo, leak dati, utenti non possono operare. Rispondi subito.
• Sev2 (alto): funzionalità chiave rotta, ma sistema gira. Risposta entro 1 ora.
• Sev3 (medio): bug visibile ma non bloccante. Risposta entro giorno lavorativo.
• Sev4 (basso): bug minore. In coda con altre task.

2. Azioni immediate

Ordine tipico per Sev1/Sev2:

1. Stabilizza (stop the bleeding):

• rollback al deploy precedente se causa è recente;
• disabilita feature flag se applicabile;
• attiva modalità manutenzione se serve fermare scrittura;
• isola sistema problematico se contagia altri.

Obiettivo: portare sistema a stato noto stabile, anche se degradato. Diagnosi viene dopo.

2. Preserva evidenze:

• screenshot di errori, dashboard;
• log in cartella separata (potrebbero essere ruotati);
• copia di stato DB se sospetto corruzione;
• timestamp di tutti gli eventi noti.

Niente di tutto questo se accidentalmente cancellato non si recupera.

3. Comunica:

• internamente (team, stakeholder);
• esternamente se utenti coinvolti (status page, email, social);
• formato: cosa è successo, cosa stiamo facendo, prossimo aggiornamento entro X.

Comunicazione regolare anche se non c’è progresso (“stiamo investigando, prossimo update fra 30 min”).

4. Mitiga effetti:

• rotazione segreti se compromessi;
• email a utenti se necessario (modifica password forzata, ecc.);
• credito/rimborso se applicabile.

5. Diagnosi vera:

• solo dopo stabilizzazione;
• con calma, basata su evidenze;
• root cause analysis prima del fix permanente.

6. Fix definitivo + test di regressione:

• non in produzione di emergenza ma in branch dedicato;
• review più rigoroso del solito;
• test che riproduce l’incidente nel senso opposto (regression contro causa).

3. Post-mortem leggero

Dopo che l’incidente è risolto, post-mortem in 1-2 giorni. Non serve cerimonia: 30 minuti, struttura fissa.

Cosa è successo: timeline degli eventi (timestamp UTC). Quando bug introdotto, quando rilevato, quando mitigato, quando risolto.

Impatto reale: utenti coinvolti, durata, danni misurabili (richieste fallite, transazioni perse, dati corrotti).

Causa diretta: cosa ha rotto immediatamente. Bug nel codice X, errore config Y.

Causa profonda (5 perché):

1. perché c’è stato bug? → mancava test specifico
2. perché mancava test? → caso non considerato in scrittura
3. perché caso non considerato? → review non l’ha catturato
4. perché review non l’ha catturato? → reviewer non aveva contesto X
5. perché non aveva contesto? → processo onboarding incompleto

Causa profonda spesso non è “il dev ha sbagliato” ma “il sistema non ha catturato l’errore”.

Cosa è andato bene: la rilevazione è stata rapida? Comunicazione efficace? Rollback funzionato?

Cosa è andato male: ritardo nel rilevare? Decisioni rischiose sotto pressione? Comunicazione confusa?

Azioni: 3-5 azioni concrete, ognuna con responsabile e scadenza.

• “Aggiungere test per caso X” → entro venerdì.
• “Aggiornare AGENTS.md con vincolo Y” → oggi.
• “Setup alert su metric Z” → settimana prossima.

Senza azioni, il post-mortem è teatro.

Procedura pratica

Avere documentato (anche solo per te):

1. Numero/canale di emergenza: dove vengono raccontati gli incidenti.
2. Lista contatti: provider hosting, DBA, security expert.
3. Documenti operativi: rollback procedure, restore DB, key rotation.
4. Checklist incident: 6 step di sezione 2, scritti.
5. Template post-mortem: file vuoto pronto da copiare.

Quando incidente accade:

1. Leggi checklist (anche se “lo ricordi”, in stress dimentichi).
2. Esegui passi in ordine.
3. Annota timeline man mano (utile per post-mortem).
4. Comunica a intervalli regolari.
5. Stop quando sistema stabile.
6. Post-mortem entro 2 giorni.

Laboratorio guidato

Simula incidente: “API key Stripe esposta in commit pubblico, scoperta 1 ora dopo push”.

Triaging:

• Impatto: utenti che fanno pagamenti potenzialmente esposti se attaccante usa la chiave.
• Severità: Sev1.
• Dati a rischio: pagamenti, dati clienti Stripe.
• Trigger: push commit dell’ultima ora.
• Container: Stripe dashboard può mostrare attività anomala.

Azioni immediate:

1. Vai su Stripe dashboard → revoca chiave esposta. Subito.
2. Genera nuova chiave Stripe.
3. Aggiorna in pannello hosting (Vercel env).
4. Trigger redeploy.
5. Verifica funzionamento: test pagamento.

Preserva evidenze:

• screenshot Stripe dashboard prima e dopo.
• log Vercel del redeploy.
• nota timeline.

Comunica:

• internamente: Slack #incidents.
• esternamente: solo se ci sono indizi di abuso (transazioni anomale).

Mitiga:

• monitora Stripe per 7 giorni: transazioni inusuali.
• considera notifica utenti se evidenza di abuso.

Diagnosi:

• come è entrata la chiave in repo? .env non gitignored? push accidentale?
• preventivo: pre-commit hook gitleaks attivato?

Fix definitivo:

• gitleaks installato.
• .env aggiunto a .gitignore (se assente).
• chiave eliminata dalla storia git con git filter-repo (anche se la rotazione l’ha già neutralizzata).

Post-mortem:

INCIDENT: Stripe key in commit pubblico

Timeline:
14:30 — push commit con .env
15:30 — gitleaks scanner segnala (community)
15:35 — chiave revocata su Stripe
15:40 — nuova chiave attiva in produzione
15:50 — verifica nessun pagamento sospetto

Impact: 1h 10min finestra di esposizione. Nessun abuso rilevato.

Causa diretta: .env commitato.

Causa profonda: 
- .gitignore mancava .env (5 perché): repo nuova, copy/paste AGENTS.md from progetto vecchio, .gitignore di quello non aveva .env, errore propagato.

Bene: rilevazione rapida, rotazione veloce.
Male: niente protezione preventiva (gitleaks).

Azioni:
- [ ] Aggiungere gitleaks a tutti i progetti — entro venerdì
- [ ] Aggiornare template repo con .gitignore completo — oggi
- [ ] Documentare procedura rotazione segreti — settimana prossima

Ora hai procedura. Funziona perché scritta a freddo, non a caldo.

Output atteso

Documento docs/incident-response.md per il tuo progetto:

• contatti emergenza;
• procedura rollback (specifica per piattaforma);
• procedura key rotation;
• template post-mortem;
• checklist immediate actions.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: prepararsi agli incidenti con lucidità, senza improvvisare mentre utenti e dati sono coinvolti. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Triaging: capire impatto, utenti coinvolti, dati a rischio, ultimo deploy, log e sistemi esterni.
• Azioni immediate: rollback, disabilitazione feature, rotazione segreti, comunicazione, preservare evidenze.
• Post-mortem leggero: causa, segnali mancati, fix, test di regressione, cambiamenti di processo.

3. Applicazione: svolgi il laboratorio: simulare un incidente: API key esposta o bug che cancella dati, e scrivere il piano di risposta. L’output da ottenere è: una procedura incident response adatta a piccoli progetti e prototipi pubblici.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho un piano scritto, anche minimo;
• conosco procedura rollback della mia piattaforma;
• ho fatto almeno una simulazione (anche solo mentale);
• ho lista contatti emergenza;
• post-mortem template pronto.

Errori comuni

Niente piano scritto. “Lo gestisco quando succede”. Sotto pressione, peggiore.

Saltare comunicazione. Utenti scoprono soli, fiducia persa.

Andare a fix definitivo subito. Senza stabilizzare prima, deploy di emergenza introduce nuovi bug.

Distruggere evidenze. “Pulisco i log”. Causa irrintracciabile dopo.

Niente post-mortem. Stessa categoria di incidente fra 3 mesi.

Post-mortem senza azioni concrete. “Useremo più cura”. Vacuo. Servono task con responsabile e scadenza.

Auto-incolparsi / incolpare team. Causa spesso è sistemica. Cambia il sistema, non punisci la persona.

Prompt di lavoro

Genera piano di incident response per la mia app: [descrizione]

Stack: [...]
Hosting: [...]
Tipo dati: [...]
Team: [solo io / piccolo / grande]

Voglio:

1. Lista incidenti tipici per il mio stack (5-7 scenari): cosa potrebbe rompersi.

2. Per ogni scenario:
   - severità tipica
   - azioni immediate (5-6 step in ordine)
   - chi/cosa contattare
   - tempo target di risoluzione

3. Template post-mortem riusabile.

4. Procedura rollback specifica per la mia piattaforma.

5. Procedura rotazione segreti.

6. Lista pre-built di "comandi salvavita" (script o comandi shell che eseguono azioni rapide tipo disable feature flag, scale up, isolate service).

Output: documento operativo pronto da copiare in docs/incident.md. Pratico, non teorico.

Esercizio finale

Esegui simulazione incident sul tuo progetto: “il deploy di oggi ha rotto il login per tutti gli utenti”. Senza fare niente in realtà, scrivi cosa faresti, in ordine, con timestamp. Quanto tempo a stabilizzare? Avresti tutti i contatti? Procedure documentate? Tipicamente la simulazione rivela 2-3 cose mancanti. Documentale prima del prossimo incidente vero.