Close

Gestione degli imprevisti per i team high velocity

Analisi post mortem degli imprevisti

In Atlassian, adottiamo la prassi delle analisi post mortem senza biasimi per assicurarci di comprendere e correggere la causa di ogni imprevisto con un livello di gravità 2 o superiore. Ecco una sintesi della nostra documentazione interna, che descrive in che modo svolgiamo le analisi post mortem in Atlassian.

Manuale sulla gestione degli imprevisti

Scarica il manuale in formato cartaceo o PDF

Abbiamo una fornitura limitata di versioni cartacee del nostro Manuale sulla gestione degli imprevisti che spediamo gratuitamente. In alternativa, puoi scaricare una versione PDF.


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.

Campo

Istruzioni

Esempio

Riepilogo dell'imprevisto

Riassumere l'imprevisto in poche frasi. Includere il livello di gravità, il perché e la durata dell'impatto.

Tra le del , clienti hanno notato . L'evento è stato scatenato da una distribuzione effettuata alle . La distribuzione conteneva una modifica al codice per . Un bug in questa distribuzione ha provocato .

L'evento è stato rilevato dal . Abbiamo mitigato l'evento mediante .

Questo imprevisto di ha interessato l'X% dei clienti.

Sono stati aperti in relazione a questo imprevisto.

Avvisaglie

Descrivere le circostanze che hanno portato all'imprevisto, ad esempio le modifiche precedenti che hanno introdotto bug latenti.

Alle del , (), è stata introdotta una modifica su per... . La modifica ha causato... .

Guasto

Descrivere cosa non ha funzionato come previsto. Allegare schermate di grafici o dati pertinenti che mostrino l'errore.

risposte sono state erroneamente inviate a X% delle richieste nel corso di .

Impatto

Descrivere cosa hanno notato i clienti interni ed esterni durante l'evento imprevisto. Includere quanti casi di supporto sono stati aperti.

Per tra le del , si è notato che .

La circostanza ha interessato clienti (X% di tutti i clienti di ), che hanno avuto problemi di .

Sono stati aperti .

Rilevamento

Come e quando Atlassian ha rilevato l'imprevisto?

Come è possibile migliorare il tempo di rilevamento? Per esercizio mentale, come avremmo potuto dimezzare il tempo di mitigazione?

Il rilevamento dell'imprevisto è avvenuto quando si è attivato il e sono stati avvertiti. Hanno poi dovuto convocare perché non erano responsabili del servizio di scrittura su disco, ritardando la risposta di .

Verrà impostato un da parte di in modo tale che .

Risposta

Chi ha risposto, quando e come? Ci sono stati ritardi o impedimenti alla nostra risposta?

Dopo essere stato contattato alle 14:34 UTC, il tecnico KITT si è collegato online alle 14:38 nella chat dell'imprevisto. Tuttavia, il tecnico di turno non aveva sufficiente esperienza sul servizio automatico di scalabilità Escalator, quindi alle 14:50 è stato inviato un successivo avviso che ha attivato e coinvolto un tecnico KITT senior alle 14:58.

Ripristino

Descrivere come e quando il servizio è stato ripristinato. Come si è capito in che modo arginare l'impatto?

Ulteriori domande da porre, a seconda dello scenario: in che modo è possibile migliorare il tempo di mitigazione? Per esercizio mentale, come avremmo potuto dimezzare il tempo di mitigazione?

Il ripristino è consistito in una triplice risposta:

  • Incremento della capacità di BuildEng EC2 ASG per aumentare il numero di nodi disponibili a soddisfare il carico di lavoro e ridurre le probabilità di pianificazione dei processi su nodi sovraccarichi

  • Disattivazione del servizio automatico di scalabilità Escalator per impedire che il cluster si ridimensioni eccessivamente

  • Ripristino del programma di pianificazione Build Engineering alla versione precedente.

Sequenza temporale

Fornire una sequenza temporale dettagliata dell'imprevisto, in ordine cronologico e con marcature orarie riferite a uno o più fusi orari.

