Modello di postmortem tecnico (senza colpe, orientato all'azione)

Perché i postmortem si trasformano in cacce alle colpe

I postmortem falliscono in un modo specifico: la sala inizia ad attribuire le cause prima di avere una cronologia condivisa. Qualcuno dice «il deploy ha causato questo» prima che l'orario del deployment sia confermato. Qualcun altro dice «l'alert non è scattato» senza sapere se l'alert fosse configurato per quello scenario. La conversazione diventa un dibattito sulla causalità prima che qualcuno abbia stabilito cosa sia effettivamente accaduto, e in quale ordine.

La soluzione è strutturale: costruite insieme la cronologia dell'incidente all'inizio del postmortem, prima che chiunque nomini una causa principale. Una volta che l'intera sala ha esaminato la sequenza degli eventi — cosa è cambiato e quando, chi ha visto cosa e a che ora — la causa è molto più facile da discutere e molto meno incline a collassare in una caccia alle colpe. Questo è l'errore di ordinamento che la maggior parte dei modelli commette: mettono la causa principale prima della cronologia perché la causa principale è ciò a cui il modello serve. Ma è la cronologia a rendere onesta la causa principale.

L'agenda (da copiare e incollare)

Durata: 60 minuti per un incidente semplice; 90 minuti per guasti complessi multi-sistema
Formato: Facilitata; presenti tutti i responder e l'ingegnere on-call; preparazione asincrona con un documento di lettura preliminare

Sezione 1 — Riepilogo dell'incidente (5 min)

Date e durata dell'incidente
Classificazione della gravità e sistemi interessati
Chi lo ha rilevato e come (segnalazione del cliente, alert, ingegnere, monitoraggio)
Questa sezione è solo fattuale; nessuna analisi ancora

Sezione 2 — Cronologia (20 min)

Costruite la cronologia in modo collaborativo a schermo — non un documento pre-scritto
Sequenza: cosa è cambiato, cosa è stato osservato, chi ha agito, cosa è stato deciso
Ogni timestamp dovrebbe avere una fonte (riga di log, PagerDuty, messaggio Slack)
Quando la cronologia è completa, chiedi: sono tutti d'accordo che sia andata così? Risolvi i disaccordi prima di proseguire

Sezione 3 — Riepilogo dell'impatto (5 min)

Impatto sui clienti: chi è stato coinvolto, per quanto tempo, in che modo
Impatto sul business: fatturato, SLA, reputazione
Impatto interno: ore di on-call, interruzione del team
Mantieni tutto fattuale; questo àncora la domanda «quanto è stato grave» senza editorializzare

Sezione 4 — Causa principale e fattori contribuenti (20 min)

Causa principale: il cambiamento o la condizione più prossimi che hanno reso possibile l'incidente
Fattori contribuenti: le condizioni che l'hanno peggiorato, reso più difficile da rilevare o più lento da risolvere
I postmortem più utili identificano 3-5 fattori contribuenti accanto alla causa principale; correggere solo la causa principale spesso trascura le condizioni sistemiche
Per ogni fattore chiedi: qualche individuo o team ha preso una decisione che sembrava ragionevole date le informazioni disponibili? Se sì, il fattore è sistemico, non personale

Sezione 5 — Cosa è andato bene (5 min)

Quale rilevamento o risposta ha funzionato meglio del previsto?
Quale processo o strumento esistente ha limitato il raggio d'azione del guasto?
Queste sono pratiche degne di essere formalizzate — se il runbook ha risparmiato 20 minuti, annotalo così il runbook viene mantenuto

Sezione 6 — Azioni (15 min)

Ogni azione affronta una causa principale o un fattore contribuente — non un miglioramento generico
Un responsabile per elemento; una data di consegna che rifletta l'urgenza
Categorizza: rilevare prima / recuperare più in fretta / prevenire il ripetersi
Limitati alle azioni che il team può realisticamente completare prima del prossimo incidente, non a una roadmap di affidabilità completa

Cosa fa fallire i modelli di postmortem

L'ordinamento con la causa principale per prima è il principale problema strutturale — già trattato sopra. Il secondo è trattare le «azioni» come un'unica categoria. I miglioramenti al rilevamento, al recupero e alla prevenzione richiedono responsabili diversi e tempistiche diverse. Mescolarli produce una lista che si estende su sei mesi e tre team, il che significa che la responsabilità si diffonde e nessuna di esse viene consegnata.

La terza modalità di fallimento è saltare «cosa è andato bene» perché sembra un ottimismo inopportuno dopo un incidente. Non lo è — è l'unico modo sistematico per identificare e formalizzare pratiche che hanno funzionato sotto pressione. Se il monitoraggio che ha intercettato il problema non era nella roadmap di costruzione di nessuno, scoprire che è stato determinante vale la pena di essere documentato. Altrimenti viene deprioritizzato dopo che l'incidente sbiadisce e la volta successiva sarai cieco.

Il costo accumulato degli incidenti in cui i fattori contribuenti restano non affrontati, e dei runbook che hanno funzionato ma non vengono mantenuti, si somma in fretta. La tassa delle riunioni spiega come l'onere delle riunioni ricorrenti e il debito delle revisioni di incidente interagiscano.

Perché la cattura del postmortem è particolarmente difficile

Le discussioni di postmortem generano rapidamente contenuto denso e non strutturato: ricostruzione della cronologia, interpretazioni contrastanti, assegnazioni di azioni tra più persone, dettagli tecnici che senza contesto non avrebbero senso in una trascrizione. Un riepilogo di postmortem scritto a memoria o da un audio montato è quasi sempre incompleto, e i resoconti di postmortem incompleti sono inutili per il riconoscimento di pattern tra gli incidenti.

Pavleur cattura l'intera discussione del postmortem e genera il report automaticamente — la cronologia così come ricostruita, i fattori contribuenti così come nominati, le azioni con responsabili e categorie così come dichiarati durante la riunione. Se qualcuno ha condiviso lo schermo per mostrare un estratto di log, un grafico di monitoraggio o la configurazione dell'alert che non è scattato, quell'elemento visivo fa parte del report. Gli strumenti solo-audio lo trascurano del tutto; un resoconto di postmortem senza i grafici è un resoconto senza le prove. Chiunque nel team — inclusi gli ingegneri che si uniscono dopo l'incidente — può leggere il resoconto completo, con il contesto visivo incluso, senza chiedere a qualcuno di ricostruirlo. Per un confronto diretto con altri strumenti su questo punto: Pavleur vs. alternative.

Sulla cadenza del postmortem

Fai il postmortem entro 48 ore dalla risoluzione dell'incidente, mentre i dettagli sono freschi. Più aspetti, più la ricostruzione della cronologia dipende dalla memoria anziché dai log, e la memoria è inaffidabile sotto stress. Per gli incidenti ad alta gravità, 24 ore sono meglio. Per gli incidenti minori, i postmortem asincroni — un documento condiviso con domande strutturate, rivisto in modo sincrono — possono essere più efficienti di una riunione completa. Il formato riunione è più prezioso quando l'incidente è stato abbastanza ambiguo o ad alto rischio da rendere importante un'interpretazione condivisa.