Playbook di incident response per team piccoli e medi

In breve: Quando il venerdì alle 23:30 cade il server di produzione, non è il momento di inventare la procedura da zero. Un playbook di incident response è un documento che definisce ruoli, comunicazione e procedure prima di averne bisogno. Ecco un playbook minimo adatto a team di 5-20 persone.

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, escala. Non scrive codice.
• Technical lead - la persona che conosce l'area problematica. Scrive la fix.
• Communications lead - aggiorna status page, clienti, management. Per piccolo team può essere lo stesso di IC.
• Scribe - scrive la timeline, chi fa cosa, quando. Cruciale per il post-mortem.

In team fino a 5 persone tipicamente IC + Technical lead = 2 ruoli divisi, gli altri li prende IC.

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 di feature, alcuni utenti). Reazione entro 30 min durante ore lavorative, entro 1 h fuori.
• SEV3 (Minor) - piccolo impatto, workaround esiste. Reazione entro il giorno lavorativo successivo.
• SEV4 (Cosmetic) - senza impatto user-facing, va in 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). 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 sapere.
4. 00:10 - Initial diagnostics. Controlla deploy recenti, grafici monitoring, error log. Cosa è cambiato negli ultimi 30-60 min?
5. 00:15 - Decisione: rollback, hotfix o workaround? Se non immediatamente chiaro, IC escala o chiama altri ingegneri.

Comunicazione: la regola "5 + 30"

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

Il primo update deve essere entro 5 minuti dal rilevamento. Indipendentemente dal fatto che tu conosca la causa.

Rollback come default

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

Per il rollback è necessario avere:

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

Post-mortem entro 48 ore

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

1. Summary - 2-3 frasi cosa è successo, quanto è durato, chi ha colpito
2. Timeline - tempi esatti di rilevamento, azioni chiave, risoluzione
3. Root cause - perché è successo (motivo tecnico + motivo procedurale)
4. Impact - numero di clienti colpiti, 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" - meglio "aggiungere test di integrazione per payment flow entro 14 giorni, owner: X")

Regola blameless post-mortem: Non cerchi un colpevole, cerchi 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 team con prodotto 24/7:

• Rotazioni settimanali - più breve brucia, più lungo significa continuità del contesto
• Sempre primario + secondario on-call. Secondario prende quando primario non reagisce entro 5 min.
• Compensazione (pagamento extra, time-off) per paging notturno e weekend
• "On-call review" mensile - chi è stato svegliato spesso, 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 →