Postmortem Che Cambiano Davvero Qualcosa

Un postmortem è facile da convocare e difficile da rendere utile. La riunione si tiene, viene scritto un documento, si annotano quattro azioni, e sei mesi dopo lo stesso guasto si ripresenta mentre qualcuno ritrova quel vecchio documento cercando tutt’altro.

La parola senza colpe raccoglie quasi tutta l’attenzione in queste discussioni, ed è davvero importante, ma non è lì che sta il fallimento. Molte organizzazioni conducono revisioni scrupolosamente senza colpe che non cambiano nulla, perché la revisione è stata trattata come il risultato invece che come la cosa che un risultato lo produce.

Il test per capire se le vostre funzionano è imbarazzante nella sua semplicità: quale percentuale delle azioni degli ultimi sei mesi è stata completata? Se la risposta è la maggior parte, il processo funziona, comunque sia fatto. Se è sotto la metà, state tenendo riunioni invece di condurre un processo, e modelli migliori non lo risolveranno. Poche azioni, con un responsabile e una data, battono un elenco completo per cui nessuno ha tempo.

A cosa serve davvero un postmortem

Non a spiegare cosa è successo. Chi era nella stanza di solito lo sa già prima che l’incidente si chiuda.

Esiste per trovare le condizioni che hanno permesso a un problema piccolo di diventare grande, e per cambiarne qualcuna. È una domanda diversa da cosa si è rotto, e la distinzione si vede subito nella stesura. “Il database ha esaurito le connessioni” è cosa si è rotto. “Nessun allarme scattava sulla saturazione del pool di connessioni, e la dashboard che l’avrebbe mostrata non è nel runbook della reperibilità” è una condizione, e su una condizione si può agire.

La seconda cosa che produce, molto sottovalutata, è un racconto condiviso dell’evento. Senza, ognuno tiene la propria versione, e quelle versioni derivano verso ciò che ciascuno già credeva del sistema. Un anno dopo due squadre litigano su un incidente che hanno vissuto insieme.

Senza colpe significa qualcosa di preciso

Non significa che nessuno abbia sbagliato. Significa che l’analisi assume che una persona, agendo in modo ragionevole con le informazioni disponibili, abbia compiuto un’azione rivelatasi sbagliata, e chiede perché quell’azione sembrasse corretta in quel momento. Il libro SRE di Google descrive questa pratica e le modalità di fallimento che la accompagnano.

Il motivo per cui non è solo gentilezza è che la colpa distrugge informazione. In un’organizzazione dove gli incidenti restano attaccati alle persone, la gente descrive gli eventi con cautela, omette il dettaglio che la mette in cattiva luce e ritarda la segnalazione finché non ha capito abbastanza da presentarla in sicurezza. La revisione lavora allora su un racconto ritoccato per autodifesa, che è il peggior input possibile.

In pratica, senza colpe è una proprietà del linguaggio. “Perché hai riavviato il servizio?” invita a difendersi. “Cosa mostrava la dashboard quando hai deciso di riavviare?” invita a fornire informazione. La seconda domanda è anche la più utile, perché la risposta è un fatto sul vostro monitoraggio e non su un collega.

Se esiste un vero problema di rendimento individuale, affrontatelo separatamente e in modo diretto. Farlo dentro la revisione dell’incidente corrompe la revisione ed è comunque un pessimo modo di avere quella conversazione.

Costruire una cronologia che insegna

La cronologia è la parte più preziosa del documento e quella scritta male più spesso, come sequenza di eventi tecnici da cui le persone sono state rimosse.

Annotate cosa sapevano le persone e quando. Non solo “il servizio è stato riavviato alle 14:32”, ma cosa poteva vedere quella persona alle 14:32 e cosa credeva stesse accadendo. È lì che sta il materiale su cui agire, perché un ritardo di quindici minuti causato da una dashboard ambigua è un problema risolvibile, mentre un ritardo di quindici minuti registrato come un buco non lo è.

Segnate i momenti che hanno contato: quando è iniziato, quando qualcuno se ne è accorto per la prima volta, quando è stata coinvolta la persona giusta, quando la causa è stata capita, quando è stato mitigato, quando è stato risolto. Negli intervalli fra questi momenti vive il miglioramento, e il tempo di rilevamento è molto spesso il più ampio.