Includere: eventuali avvisaglie; inizio dell'impatto; ora di rilevamento; escalation, decisioni e modifiche; e fine dell'impatto.

Tutti gli orari sono UTC.

11:48 - Aggiornamento K8S 1.9 del piano di controllo terminato
12:46 - Aggiornamento Goliath a V1.9 completato, incluso servizio automatico di scalabilità del cluster e istanza programma di pianificazione BuildEng
14:20 - Build Engineering segnala un problema a KITT Disturbed
14:27 - KITT Disturbed inizia a indagare errori di un'istanza EC2 specifica (ip-203-153-8-204)
14:42 - KITT Disturbed blocca il nodo specifico
14:49 - BuildEng segnala che il problema interessa più di un singolo nodo. 86 istanze del problema indicano che gli errori sono più sistematici
15:00 - KITT Disturbed suggerisce di passare al programma di pianificazione standard
15:34 - BuildEng riporta errori in 300 pod
16:00 - BuildEng esegue il kill di tutte le build in errore con rapporti di OutOfCpu
16:13 - BuildEng segnala che gli errori persistono con le nuove build e non sono semplicemente transitori.
16:30 - KITT riconosce gli errori come imprevisto e li gestisce di conseguenza.
16:36 - KITT disattiva il servizio automatico di scalabilità Escalator per evitare che esso rimuova risorse di elaborazione per limitare il problema.
16:40 - KITT conferma che ASG è stabile, il carico del cluster è normale e l'impatto sui clienti è risolto.

Cinque perché

Utilizzare la tecnica di identificazione della causa primaria.

Iniziare con l'impatto e chiedersi perché sia avvenuto e perché abbia prodotto i danni rilevati. Continuare a chiedere perché fino ad arrivare alla causa primaria.

Documentare i "perché" come nell'elenco riportato o in un diagramma allegato alla issue.

  1. Il servizio ha smesso di funzionare perché il database era bloccato

  2. Perché è verificato un numero eccessivo di scritture sul database

  3. Perché è stata apportata una modifica al servizio e l'aumento non era previsto

  4. Perché non abbiamo impostato un processo di sviluppo nei casi in cui occorre testare il carico delle modifiche

  5. Non abbiamo mai svolto test di carico e stiamo raggiungendo nuovi livelli di crescita

Causa radice

Qual è stata la causa primaria? Si tratta di ciò che deve cambiare per impedire che questa categoria di imprevisto si ripresenti.

Un bug nella gestione del pool di connessione a ha determinato connessioni in condizioni di errore, associate a mancanza di visibilità sullo stato della connessione.

Controllo del backlog

Vi sono sviluppi in backlog che avrebbero potuto evitare l'imprevisto o ridurne notevolmente l'impatto? Se sì, perché non sono stati implementati?

Una valutazione onesta aiuta a chiarire le passate decisioni in merito a priorità e rischi.

Non in senso specifico. I miglioramenti alla tipizzazione del flusso erano task noti in via di sviluppo con proprie procedure già stabilite (ad es. aggiungere tipi di flusso per la modifica/creazione di un file). I ticket per la sistemazione dei test di integrazione erano stati aperti ma i tentativi non hanno avuto successo.

Ricorrenza

Questo imprevisto (con la stessa causa primaria) si era già verificato? Se sì, perché si è ripetuto?

Questa stessa causa primaria ha causato gli imprevisti HOT-13432, HOT-14932 e HOT-19452.

Lezioni apprese

Che cosa abbiamo imparato?

Dibattere cosa ha funzionato, cosa avrebbe potuto funzionare meglio e dove abbiamo avuto fortuna in modo da trovare le opportunità di miglioramento.

  1. Occorre un test unitario per verificare che il limitatore di velocità del lavoro sia stato sottoposto a corretta manutenzione

  2. I carichi di lavoro delle operazioni di massa atipiche rispetto al normale funzionamento dovrebbero essere rivisti

  3. Le operazioni di massa devono iniziare progressivamente ed essere monitorate, aumentandole quando le metriche del servizio sembrano mantenersi su valori nominali

