Questo principio del pilastro dell'affidabilità del Google Cloud Architecture Framework fornisce consigli per aiutarti a eseguire autopsie efficaci dopo errori e incidenti.
Questo principio è pertinente all'area di interesse dell'apprendimento dell'affidabilità.
Panoramica del principio
Un'analisi post mortem è una registrazione scritta di un incidente, del suo impatto, delle azioni intraprese per mitigare o risolvere l'incidente, delle cause principali e delle azioni di follow-up per impedire che si ripresenti. Lo scopo di un'analisi post mortem è imparare dagli errori e non assegnare responsabilità.
Il seguente diagramma mostra il flusso di lavoro di un'analisi post mortem:
Il flusso di lavoro di un'analisi post mortem include i seguenti passaggi:
- Creare un post mortem
- Raccogli i fatti
- Identifica e analizza le cause principali
- Pianificare il futuro
- Esegui il piano
Esegui analisi post mortem dopo eventi importanti e non importanti, come i seguenti:
- Tempi di riposo o degradamenti visibili agli utenti oltre una determinata soglia.
- Perdite di dati di qualsiasi tipo.
- Interventi di tecnici disponibili, ad esempio un rollback della release o un nuovo routing del traffico.
- Tempi di risoluzione superiori a una soglia definita.
- Errori di monitoraggio, che in genere implicano la rilevazione manuale degli incidenti.
Consigli
Definisci i criteri di post mortem prima che si verifichi un incidente in modo che tutti sappiano quando è necessario eseguire un post mortem.
Per eseguire post mortem efficaci, tieni presenti i consigli riportati nelle seguenti sezioni.
Esegui analisi post mortem senza attribuzione delle colpe
I post mortem efficaci si concentrano su processi, strumenti e tecnologie e non fanno ricadere la colpa su singoli individui o team. Lo scopo di un'analisi post mortem è migliorare la tecnologia e il futuro, non trovare il colpevole. Tutti commettono errori. L'obiettivo dovrebbe essere analizzare gli errori e imparare da essi.
Gli esempi riportati di seguito mostrano la differenza tra un feedback che attribuisce la colpa e un feedback senza colpa:
- Feedback che attribuisce la colpa: "Dobbiamo riscrivere l'intero sistema di backend complicato. Si verificano guasti settimanali da tre quarti di anno a questa parte e sono sicuro che siamo tutti stanchi di sistemare le cose a poco a poco. Seriamente, se mi chiami un'altra volta lo riscriverò io…"
- Feedback senza colpa: "Un'azione per riscrivere l'intero sistema di backend potrebbe effettivamente impedire la comparsa di queste pagine. Il manuale di manutenzione per questa versione è piuttosto lungo ed è molto difficile formarsi completamente. Sono sicuro che i nostri futuri ingegneri di guardia ce lo ringrazieranno."
Rendi il report post mortem leggibile da tutti i segmenti di pubblico previsti
Per ogni informazione che prevedi di includere nel report, valuta se è importante e necessaria per aiutare il pubblico a capire cosa è successo. Puoi spostare spiegazioni e dati supplementari in un'appendice del report. I revisori che hanno bisogno di maggiori informazioni possono richiederle.
Evita soluzioni complesse o sovraingegnerizzate
Prima di iniziare a esplorare le soluzioni per un problema, valutane l'importanza e la probabilità di ricorrenza. L'aggiunta di complessità al sistema per risolvere problemi che difficilmente si verificheranno di nuovo può portare a un aumento dell'instabilità.
Condividi il post mortem con il maggior numero di persone possibile
Per assicurarti che i problemi non rimangano irrisolti, pubblica i risultati del post-mortem per un pubblico ampio e ricevi assistenza dal team di gestione. Il valore di un post mortem è proporzionale all'apprendimento che si verifica dopo il post mortem. Quando più persone imparano dagli incidenti, la probabilità che si ripetano errori simili si riduce.