Scrivetela finché è fresca, idealmente entro un giorno o due. Il ricordo di ciò che qualcuno credeva in un certo istante svanisce molto più in fretta del ricordo di ciò che è accaduto.

Raramente esiste una sola causa radice

L’espressione spinge a fermarsi alla prima spiegazione plausibile, mentre gli incidenti di qualsiasi dimensione sono catene in cui più cose dovevano valere contemporaneamente.

Una revisione utile elenca invece i fattori contribuenti: la modifica che ha innescato tutto, il test che l’avrebbe intercettata e che non esisteva, l’allarme finito su un canale che nessuno guarda, il runbook accurato per un’architettura precedente. Ognuno è un’opportunità a sé, e potete correggere i due più economici invece di quello che si trovava per caso all’inizio della catena.

Questo riduce anche una distorsione comune. Quando una revisione nomina una sola causa radice, quella causa è molto spesso “errore umano”, che è una descrizione e non una spiegazione, e che chiude l’indagine esattamente dove sarebbe dovuta cominciare.

Fare in modo che il follow up avvenga

Qui i postmortem vivono o muoiono, e i rimedi non hanno nulla di affascinante.

Meno azioni. Due che vengono fatte battono otto che restano ferme. Ordinatele per quanto riducono tempo di rilevamento, raggio d’impatto o probabilità, e tagliate il resto.

Un responsabile con nome e una data, nel vostro tracker di lavoro abituale e non nel documento. Le azioni che vivono solo nel postmortem sono invisibili durante la pianificazione, cioè quando il lavoro viene davvero programmato.

Rivedete le azioni aperte al postmortem successivo. Questa singola abitudine vale più di qualsiasi modello. Rende visibile ciò che non è stato fatto e trasforma una serie di riunioni scollegate in un processo.

Accettate alcune azioni con onestà. Una squadra che completa metà di ciò che promette dovrebbe promettere la metà. Registrare un’intenzione che nessuno finanzierà è peggio che registrare la decisione di non agire, perché la seconda almeno è vera.

I miglioramenti che ne escono sono della stessa famiglia della nostra guida al disaster recovery e delle strategie di testing software: rilevamento più rapido, raggio minore, sistema gestibile da altri.

Mecanik conduce revisioni degli incidenti sui sistemi che manteniamo, come parte del servizio di analisi sicurezza server. Lo schema si ripete quasi sempre: la causa tecnica è stata capita in fretta, e il ritardo di rilevamento è stato la parte cara.

Domande frequenti

A cosa serve un postmortem? A trovare le condizioni che hanno permesso a un problema piccolo di diventare grande e a cambiarne qualcuna, che è una domanda diversa da cosa si è rotto. Produce anche un racconto condiviso dell’evento, senza il quale ognuno tiene una versione privata che deriva verso ciò che già credeva del sistema.

Cosa significa davvero senza colpe? Che l’analisi assume che una persona, agendo in modo ragionevole con le informazioni disponibili, abbia compiuto un’azione rivelatasi sbagliata, e chiede perché sembrasse corretta in quel momento. Conta perché la colpa distrugge informazione: la gente ritocca il proprio racconto per autodifesa e la revisione lavora poi su un input corrotto.

Un postmortem deve individuare una sola causa radice? No. Gli incidenti di qualsiasi dimensione sono catene in cui più condizioni dovevano valere insieme, quindi elencare i fattori contribuenti è più utile. Permette di correggere i due più economici invece del primo della catena, ed evita di concludere con “errore umano”, che è una descrizione e non una spiegazione.

Cosa deve contenere una cronologia dell’incidente? Cosa sapevano le persone e quando, non solo cosa hanno fatto i sistemi. Registrate quando è iniziato, quando qualcuno se ne è accorto, quando è stata coinvolta la persona giusta, quando la causa è stata capita, quando è stato mitigato e quando risolto. Negli intervalli vive il miglioramento, e il tempo di rilevamento è di solito il più ampio.

Perché le azioni dei postmortem non vengono mai fatte? Perché vivono nel documento invece che nel tracker di lavoro, quindi sono invisibili quando il lavoro viene programmato. Si risolve con meno azioni, un responsabile con nome e una data nel tracker abituale, e una revisione delle azioni aperte all’inizio del postmortem successivo, che rende visibile ciò che manca.