Azioni correttive

Cosa faremo per assicurarci che questa categoria di imprevisti non si ripeta? Chi intraprenderà le azioni ed entro quando?

Creare link di "Azione prioritaria" ai ticket per monitorare ciascuna azione.

  1. Posto temporaneamente in atto un limite di velocità del servizio automatico di scalabilità per limitare gli errori

  2. Test unitario e reintroduzione della limitazione di velocità del lavoro

  3. Introduzione di un meccanismo secondario per raccogliere le informazioni di velocità distribuite sul cluster per guidare gli effetti di scalabilità

  4. Le migrazioni di entità importante devono essere coordinate, poiché AWS ES non offre la scalabilità automatica

  5. Verificare che la ricerca di Stride sia ancora classificata come Livello 2

  6. Aprire un ticket relativo al servizio pf-directory-service in modo da farlo terminare in errore parziale anziché totale quando xpsearch-chat-searcher termina in errore.

  7. Prevedere un avviso di Cloudwatch per identificare un problema di I/O elevato sul cluster ElasticSearch


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:

Scenario Causa immediata e azione Causa radice Mitigazione della causa primaria

I servizi dello Squad "Red Dawn" di Stride non disponevano di monitoraggio Datadog e avvisi su chiamata oppure non erano configurati correttamente.

I membri del team non avevano configurato il monitoraggio e l'invio di segnalazioni per i nuovi servizi.

Assicurarsi di configurarli per questi servizi.

Non vi è un processo definito per avviare nuovi servizi, che includa monitoraggio e segnalazioni.

Creare un processo per avviare i nuovi servizi e addestrare il team a seguirlo.

Stride è inutilizzabile su IE11 a causa di un aggiornamento a Fabric Editor che non funziona con questa versione del browser.

Aggiornamento di una dipendenza.

Ripristinare l'aggiornamento precedente.

Mancanza di test di compatibilità su tutti i browser.

Automatizzare test permanenti di compatibilità su tutti i browser.

I log di Micros EU non raggiungevano il servizio di registrazione eventi.

Il ruolo attribuito a Micros per inviare i log era errato.

Correggere il ruolo.

Non è possibile sapere quando la registrazione eventi da un ambiente non funziona.

Aggiungere monitoraggio e segnalazioni sui log mancanti per qualsiasi ambiente.

Innescati da un precedente imprevisto di AWS, i nodi Confluence Vertigo hanno esaurito il proprio pool di connessioni a Media, causando ai clienti errori intermittenti su allegati e documenti multimediali.

Errore AWS.

Recuperare l'analisi post mortem di AWS.

Un bug nella gestione del pool di connessioni Confluence ha determinato connessioni in condizioni di errore, associate a mancanza di visibilità sullo stato della connessione.

Correggere il bug e aggiungere il monitoraggio che può rilevare situazioni future simili prima che abbiano un impatto.


Categorie di cause primarie e azioni corrispondenti

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

Categoria

Definizione

Cosa occorre fare al riguardo?

Bug

Una modifica al codice effettuata da Atlassian (questo è un tipo specifico di modifica)

Test. Canary. Effettuare implementazioni incrementali e osservare il loro andamento. Utilizzare flag di funzionalità. Confrontarsi con il proprio tecnico della qualità.

Modifica

Una modifica effettuata da Atlassian (che non riguardi il codice)

Migliorare il modo in cui si eseguono le modifiche, ad esempio le revisioni delle modifiche o i processi di gestione delle modifiche. Tutte le osservazioni fatte per un "bug" valgono anche in questo caso.

Scalabilità

Difetti di scalabilità (ad esempio, ignoranza dei limiti delle risorse o assenza di pianificazione della capacità)

