Analisi post mortem degli imprevisti

Che cos'è un'analisi retrospettiva?

Un'analisi post mortem è una traccia scritta di un imprevisto che descrive:

• L'impatto dell'imprevisto.
• Le azioni intraprese per arginare o risolvere l'imprevisto.
• La causa primaria alla radice dell'imprevisto.
• Le misure di follow-up adottate per impedire il ripetersi dell'imprevisto.

In Atlassian, monitoriamo tutte le analisi post mortem mediante le issue di Jira per assicurarci che siano completate e approvate. Se le tue esigenze sono meno complesse, puoi decidere di utilizzare un sistema più semplice, come una pagina Confluence per ciascuna analisi post mortem .

Perché svolgiamo analisi post mortem?

Gli obiettivi di un'analisi post mortem sono: comprendere tutte le cause primarie che hanno contribuito all'imprevisto, documentare l'imprevisto per futuro riferimento e identificazione di schemi ricorrenti e varare azioni preventive efficaci per ridurre la probabilità o l'impatto di episodi ripetuti.

Affinché le analisi retrospettive siano efficaci nel ridurre gli imprevisti ripetuti, il processo di revisione deve incentivare i team a identificare le cause principali e a correggerle. La scelta del metodo più adatto dipende dalla cultura del tuo team; in Atlassian, abbiamo individuato una combinazione di metodi che funzionano con i nostri team di risposta agli imprevisti:

• Le riunioni faccia a faccia aiutano a condurre analisi appropriate e allineano il team su ciò che deve essere corretto.
• Le approvazioni post mortem da parte dei responsabili dei team operativi e di delivery incentivano i team a svolgere in modo accurato il lavoro necessario.
• Le "azioni prioritarie" designate hanno un Obiettivo del livello di servizio (SLO) concordato di 4 o 8 settimane, a seconda del servizio, con promemoria e rapporti per assicurarsi che siano completate.

La partecipazione a questo processo e la verifica che sia efficace richiedono un impegno a tutti i livelli dell'organizzazione. I nostri direttori e manager tecnici hanno deciso gli approvatori e gli SLO per la risoluzione delle azioni nelle rispettive aree. Questo sistema si limita a codificare e tenta di far rispettare le loro decisioni.

Quando è necessaria un'analisi post mortem?

Noi svolgiamo analisi post mortem per imprevisti di gravità 1 e 2. Negli altri casi, sono facoltative.

Durante la risoluzione o subito dopo aver risolto la issue, il responsabile dell'analisi post mortem crea una nuova issue post mortem.

Chi completa l'analisi post mortem?

