Il postmortem di un incidente è una breve analisi scritta di un’interruzione del servizio: cosa è successo, che impatto ha avuto sugli utenti, perché è successo e cosa cambierai perché non si ripeta. Un postmortem blameless si concentra su sistemi e processi, non su chi ha commesso un errore. Il template di base ha sei parti: riepilogo, impatto, cronologia, causa principale, cosa è andato bene e cosa male, e azioni con responsabili e scadenze.
Di seguito trovi quando scriverne uno, i principi che lo rendono utile, un template completo da copiare, un esempio compilato e come trasformarlo in un riepilogo per i clienti.
Quando scrivere un postmortem
Non ogni piccolo intoppo richiede un documento. Stabilisci criteri chiari, così la decisione non si prende sotto pressione. I più comuni:
I clienti non hanno potuto usare una funzione fondamentale, come il checkout, il login o l’API, per più di qualche minuto.
Dei dati sono andati persi, sono stati danneggiati o esposti.
L’incidente ha consumato una parte consistente del tuo error budget mensile.
Clienti o committenti hanno segnalato il problema prima del monitoraggio.
Lo stesso tipo di incidente si è già verificato in passato.
Scrivilo entro pochi giorni lavorativi, finché ricordi e log sono freschi. Un postmortem scritto tre settimane dopo è in gran parte frutto di supposizioni.
I principi blameless
Un postmortem blameless parte dal presupposto che tutti abbiano agito in modo ragionevole con le informazioni che avevano in quel momento. Se una persona ha potuto mandare giù il sito con un solo comando, il problema è che un solo comando poteva mandare giù il sito. La ricerca del colpevole spinge le persone a nascondere i dettagli, e sono proprio i dettagli che ti servono.
Descrivi le azioni, non le persone. “Il job di importazione è stato avviato nelle ore di punta” invece di “Anna ha avviato l’importazione nel momento sbagliato”.
Chiediti “come”, non “chi”. Come ha fatto il sistema a permetterlo? Come ce ne siamo accorti? Come avremmo potuto accorgercene prima?
Cerca più cause. Raramente un incidente ha una sola causa principale. Di solito un fattore scatenante incontra un punto debole che una protezione mancante non ha intercettato.
Usa fatti e timestamp. Dati di monitoraggio, log e cronologia delle chat valgono più della memoria.
Tieni corto l’elenco delle azioni. Due o tre modifiche che vengono portate a termine valgono più di dieci che restano sulla carta.
Il template di postmortem
Copialo nel tuo wiki, nel repository o nello strumento che usi per i documenti. Ogni sezione indica cosa va inserito.
# Postmortem: [titolo breve]
Data dell’incidente: [AAAA-MM-GG]
Autore/i: [nomi]
Stato: [bozza / in revisione / definitivo]
Gravità: [es. SEV1 / SEV2 / SEV3]
## Riepilogo
[Due o tre frasi: cosa si è rotto, per quanto tempo e come è stato risolto.]
## Impatto
– Servizi e componenti coinvolti:
– Durata (dall’inizio al ripristino):
– Utenti o clienti coinvolti:
– Impatto sul business (ordini, registrazioni, SLA):
– Comunicazione ai clienti (pagina di stato, email, ticket):
## Rilevamento
– Come è stato rilevato l’incidente? (monitor, cliente, membro del team)
– Tempo dall’inizio all’avviso:
– Tempo dall’avviso alla presa in carico:
## Cronologia
[Tutti gli orari in un unico fuso orario. Una riga per evento.]
HH:MM evento
HH:MM evento
## Causa principale e fattori concomitanti
– Fattore scatenante:
– Causa di fondo:
– Perché le protezioni non l’hanno intercettato:
## Risoluzione
[Cosa è stato fatto per ripristinare il servizio, e da chi (ruolo, non colpa).]
## Cosa è andato bene
–
## Cosa è andato male
–
## Dove siamo stati fortunati
–
## Azioni
| Azione | Tipo (prevenire / rilevare / rispondere) | Responsabile | Scadenza | Ticket |
|——–|——————————————|————–|———-|——–|
| | | | | |
## Riepilogo per i clienti
[Versione breve per la pagina di stato o l’email ai clienti.]
La sezione “Dove siamo stati fortunati” è facile da saltare ed è spesso la più preziosa. Registra i casi sfiorati: l’incidente è avvenuto di notte, il backup era stato eseguito un’ora prima, l’unica persona che conosceva il sistema per caso era sveglia.
Un esempio compilato
Ecco il template applicato a un incidente immaginario in un negozio online, northwind.shop. I dettagli sono inventati a scopo illustrativo, ma la struttura è quella che dovrebbe avere un postmortem reale.
Riepilogo
Dalle 03:12 alle 03:19 CET, il checkout di northwind.shop ha restituito 503 Service Unavailable. Un’importazione notturna dei prodotti ha occupato tutti i worker PHP-FPM, quindi le richieste di checkout venivano rifiutate. Lo sviluppatore di reperibilità ha interrotto l’importazione e riavviato PHP-FPM. Downtime totale: 7 minuti.
Impatto
Checkout e carrello non sono stati disponibili per 7 minuti. Le pagine prodotto venivano servite dalla cache e sono rimaste online.
I log del server mostrano 23 richieste di checkout fallite in quell’intervallo (dato di esempio).
La pagina di stato ha mostrato “Checkout: interruzione grave” dalle 03:13. Non è arrivato alcun ticket al supporto.
Cronologia
03:00 Parte l’importazione notturna dei prodotti.
03:12 Il controllo di uptime su northwind.shop/checkout restituisce 503.
03:13 Un secondo controllo conferma l’errore. Si apre un incidente, lo sviluppatore di reperibilità riceve un avviso su Telegram e i dettagli vengono pubblicati nel canale Slack del team. La pagina di stato segna il Checkout come down.
03:15 Il reperibile prende in carico l’incidente su Slack e apre la dashboard del server. Memoria e CPU sono alte su web-01.
03:17 Lo stato di PHP-FPM mostra tutti i worker occupati con le richieste dell’importazione. Il job di importazione viene interrotto.
03:18 PHP-FPM viene riavviato.
03:19 I controlli tornano a passare. Parte una notifica di ripristino con un downtime totale di 7 minuti.
Causa principale e fattori concomitanti
Fattore scatenante: dopo un aggiornamento del catalogo, il feed del fornitore era tre volte più grande del solito.
Causa di fondo: l’importazione gira nello stesso pool PHP-FPM del negozio. Le importazioni di grandi dimensioni possono occupare tutti i worker.
Protezione mancante: l’importazione non ha un limite di richieste simultanee e non c’era alcun avviso sulla saturazione dei worker.
Per capire perché i worker esauriti si manifestano proprio con questo errore, leggi la nostra guida all’errore 503 Service Unavailable.
Cosa è andato bene, cosa male e dove siamo stati fortunati
Bene: il rilevamento ha richiesto un minuto e la presa in carico due. La pagina di stato si è aggiornata senza interventi manuali.
Male: ci sono voluti quattro minuti per trovare la causa, perché nulla collegava il job di importazione ai web server.
Fortuna: è successo alle 03:12, non durante il picco serale.
Azioni
AzioneTipoResponsabileScadenzaEseguire l’importazione in un pool di worker separato con un limite di concorrenzaPrevenireResponsabile backendEntro 2 settimaneInviare un avviso quando la memoria di web-01 resta sopra l’85%RilevareOpsQuesta settimanaAggiungere un heartbeat che segnali il termine dell’importazioneRilevareResponsabile backendQuesta settimanaAggiungere al monitor il runbook “503 sul checkout”RispondereTurno di reperibilitàQuesta settimana
Pubblicare un riepilogo per i clienti
Il postmortem interno è per il team. I clienti hanno bisogno di una versione più breve, senza nomi di server: cosa è successo, per quanto tempo, se i loro dati sono al sicuro e cosa stai cambiando. Pubblicala sulla tua pagina di stato e linkala da ogni email sull’incidente o aggiornamento ai clienti. In Uptimecheck scrivi l’analisi direttamente sull’incidente, accanto alla sua cronologia, e puoi scegliere di mostrarla sotto l’incidente sulla tua pagina di stato.
Checkout non disponibile, dalle 03:12 alle 03:19 CET
Tra le 03:12 e le 03:19 CET i clienti non hanno potuto completare gli
acquisti su northwind.shop. La navigazione dei prodotti non è stata
coinvolta e non sono andati persi ordini né dati di pagamento.
La causa è stata un aggiornamento programmato dei prodotti che ha usato
più capacità del server del previsto. Lo abbiamo interrotto e il
checkout è tornato operativo alle 03:19.
Stiamo spostando questi aggiornamenti su una capacità separata, così non
potranno più influire sul checkout, e abbiamo aggiunto avvisi anticipati
per questo tipo di carico.
Mantieni un tono fattuale e promesse concrete. “Prendiamo l’affidabilità sul serio” non dice nulla; “le importazioni ora girano su una capacità separata” dice qualcosa. La nostra guida su come creare una pagina di stato approfondisce come scrivere gli aggiornamenti sugli incidenti.
È utile anche sapere quante persone se ne sono accorte. Uptimecheck include le statistiche della pagina di stato con ogni pagina di stato, con le visite al giorno e per paese, referrer e dispositivo negli ultimi 30 giorni, così puoi aggiungere al postmortem quante persone hanno consultato la pagina il giorno dell’incidente. Insieme alla cronologia dell’incidente, hai inizio, avviso, presa in carico, ripristino e portata senza dover scavare nei log. Gli incidenti dei siti web riportano anche la risposta fallita, con uno screenshot o un traceroute, un ottimo punto di partenza per le sezioni sul rilevamento e sulla causa principale.
Tenere traccia delle azioni
Un postmortem senza azioni completate è un racconto, non una soluzione. Tratta le azioni come qualsiasi altro lavoro:
Crea un ticket per ogni azione nello stesso tracker che il team usa già e collegalo dal postmortem.
Assegna a ciascuna un unico responsabile e una scadenza.
Classifica le azioni per tipo: prevenire, rilevare o rispondere. Se ogni azione è “fare più attenzione”, l’analisi non è finita.
Rivedi le azioni aperte dei postmortem in una riunione periodica, per esempio ogni due settimane.
Segna il postmortem come definitivo solo quando tutte le azioni sono completate o esplicitamente scartate con una motivazione.
Col tempo, i postmortem stessi diventano dati. Conta quanti incidenti sono stati scoperti dal monitoraggio e quanti dai clienti, e segui i tempi di rilevamento e di risposta da un incidente all’altro. Il nostro articolo su MTTR, MTTA e MTBF spiega come calcolarli.
Condurre la riunione di analisi
Per gli incidenti più importanti è utile una riunione di 30-45 minuti. Condividi la bozza in anticipo, lascia che la persona che ha guidato la risposta ripercorra la cronologia e dedica la maggior parte del tempo ai fattori concomitanti e alle azioni. Un facilitatore neutrale, che non ha lavorato all’incidente, mantiene la discussione blameless e nei tempi. Chiudi confermando responsabili e scadenze per ogni azione.
Ottieni in automatico i timestamp per il tuo prossimo postmortem. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.