Playbook di incident response per team piccoli e medi

Ruoli durante un incident

Ruoli chiari eliminano il caos. Anche un piccolo team ha bisogno almeno di:

• Incident Commander (IC) - gestisce l'incident, prende decisioni ed escala. Non scrive codice.
• Technical lead - la persona che conosce l'area problematica. Scrive la fix.
• Communications lead - aggiorna la status page, informa clienti e management. In un piccolo team può essere la stessa persona dell'IC.
• Scribe - tiene la timeline: chi fa cosa e quando. Una base cruciale per il post-mortem.

In un team fino a 5 persone si separano di solito l'IC e il Technical lead, e l'IC assume gli altri ruoli.

Livelli di severity

Definisci 3-4 livelli di gravità in anticipo:

• SEV1 (Critical) - servizio principale completamente non disponibile. Si reagisce immediatamente, paging anche di notte.
• SEV2 (Major) - degrado significativo (parte delle feature, alcuni utenti). Reazione entro 30 min durante le ore lavorative, entro 1 h al di fuori.
• SEV3 (Minor) - piccolo impatto, esiste un workaround. Reazione entro il giorno lavorativo successivo.
• SEV4 (Cosmetic) - senza impatto user-facing, va nella queue normale.

Procedura SEV1: i primi 15 minuti

1. 00:00 - Rilevamento. L'alert arriva dal monitoraggio o dal cliente. Qualcuno in rotazione on-call conferma che il problema è reale.
2. 00:02 - Attivazione IC. Si apre un canale di comunicazione dedicato (Slack #incident-N o Discord) e si chiama il Technical lead.
3. 00:05 - Primo status update. Sulla status page pubblica: "Investigating reports of [problema]." Email alle persone interne che dovrebbero saperlo.
4. 00:10 - Initial diagnostics. Controlla i deploy recenti, i grafici di monitoring e gli error log. Cosa è cambiato negli ultimi 30-60 min?
5. 00:15 - Decisione: rollback, hotfix o workaround? Se non è immediatamente chiaro, l'IC escala o chiama altri ingegneri.

Comunicazione: la regola "5 + 30"

Aggiorna la status page durante un SEV1 almeno ogni 30 minuti, anche se non hai info nuove. "Ancora in fase di indagine, ETA ancora sconosciuto" è un update migliore del silenzio - i clienti almeno sanno che qualcuno sta lavorando al problema.

Il primo update deve arrivare entro 5 minuti dal rilevamento, indipendentemente dal fatto che tu conosca già la causa.

Rollback come scelta predefinita

Per un SEV1 iniziato poco dopo un deploy, il rollback è la prima scelta, non un hotfix. Un hotfix scritto di notte sotto pressione è fonte di altri bug. Il rollback ripristina uno stato noto e funzionante e ti dà tempo per una diagnostica tranquilla al mattino.

Il rollback presuppone di avere:

• Versioning del deployment (tag Docker, tag Git, artefatto di deployment)
• Database migration backwards compatible (se la nuova versione droppa una colonna, la vecchia non la recupera)
• Procedura di rollback documentata (comandi, quanto dura, chi può eseguirla)

Post-mortem entro 48 ore

Dopo ogni incident SEV1/SEV2 scrivi un documento con questa struttura:

1. Summary - 2-3 frasi su cosa è successo, quanto è durato e chi ha colpito
2. Timeline - i tempi esatti di rilevamento, azioni chiave e risoluzione
3. Root cause - perché è successo (motivo tecnico e procedurale)
4. Impact - numero di clienti colpiti e impatto business
5. What went well - cosa abbiamo fatto bene (apprezzare il team)
6. What went wrong - dove abbiamo perso tempo
7. Action items - task concreti con owner e deadline (non "testare meglio", ma piuttosto "aggiungere un test di integrazione per il payment flow entro 14 giorni, owner: X")

Regola blameless post-mortem: Non cerchi un colpevole, ma una debolezza sistemica. "John ha deployato una cattiva versione" è la conclusione sbagliata - quella giusta è "il processo di deploy non conteneva una fase canary che avrebbe catturato il bug prima del rollout completo".

Rotazione on-call

Per un team con prodotto 24/7:

• Le rotazioni settimanali sono il giusto compromesso - quelle più brevi portano al burnout, quelle più lunghe sovraccaricano l'on-call primario
• Prevedi sempre un on-call primario + secondario. Il secondario subentra quando il primario non reagisce entro 5 min.
• Compensa il paging notturno e del weekend (maggiorazione o riposo compensativo)
• Introduci un "on-call review" mensile - chi è stato svegliato più spesso e cosa si può automatizzare

Strumenti

• Monitoring (ePulz.io, Datadog, New Relic) - rilevamento + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - escalation, rotazione, SMS/voce
• Status page (propria, ePulz.io, Statuspage.io) - comunicazione esterna
• Hosting runbook (Notion, GitHub Wiki, internal docs) - playbooks e runbooks
• Template postmortem (Confluence, Notion template) - standardizzazione

Conclusione

L'incident response non si può improvvisare sotto pressione. 30 minuti investiti nella scrittura di un playbook si ripagano al primo outage maggiore - meno caos, MTTR più breve, miglior comunicazione con i clienti e un team che sa cosa fare.

Inizia con rilevamento automatico

ePulz.io risolve i primi minuti dell'incident response: rilevamento + alerting via e-mail, Telegram e webhook verso Slack / Discord / PagerDuty.

Avvia monitoraggio →