Questo principio del pilastro dell'affidabilità del Google Cloud framework Well-Architected fornisce consigli per aiutarti a condurre postmortem efficaci dopo guasti e incidenti.
Questo principio è pertinente all'area di interesse dell'apprendimento dell'affidabilità.
Panoramica del principio
Un 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 evitare che si ripeta. L'obiettivo di un post mortem è imparare dagli errori e non assegnare colpe.
Il seguente diagramma mostra il flusso di lavoro di un post mortem:
Il flusso di lavoro di un post mortem include i seguenti passaggi:
- Crea un postmortem
- Acquisire i fatti
- Identificare e analizzare le cause principali
- Pianificare il futuro
- Esegui il piano
Esegui analisi post mortem dopo eventi importanti e non importanti come i seguenti:
- Tempi di inattività o peggioramenti visibili agli utenti oltre una determinata soglia.
- Perdite di dati di qualsiasi tipo.
- Interventi di ingegneri di turno, ad esempio un rollback della release o il reindirizzamento del traffico.
- Tempi di risoluzione superiori a una soglia definita.
- Errori di monitoraggio, che di solito implicano il rilevamento manuale degli incidenti.
Consigli
Definisci i criteri post mortem prima che si verifichi un incidente, in modo che tutti sappiano quando è necessario un post mortem.
Per condurre postmortem efficaci, tieni presente i consigli nelle seguenti sottosezioni.
Eseguire analisi post mortem senza attribuzione delle colpe
Le analisi post mortem efficaci si concentrano su processi, strumenti e tecnologie e non attribuiscono la colpa a individui o team. Lo scopo di un'analisi post-mortem è quello di migliorare la tua tecnologia e il tuo futuro, non di trovare il colpevole. Tutti commettono errori. L'obiettivo dovrebbe essere analizzare gli errori e imparare da questi.
Gli esempi seguenti mostrano la differenza tra un feedback che attribuisce la colpa e un feedback che non attribuisce la colpa:
- Feedback che attribuisce la colpa: "Dobbiamo riscrivere l'intero complicato sistema di backend! Si rompe ogni settimana da tre trimestri e sono sicuro che siamo tutti stanchi di aggiustare le cose pezzo per pezzo. Seriamente, se mi chiamano un'altra volta, lo riscrivo io…"
- Feedback senza colpe: "Un'azione per riscrivere l'intero sistema di backend potrebbe effettivamente impedire che queste pagine continuino a essere visualizzate. Il manuale di manutenzione per questa versione è piuttosto lungo e molto difficile da imparare completamente. Sono sicuro che i nostri futuri ingegneri di turno ci ringrazieranno."
Rendere il report postmortem 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 i dati e le spiegazioni supplementari in un'appendice del report. I revisori che necessitano di maggiori informazioni possono richiederle.
Evita soluzioni complesse o eccessivamente elaborate
Prima di iniziare a esplorare le soluzioni a un problema, valuta l'importanza del problema e la probabilità che si ripresenti. Aggiungere complessità al sistema per risolvere problemi che è improbabile che si ripresentino può portare a una maggiore instabilità.
Condividi l'analisi post-mortem il più ampiamente possibile
Per assicurarti che i problemi non rimangano irrisolti, pubblica i risultati dell'analisi post mortem per un vasto pubblico e ricevi il supporto della gestione. Il valore di un'analisi post mortem è proporzionale all'apprendimento che si verifica dopo l'analisi. Quando più persone imparano dagli incidenti, la probabilità che si verifichino nuovamente guasti simili si riduce.