Modello dell'analisi retrospettiva degli imprevisti

Una documentazione chiara è la chiave di un'analisi retrospettiva degli imprevisti efficace. Molti team usano un modello completo per raccogliere dettagli coerenti durante le revisioni delle analisi retrospettive. 

Di seguito è riportato un esempio di un modello di analisi retrospettiva degli imprevisti basato sull'analisi descritta nel nostro manuale degli imprevisti. Puoi copiare e incollare questi contenuti per documentare le tue analisi retrospettive.

Riepilogo dell'imprevisto

Scrivi un riepilogo dell'imprevisto in poche frasi. Includi ciò che è successo, il perché, il livello di gravità dell'imprevisto e la durata dell'impatto.

ESEMPIO:

Nella fascia oraria {time range of incident, e.g. 15:45 and 16:35} del giorno {DATE}, {NUMBER} gli utenti hanno riscontrato {EVENT SYMPTOMS}. 

L'evento è stato attivato da {CHANGE} alle ore {TIME OF CHANGE THAT CAUSED THE EVENT}. 

{CHANGE} conteneva {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Un bug in questo codice ha causato {DESCRIPTION OF THE PROBLEM}. 

L'evento è stato rilevato da {MONITORING SYSTEM}. Il team ha iniziato a lavorare sull'evento intervenendo in questo modo: {RESOLUTION ACTIONS TAKEN}.

Questo imprevisto {SEVERITY LEVEL} ha interessato il {X%} degli utenti.

Si è avuto un ulteriore impatto, come notato dalle segnalazioni di {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} in relazione a questo imprevisto. 

Avvisaglie

Descrivi la successione di eventi che hanno portato all'imprevisto, ad esempio le modifiche precedenti che hanno introdotto bug non ancora rilevati.

ESEMPIO:

Alle ore {16:00} del giorno {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), è stata introdotta una modifica a {PRODUCT OR SERVICE}  al fine di {THE CHANGES THAT LED TO THE INCIDENT}. 

Questa modifica ha prodotto  {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Guasto

Descrivi in che modo la modifica implementata non ha avuto i risultati previsti. Se possibile, allega screenshot delle visualizzazioni dei dati pertinenti in cui è illustrato l'errore.

ESEMPIO:

{NUMBER} risposte sono state inviate per errore al {XX%} delle richieste. Questo è andato avanti per {TIME PERIOD}.

Impatto

Descrivi l'impatto che l'imprevisto ha avuto sugli utenti interni ed esterni. Includi quanti casi di assistenza sono stati aperti.

ESEMPIO:

Per {XXhrs XX minutes} nell'intervallo di tempo {XX:XX UTC and XX:XX UTC} del giorno {MM/DD/YY}, {SUMMARY OF INCIDENT} i nostri utenti hanno subito questo imprevisto.

Questo imprevisto ha interessato {XX} clienti (X% DI UTENTI DI {SYSTEM OR SERVICE}), che hanno riscontrato {DESCRIPTION OF SYMPTOMS}.

Sono stati inviati {XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}.

Rilevamento

Quando il team ha rilevato l'imprevisto? Come se n'è accorto? In che modo è possibile migliorare il tempo di rilevamento? Rifletti: come avremmo potuto dimezzare questo tempo?

ESEMPIO:

L'imprevisto è stato rilevato quando {ALERT TYPE} è stato attivato e sono stati chiamati {TEAM/PERSON}. 

In seguito, è stato contattato {SECONDARY PERSON} perché {FIRST PERSON} non era responsabile del servizio di scrittura su disco e questo ha ritardato la risposta di {XX MINUTES/HOURS}.

{DESCRIBE THE IMPROVEMENT} verrà impostato da {TEAM OWNER OF THE IMPROVEMENT} in modo che {EXPECTED IMPROVEMENT}.

Risposta

Chi ha risposto all'imprevisto? Quando ha risposto e cosa ha fatto? Annota eventuali ostacoli o ritardi della risposta.

ESEMPIO:

Dopo essere stato contattato alle ore {XX:XX UTC}, {ON-CALL ENGINEER} si è collegato alle ore {XX:XX UTC} in {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Il tecnico non aveva conoscenze pregresse su {AFFECTED SYSTEM}, quindi è stato inviato un secondo avviso alle ore {XX:XX UTC} a {ESCALATIONS ON-CALL ENGINEER}, che è arrivato alle ore {XX:XX UTC}.

Ripristino

Descrivi in che modo è stato ripristinato il servizio ed è stato ritenuto concluso l'imprevisto. Esponi nei dettagli come hai ripristinato il corretto funzionamento del sistema e come sapevi quali passaggi seguire per farlo. 

A seconda dello scenario, considera queste domande: In che modo è possibile migliorare il tempo di mitigazione? e Come avremmo potuto dimezzare questo tempo?

ESEMPIO:

Abbiamo utilizzato un triplice approccio al ripristino del sistema: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Esempio: incrementando la capacità di BuildEng EC3 ASG per aumentare il numero di nodi disponibili a supportare 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.

Timeline

Descrivi nei dettagli la timeline dell'imprevisto. Consigliamo di utilizzare il fuso orario UTC come standard.

Includi eventuali eventi importanti precedenti all'evento, gli avvii delle attività, il primo impatto noto e le escalation. Annota le decisioni prese o le modifiche apportate e l'ora di fine dell'imprevisto, oltre agli eventuali eventi successivi all'impatto degni di nota. 

ESEMPIO:

Tutti gli orari sono UTC.

11:48 - Upgrade a K8S 1.9 del piano di controllo terminato 

12:46 - Upgrade alla V1.9 completato, incluse le istanze del servizio automatico di scalabilità cluster e del servizio di programmazione BuildEng 

14:20 - L'ingegnere della build segnala un problema a KITT Disturbed

14:27 - KITT Disturbed inizia a indagare sui guasti di una specifica istanza EC2 (ip-203-153-8-204) 

14:42 - KITT Disturbed isola il nodo 

14:49 - BuildEng segnala che il problema interessa più di un solo nodo. 86 istanze del problema mostrano che gli errori sono più sistemici 

15:00 - KITT Disturbed suggerisce di passare allo scheduler standard 

15:34 - BuildEng segnala che 200 pod hanno avuto esito negativo 

16:00 - BuildEng blocca tutte le build non riuscite con report OutOfCPU 

16:13 - BuildEng segnala che gli errori sono costantemente ricorrenti con le nuove build e non sono stati solo 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.

MODELLO:

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

Identificazione della causa primaria: I cinque perché

I 5 perché sono una tecnica di identificazione della causa primaria. Ecco come puoi usarla:

• Inizia con una descrizione dell'impatto e chiediti perché si è verificato. 

• Prendi nota dell'impatto.  

• Chiediti perché è successo e perché ha avuto l'impatto che ne è derivato. 

• Continua a chiederti perché fino ad arrivare alla causa primaria.

Elenca i "perché" nella documentazione dell'analisi retrospettiva.

ESEMPIO:

1. L'applicazione ha avuto un'interruzione perché il database era bloccato

2. Il database è bloccato perché c'erano troppe scritture al suo interno

3. Perché abbiamo introdotto una modifica al servizio e non ci aspettavamo scritture elevate

4. Perché non abbiamo un processo di sviluppo stabilito per le modifiche ai test di carico

5. Perché non abbiamo mai ritenuto necessario eseguire il test di carico fino a quando non abbiamo raggiunto questo livello di scala.

Causa radice

Annota la causa primaria definitiva dell'imprevisto, ovvero ciò che deve cambiare per impedire che questa categoria di imprevisto si ripresenti.

ESEMPIO:

Un bug in

Controllo del backlog

Rivedi il backlog di progettazione per verificare se c'era del lavoro non pianificato che avrebbe potuto impedire questo imprevisto o almeno ridurne l'impatto. 

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

ESEMPIO:

Nessun elemento specifico nel backlog che avrebbe potuto migliorare questo servizio. C'è una nota sui miglioramenti della tipizzazione del flusso e questi erano task noti in via di sviluppo con propri flussi di lavoro.  

Sono stati inviati dei ticket relativi al miglioramento dei test di integrazione che finora non hanno avuto successo.

Ricorrenza

Ora che conosci la causa primaria, puoi esaminare gli imprevisti passati e verificare se hanno la stessa causa primaria? Se la risposta è sì, annota la mitigazione tentata per questi imprevisti e chiedi perché l'imprevisto si è verificato di nuovo.

ESEMPIO:

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

Lezioni apprese

Discuti di cosa è andato bene nel processo di risposta agli imprevisti, di cosa poteva essere migliorato e delle opportunità di miglioramento.

ESEMPIO:

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

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

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

Azioni correttive

Descrivi l'azione correttiva stabilita per impedire che questa categoria di imprevisti si verifichi in futuro. Annota chi è il responsabile, quando deve completare il lavoro e dove tale lavoro viene monitorato.

ESEMPIO:

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à