Registrare i post-mortem degli incidenti: trasformare i guasti in sapere condiviso

Ogni team scrive un documento di post-mortem dopo un disservizio. Molti meno lo leggono. Una timeline ben scritta, piena di link a dashboard e frammenti di log, chiede a chi legge di ricostruire l’incidente nella propria testa: la maggior parte scorre, annuisce e passa oltre.

Una breve registrazione dello schermo cambia le carte in tavola. Invece di descrivere com’era il grafico degli errori alle 02:14, lo mostri. Invece di spiegare quale query ha fatto emergere la causa radice, la esegui. In questa guida vedrai come registrare post-mortem che vengono davvero guardati e come mantenerli utili anche mesi dopo.

Perché registrare un post-mortem

• Le prove battono le descrizioni: grafici, trace e log sono visivi per natura — gli screenshot perdono il movimento prima/dopo che rende evidente un picco
• Più rapido da produrre: commentare ciò che hai già aperto richiede meno tempo che scrivere un testo curato
• Ideale per chi è appena arrivato: sei minuti di riepilogo fanno capire i modi di guasto del sistema molto più in fretta di una pagina wiki
• Conserva il ragionamento: i documenti registrano cosa è successo, i video catturano perché chi era di turno ha pensato quello che ha pensato a ogni passo
• Adatto all’asincrono: i team distribuiti assorbono la review senza fissare un’altra riunione tra fusi orari

Cosa registrare — e cosa no

Un post-mortem registrato non è la replica dell’intero incidente. Tieni solo le parti in cui vedere vale più che leggere:

Registra questo:

• Il momento della rilevazione: l’alert, la dashboard, la prima segnalazione degli utenti
• Il grafico chiave che mostra l’impatto nella finestra dell’incidente
• I passaggi di indagine che hanno ristretto il campo (vicoli ciechi compresi)
• Il codice, la configurazione o la query esatta che ha causato il guasto
• L’applicazione del fix e il recupero delle metriche

Salta questo:

• Le lunghe attese per deploy o caricamento dei dati
• Le conversazioni interne non legate alla diagnosi
• Tutto ciò che puoi dire in una frase di commento

Prepararsi prima di premere Registra

Gli strumenti di incident response mostrano molte cose che non vuoi in un video condiviso. Dedica cinque minuti:

1. Apri tutte le schede in anticipo: dashboard sull’intervallo corretto, query dei log, pull request, alert
2. Fissa gli intervalli temporali: blocca le dashboard sulla finestra dell’incidente perché tutti vedano quello che vedi tu
3. Chiudi le superfici sensibili: anagrafiche clienti, ticket interni con dati personali, messaggi privati, gestori di credenziali
4. Silenzia le notifiche: nulla svilisce un post-mortem serio come un promemoria per il pranzo in piena narrazione
5. Scrivi una scaletta di tre righe: impatto, causa radice, prevenzione. Tutto il resto discende da questi tre punti

Usa la cattura finestra invece dello schermo intero quando la dashboard sta in un’unica finestra del browser: è il modo più semplice per garantire che nient’altro finisca nell’inquadratura.

Una struttura che funziona

Mantieni la registrazione tra i cinque e i dieci minuti. Una struttura affidabile:

1. Prima l’impatto (30 secondi): chi è stato colpito, per quanto tempo e quanto gravemente. Parti da qui, è ciò per cui la maggior parte guarda
2. Percorso della timeline (2–3 minuti): rilevazione, escalation, mitigazione, risoluzione, mostrati sulla dashboard reale
3. Causa radice (2–3 minuti): mostra il percorso di codice, la modifica di configurazione o la query reali. Zooma sulle righe specifiche
4. Cosa ha reso tutto difficile (1 minuto): alert mancanti, log confusi, responsabilità poco chiare — proprio ciò che i documenti tendono ad appiattire
5. Azioni (1 minuto): enuncia ogni azione con il responsabile, poi collegale nella descrizione

Usare l’editor per renderlo leggibile

Il materiale grezzo di un incidente è denso. L’editor di Recorded lo rende seguibile:

• Effetti di zoom: dashboard e righe di log sono piccole. Ingrandisci il picco, il messaggio d’errore, il diff incriminato — nessuno deve strizzare gli occhi
• Regioni di velocità: accelera le pipeline di deploy e l’esecuzione delle query, torna a velocità normale nel momento in cui emerge la causa
• Sovrapposizioni di testo: applica i timestamp (02:14 UTC — primo alert) così il video si allinea al documento
• Taglio: elimina la falsa partenza in cui ti sei accorto che la dashboard era sull’intervallo sbagliato
• Effetti del cursore: evidenzia i clic quando mostri il percorso esatto di riproduzione

Usa la webcam solo in apertura e chiusura. Un volto aiuta a dare il tono su impatto e azioni; durante l’analisi dei log copre soltanto il terminale.

Restare senza colpe davanti alla telecamera

Il video trasmette il tono in un modo che il testo non ha. La stessa frase suona come analisi o come accusa a seconda di come viene detta.

• Di’ «il deploy ha introdotto» invece di nominare chi l’ha rilasciato
• Racconta le decisioni nel contesto disponibile allora: «a questo punto non avevamo ancora la metrica della profondità della coda»
• Mostra i vicoli ciechi senza scusarti: provano che il sistema era difficile da diagnosticare, e questo è già un’azione da intraprendere
• Rifai l’introduzione se la prima take suona irritata. Bastano due minuti e danno il tono a chiunque guarderà

Abbinare video e documento

La registrazione integra il documento di post-mortem, non lo sostituisce. I documenti si cercano, si linkano e si scorrono; il video no.

Un buon abbinamento:

• Il documento resta la fonte di verità per timeline, azioni e responsabili
• La registrazione è incorporata in cima, con una riga che riassume cosa copre
• I timestamp dei capitoli nella descrizione portano dritti alla sezione sulla causa radice
• Le azioni vivono nel tuo tracker, non solo nel video

Costruire una libreria di incidenti

Le singole registrazioni sono utili. Una raccolta lo è molto di più.

• Nomina in modo coerente: 2026-09-28-checkout-latency-postmortem si ordina e si cerca senza problemi
• Tagga per sistema: raggruppa per servizio coinvolto, così puoi consegnare in blocco tutto ciò che riguarda un componente a chi entra in reperibilità
• Rivedi ogni trimestre: guardare di fila le registrazioni del trimestre fa emergere subito i guasti ricorrenti
• Usale nell’onboarding: tre o quattro incidenti selezionati sono il modo più rapido per insegnare come si rompe davvero il tuo sistema

Errori comuni

• Registrare durante l’incidente: prima la mitigazione. La review si registra dopo, quando puoi parlare con calma
• Condividere il materiale grezzo: 40 minuti di schermo condiviso senza montaggio non sono un post-mortem, nessuno li guarda
• Divulgare dati dei clienti: guarda sempre la registrazione una volta prima di condividerla, cercando dati personali in log e dashboard
• Saltare il riepilogo di impatto: chi guarda solo il primo minuto deve comunque portarsi a casa i fatti principali
• Lasciare che sostituisca il documento: tra sei mesi, quando inizierà un incidente simile, in un video non si può cercare

Conclusione

I post-mortem falliscono quando sono scritti per essere archiviati invece che compresi. Una registrazione mirata — impatto in apertura, prove reali sullo schermo, narrazione senza colpe, azioni chiare — trasforma ogni guasto in qualcosa che l’intero team può imparare in dieci minuti.

Registra il prossimo post-mortem invece di limitarti a scriverlo e osserva quante più persone se ne occupano davvero.