Il team di delivery del servizio andato in errore (il team indicato come responsabile del "Servizio difettoso" nella issue dell'imprevisto) è responsabile del completamento dell'analisi postmortem. Quel team seleziona il responsabile dell'analisi post mortem e gli assegna la issue post mortem.

• Il responsabile dell'analisi retrospettiva gestisce tale analisi in tutte le fasi, dalla stesura, all'approvazione fino alla pubblicazione finale. Il responsabile risponde del completamento dell'analisi retrospettiva.
• Uno o più responsabili dell'approvazione post mortem esaminano e approvano l'analisi post mortem e sono tenuti ad assegnare la priorità alle azioni di follow-up nel proprio backlog.

Noi usiamo una pagina Confluence in cui sono elencati i responsabili dell'approvazione post mortem (obbligatori e facoltativi) ordinati per gruppi di servizi, che generalmente corrispondono ai prodotti Atlassian (ad esempio, Bitbucket Cloud).

Come si tracciano le azioni delle analisi post mortem?

Per ogni azione derivante dall'analisi post mortem:

• Apriamo una issue Jira nel backlog del team responsabile. Tutte le azioni post mortem devono essere tracciate in Jira.
• Le colleghiamo dalla issue post mortem come "Azione prioritaria" (per correzioni di cause primarie) o "Azione migliorativa" (per interventi correttivi relativi a cause non primarie ).

Abbiamo creato alcuni report personalizzati utilizzando le API REST di Jira per tenere traccia del numero di imprevisti a ciascun livello di gravità le cui cause primarie non sono state corrette mediante le azioni prioritarie sul post mortem. I responsabili tecnici di ciascun reparto esaminano regolarmente questo elenco.

Processo di analisi post mortem

La gestione del processo post mortem include la creazione di una issue post mortem, lo svolgimento di una riunione post mortem, l'identificazione di azioni, l'approvazione e (facoltativamente) la comunicazione dei risultati.

Il responsabile dell'analisi post mortem ha l'incarico di gestire di queste attività:

1. Creare un post mortem e collegarlo all'imprevisto.
2. Modificare la issue post mortem, leggere le descrizioni dei campi e compilarli.
3. Utilizzare la tecnica dei "Cinque perché", percorrendo la catena causale fino a trovare la vera causa principale dell'imprevisto.
4. Pianificare la riunione post mortem. Invitare il team di delivery, i team interessati e tutte parti coinvolte, utilizzando il modello di invito alla riunione.
5. Incontrare il team e gestire la riunione secondo la scaletta sotto indicata.
6. Confrontarsi in seguito con i manager responsabili dello sviluppo e ottenere il loro impegno a intraprendere misure specifiche che evitino questa categoria di imprevisti.
7. Aprire una issue Jira per ogni azione nei backlog dei team responsabili. Collegare le azioni dalla issue post mortem "Azione prioritaria" (per correzioni di cause primarie) o "Azione migliorativa" (per altri interventi correttivi).
8. Cercare i responsabili approvazione idonei in Confluence e aggiungerli al campo "Approvatori" nell'analisi retrospettiva.
9. Selezionare la transizione "Richiedi approvazione" per richiedere l'approvazione da parte degli approvatori designati. Una procedura automatica inserisce commenti sul ticket con istruzioni per gli approvatori.
10. Seguire il processo secondo necessità fino all'approvazione dell'analisi post mortem.
11. Una volta approvato il post mortem, una procedura automatica crea una bozza di blog post mortem, che è possibile modificare e pubblicare. Un blog per le analisi post mortem permette di condividere le lezioni così faticosamente acquisite e ne moltiplica il valore.

Una volta terminato il processo post mortem, le azioni vengono ordinate in base alla priorità dal team di sviluppo come parte del normale backlog in base allo SLO del team.

Riunioni di analisi post mortem

Riteniamo che riunire il team per discutere insieme quanto appreso consenta un'analisi più approfondita delle cause primarie. Spesso ricorriamo alla videoconferenza, poiché i nostri team sono distribuiti, e talvolta, se gli imprevisti coinvolgono gruppi numerosi, le riunioni si svolgono per gruppi.

Ecco la scaletta che consigliamo:

1. Ricordare al team che le analisi post mortem sono senza biasimo e spiegarne il motivo
2. Accertare la cronologia degli eventi
3. Accertare le cause primarie
4. Individuare le azioni utilizzando una "mentalità aperta" - "Cosa potremmo fare per prevenire questa categoria di imprevisti in futuro?"
5. Chiedere al team "Cosa ha funzionato / Cosa potrebbe aver funzionato meglio / Dove abbiamo avuto fortuna?"

Modello suggerito per la prenotazione a calendario della riunione:

Ti invito a partecipare a un'analisi postmortem senza biasimo relativa a , in cui .

Gli obiettivi di un'analisi post mortem sono: comprendere tutte le cause primarie che hanno contribuito all'imprevisto, documentare l'imprevisto per futuro riferimento e identificazione di schemi ricorrenti e varare azioni preventive efficaci per ridurre la probabilità o l'impatto di episodi ripetuti.

In questa riunione, cercheremo di determinare le cause primarie e di decidere le azioni finalizzate ad arginarle.

Se all'incontro non sono presenti i manager responsabili dello sviluppo, evitare di impegnarsi su azioni specifiche durante la riunione, perché il contesto non è adatto a decisioni che definiscano le priorità. I partecipanti si sentiranno obbligati a impegnarsi pur non avendo informazioni complete. Piuttosto, confrontarsi con i manager responsabili dopo la riunione per ottenere il loro impegno a fissare le azioni prioritarie identificate.

Campi della issue per l'analisi post mortem

La nostra issue post mortem dispone di svariati campi per incoraggiare la raccolta di tutti i dettagli importanti sull'imprevisto prima della riunione postmortem. Di seguito riportiamo alcuni esempi del modo in cui compiliamo questi campi.

Cause immediate e cause primarie

Nel redigere o consultare un'analisi post mortem, è necessario distinguere tra cause immediate e cause primarie.

• Le cause immediate sono i motivi che hanno portato direttamente all'imprevisto.
• Le cause primarie sono i motivi, posti nel punto ottimale della catena di eventi, modificando i quali è possibile evitare l'intera categoria di imprevisti.

Un'analisi retrospettiva ha lo scopo di scoprire le cause principali e decidere il modo migliore per arginarle. La vera efficacia di un'analisi retrospettiva consiste nel saper trovare il punto ottimale nella catena di eventi. Consigliamo di utilizzare una tecnica come quella dei Cinque perché per "risalire lungo la catena" e individuare le cause principali.

Ecco qualche esempio di cause immediate e cause primarie:

Categorie di cause primarie e azioni corrispondenti

Utilizziamo queste categorie per raggruppare le cause principali e discutere le azioni appropriate per ciascuna di esse.

Cause primarie con dipendenze

Quando nel servizio si verifica un imprevisto dovuto all'errore di una dipendenza, la posizione dell'errore e la causa primaria dipendono dall'accertare se la dipendenza è interna ad Atlassian o di terze parti e dal chiedersi quale sia l'aspettativa ragionevole della performance della dipendenza.

Se si tratta di una dipendenza interna, chiedersi "qual è l' Obiettivo del livello di servizio (SLO) della dipendenza?":

• La dipendenza ha violato lo SLO?
  • L'errore è della dipendenza ed è necessario un incremento della sua affidabilità.
• La dipendenza ha rispettato lo SLO, ma il servizio presentava comunque errori?
  • Il servizio deve migliorare la propria capacità di recupero.
• La dipendenza non ha uno SLO?
  • Ne occorre uno!

Se si tratta di una dipendenza di terze parti, chiedersi "qual è la nostra ragionevole aspettativa* circa la disponibilità/latenza/ecc. della dipendenza della terza parte?"

• La dipendenza della terza parte ha superato le nostre aspettative (in senso negativo)?
  • L'aspettativa non era corretta.
    • Siamo sicuri che il problema non si ripeterà? Ad esempio: riesaminiamo e accettiamo la RCA (analisi delle cause primarie) del fornitore. In questo caso, l'azione è l'RCA della terza parte.
    • Oppure, dobbiamo adeguare le nostre aspettative? In questo caso, le azioni devono aumentare la nostra capacità di recupero e adattare le nostre aspettative.
    • Le nostre aspettative adattate sono inaccettabili? In questo caso, dobbiamo risolvere in qualche modo il divario tra requisiti e soluzione, ad esempio trovare un altro fornitore.
• La dipendenza di una terza parte ha soddisfatto le nostre aspettative, ma il servizio presentava comunque errori?
  • In questo caso, il servizio deve migliorare la propria capacità di recupero.
• Non abbiamo realmente un'aspettativa?
  • Il responsabile di una dipendenza di terze parti deve stabilirlo e condividerlo con i team, in modo che sappiano quale livello di capacità di recupero occorre per sviluppare sui servizi dipendenti.

*Perché si parla di "aspettativa"? Non disponiamo di SLA con le terze parti? In realtà, gli SLA contrattuali con terze parti sono troppo carenti per essere utili nel determinare errori e misure di contenimento. Ad esempio, AWS non pubblica quasi nessuno SLA per EC2. Pertanto, quando dipendiamo dal servizio di una terza parte, dobbiamo prendere una decisione sul livello di affidabilità, disponibilità, prestazioni o altra metrica chiave che ci aspettiamo venga ragionevolmente fornito.

Azioni post mortem

Sue Lueder e Betsy Beyer di Google hanno pubblicato un'eccellente presentazione e un articolo sulle azioni post mortem, che in Atlassian utilizziamo per stimolare il team.

Esamina le domande seguenti per un supporto nel garantire che il PIR (Revisione post mortem dell'imprevisto) copra le correzioni a breve e a lungo termine:

"Mitigare imprevisti futuri" e "Prevenire imprevisti futuri" sono la tua fonte più probabile di azioni che affrontano la causa primaria. Assicurati di sviluppare almeno una di queste strategie.

Approvazioni post mortem

Atlassian utilizza un flusso di lavoro Jira con una fase di approvazione per garantire che le analisi post mortem siano approvate. I responsabili dell'approvazione sono generalmente responsabili di servizi o altri manager con responsabilità del funzionamento di un servizio. L'approvazione per un analisi post mortem indica:

• Accordo con le conclusioni della revisione successiva all'imprevisto, inclusa l'identificazione della causa primaria; e
• Accordo sul fatto che le azioni collegate indicate come "Azione prioritaria" sono una soluzione accettabile per risolvere la causa primaria.

I nostri approvatori richiedono spesso azioni aggiuntive o identificano una determinata catena di causalità non presa in considerazione dalle azioni proposte. Così facendo, in Atlassian notiamo che le approvazioni aggiungono moltissimo valore al processo post mortem.

Nei team con un numero inferiore di imprevisti o con infrastrutture meno complesse, le approvazioni post mortem potrebbero non essere necessarie.

Analisi post mortem senza biasimo

Quando sorgono problemi, cercare qualcuno da incolpare è una naturale tendenza umana. È nell'interesse di Atlassian evitare questa situazione; quindi, nello svolgere un'analisi post mortem, occorre deliberatamente vincere questa propensione. Diamo per scontate le buone intenzioni da parte del nostro personale e non incolpiamo mai le persone per i malfunzionamenti. L'analisi post mortem deve esaminare in modo onesto e obiettivo le circostanze che hanno portato al malfunzionamento, in modo da poter trovare le vere cause primarie e contenerle. Incolpare le persone mette a repentaglio questo obiettivo, perché:

• Quando le persone sentono a rischio la propria posizione o le proprie prospettive di carriera, in presenza di loro colleghi, solitamente "i superiori interessi aziendali del datore di lavoro" passano in secondo piano nella loro gerarchia personale; quindi chiaramente dissimulano o nascondono la verità per proteggere le proprie esigenze fondamentali.
• Anche se una persona ha intrapreso un'azione che ha direttamente portato a un imprevisto, ciò che dovremmo chiedere non è "perché l'individuo x ha fatto questo?", ma "perché il sistema gli ha permesso di farlo, o l'ha indotto a credere che fosse la cosa giusta da fare?".
• Dare la colpa alle singole persone è scortese e, se si ripete troppo spesso, crea una cultura di timore e sfiducia.

Nelle nostre analisi post mortem, adottiamo queste tecniche per favorire un clima di sicurezza personale per tutti i partecipanti:

• Aprire la riunione di analisi retrospettiva dichiarando che si tratta di un'analisi oggettiva e spiegandone il motivo.
• Fare riferimento ai singoli in base al ruolo (ad es. "il tecnico di turno dei Widget") piuttosto che col nome (pur restando chiari e non ambigui circa i fatti)
• Assicurarsi che la sequenza temporale, la catena causale e le mitigazioni del post mortem siano inquadrate nel contesto di sistemi, processi e ruoli, non individui.

La nostra ispirazione per analisi post mortem senza biasimo e l'utile concetto di "seconde storie" provengono dall'articolo fondamentale di John Allspaw.