Quali sono i limiti di risorse del servizio? Vengono monitorati e segnalati? Se non si dispone di un piano di capacità, crearne uno. Se ve n'è uno, quale nuovo vincolo occorre considerare?

Architettura

Disallineamento della progettazione rispetto alle condizioni operative

Controllare la progettazione. Occorre cambiare piattaforma?

Dipendenza

Errore di un servizio di terze parti (non di Atlassian)

Si sta gestendo il rischio di errori o guasti di terze parti? È stata presa la decisione aziendale di accettare un rischio o è necessario adottare misure di contenimento? Vedere "Cause primarie con dipendenze" qui di seguito.

Sconosciuto

Non determinabile (l'azione è aumentare la capacità diagnostica)

Migliorare l'osservabilità del sistema aggiungendo funzioni di log, monitoraggio, debug e simili.


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.

Categoria Domanda da porsi Esempi

Indagare sull'imprevisto

"Cosa ha causato questo imprevisto e perché?" L'obiettivo finale è determinare le cause primarie.

Analisi dei log, diagrammi del percorso della richiesta, riesame dei dump dell'heap

Mitigare l'imprevisto

"Quali azioni immediate abbiamo intrapreso per risolvere e gestire questo specifico evento ?"

Ripristino, scelte selettive, push di configurazioni, comunicazione con gli utenti interessati

Riparare i danni derivanti dall'imprevisto

"Come abbiamo risolto i danni immediati o collaterali provocati da questo imprevisto?"

Ripristino dei dati, riparazione delle macchine, rimozione di reindirizzamenti di traffico

Rilevare imprevisti futuri

"Come possiamo ridurre il tempo necessario a rilevare con precisione un simile errore?"

Monitoraggio, segnalazioni, verifiche di plausibilità su input/output

Mitigare imprevisti futuri

"Come possiamo ridurre la gravità e/o la durata di simili imprevisti futuri?"

"La prossima volta, come possiamo ridurre la percentuale di utenti interessati da questa categoria di malfunzionamenti?"

Degradazione progressiva, perdita di risultati non critici, errori di apertura, intensificazione delle prassi attuali con dashboard o playbook, modifiche al processo degli imprevisti

Prevenire imprevisti futuri

"Come possiamo evitare il ripetersi di questo tipo di malfunzionamento?"

Miglioramenti della stabilità nel codice di base, test unitari più approfonditi, convalida dell'input e robustezza rispetto all condizioni di errore, modifiche al provisioning

Inoltre, utilizziamo i consigli di Lueder e Beyer su come formulare le nostre azioni post mortem.

Formulazione di azioni post mortem:

La corretta formulazione di un'azione post mortem può fare la differenza tra una facile conclusione e un ritardo indefinito dovuto a impraticabilità o procrastinazione. Un'azione post mortem ben progettata deve avere le seguenti proprietà ed essere:

Realizzabile: formula ogni azione come una frase che inizia con un verbo. L'azione deve tradursi in un risultato utile, non in un processo. Ad esempio, "Enumerare l'elenco delle dipendenze critiche" è una buona azione, mentre "Effettuare un indagine sulle dipendenze" non lo è.

Specifica: definisci l'ambito di ciascuna azione nel modo più restrittivo possibile, chiarendo cosa è incluso e cosa non è incluso nel lavoro.

Circoscritta: esprimi ogni azione indicando come poter capire quando è finita, piuttosto che lasciarla aperta o in corso.

Da... A...

Indagare il monitoraggio per questo scenario.

(Azione realizzabile) Aggiungere segnalazioni per tutti i casi in cui questo servizio restituisce >1% di errori.

Risolvere il problema che ha causato l'interruzione del servizio.

(Azione specifica) Gestire in modo sicuro il codice postale non valido nel modulo di immissione degli indirizzi utente.

Assicurarsi che il tecnico verifichi che lo schema del database possa essere analizzato prima dell'aggiornamento.

(Azione circoscritta) Aggiungere un controllo automatico prima dell'invio per le modifiche dello schema.


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.