Gestione degli incidenti, parte 4: Analisi e report degli incidenti successivi alla soluzione

Questa è la parte 4 della panoramica della gestione degli incidenti in Zendesk. Questa guida contiene le parti seguenti:

Parte 1: Come i problemi di servizio Zendesk diventano incidenti di servizio
Parte 2: Come Zendesk gestisce gli incidenti di servizio
Parte 3: Monitoraggio di un incidente pubblico del servizio Zendesk
Parte 4: Analisi e report degli incidenti successivi alla soluzione (questo articolo)

In questo articolo, parte 4, impareraicome il team di risposta agli incidenti conduce una retrospettiva che include l'analisi delle cause principali e la soluzione degli incidenti di servizio e quindi assegna gli elementi di riparazione ai team di progettazione che ne hanno la proprietà.

Svolgendo queste attività, l’assistenza clienti Zendesk può condividere i dettagli dell’incidente e i passaggi successivi con i clienti interessati.

Questo articolo contiene le sezioni seguenti:

Retrospettiva di un incidente di servizio
Assegnazione di elementi di riparazione
Chiusura di un incidente di servizio

Retrospettiva di un incidente di servizio

Zendesk conduce un esercizio di riflessione con tutti i membri del team coinvolti nell'incidente per esaminare e documentare le cause dell'incidente, l'impatto dell'incidente sui clienti e le azioni intraprese per mitigarlo o risolverlo. Il team esamina le cause principali identificate e le azioni di follow-up che impediranno il ripetersi dell’incidente. Questa operazione è nota come retrospettiva interna degli incidenti di servizio. Le retrospettive degli incidenti vengono condivise pubblicamente solo per gli incidenti di gravità elevata.

Per garantire trasparenza e inclusione a tutti i team Zendesk, è disponibile un calendario retrospettivo interno Zendesk in modo che possano partecipare alla riunione retrospettiva interna e ottenere maggiori informazioni sugli incidenti di servizio e sulle cause principali. Gli esiti degli incidenti vengono condivisi con tutti i team tecnici e gli esiti significativi degli incidenti vengono evidenziati ed esaminati durante la riunione tecnica settimanale di Zendesk.

Ci sono quattro attività principali eseguite in una retrospettiva di un incidente di servizio:

Esamina i dettagli dell’incidente contenuti nel Documento dell’incidente per ancorare e orientare i partecipanti all’incidente
Rivedere e convalidare i risultati dell’analisi delle cause principali contenuti nel documento dell’incidente
Identifica e categorizza qualsiasi intervento di riparazione necessario affinché i team di progettazione Zendesk affrontino completamente le cause principali che portano all’incidente del servizio. Tutti gli elementi di riparazione vengono concordati con il consenso dei partecipanti alla retrospettiva
Assegna il lavoro di riparazione ai team di progettazione appropriati con SLA chiari e appropriati definiti.

Analisi degli incidenti con gravità elevata

Una volta risolto un incidente di gravità elevata, il responsabile dell’incidente pianifica una riunione retrospettiva che include:

Tutti i membri del team che hanno partecipato alla risposta all’incidente
I tecnici dei team i cui prodotti o servizi sono stati interessati dall’incidente
Team che detengono la proprietà o investono interessi come:

l’assistenza clienti Zendesk
Team di prodotto
I leader che possiedono prodotti, servizi e aree di assistenza interessati

Viene fatto ogni sforzo per tenere la riunione retrospettiva dell’incidente entro 72 ore dalla risoluzione dell’incidente, tenendo conto che la tempistica della riunione dipenderà dalla complessità della causa principale e dalla disponibilità dei membri del team nelle aree geografiche.

Dopo aver pianificato la retrospettiva dell’incidente, il responsabile tecnico documenta l’analisi della causa principale e crea il documento dell’incidente in base alle seguenti categorie:

Panoramica incidente
Impatto sui clienti
Descrizione tecnica
Informazioni sulla causa principale e sul servizio
Dettagli e tempistiche dell’incidente
Rimedi

Il Documento sull’incidente guida la retrospettiva dell’incidente e acquisisce qualsiasi intervento di riparazione identificato per risolvere completamente i problemi alla base dell’incidente.

È disponibile un’ulteriore fase di analisi per gli incidenti di gravità 0-3 nota come analisi della causa principale. Questa analisi offre al team tecnico la possibilità di comprendere e documentare l’incidente e definire il lavoro necessario per risolvere completamente i problemi. Queste informazioni vengono acquisite nel documento incidente.

Processo di analisi della causa principale dell’incidente Zendesk

Analisi degli incidenti a bassa gravità

Gli incidenti con gravità bassa passano attraverso una causa principale e una fase di report più snella rispetto agli incidenti con gravità elevata. Sebbene non venga completata una riunione formale retrospettiva sugli incidenti (a meno che non sia richiesto dal proprietario dell’ingegneria del prodotto) per gli incidenti di bassa gravità, il proprietario dell’ingegneria del prodotto crea un documento dell’incidente.

Le cause principali vengono identificate, classificate e condivise con i team di progettazione e gli elementi correttivi vengono aggiunti al backlog del team di progettazione del prodotto con gli SLA. Come per gli incidenti di gravità più elevata, Zendesk cerca di apprendere e migliorare i nostri processi di progettazione in seguito a un'analisi approfondita degli incidenti di gravità inferiore.

Poiché gli incidenti di gravità 3 hanno un impatto minore sui clienti, lo stato del problema e le soluzioni correttive identificate vengono condivisi con i clienti interessati che hanno contattato l’assistenza clienti Zendesk tramite un ticket Zendesk.

Gli incidenti di gravità 4 per definizione non hanno un impatto diretto sui clienti. L’analisi post-incidente non viene comunicata ai clienti, ma le cause principali vengono identificate e le soluzioni vengono affrontate internamente usando i processi e le procedure sopra descritti.

Assegnazione di elementi di riparazione

Per garantire il completamento degli elementi di riparazione, il team di progettazione del prodotto esamina gli elementi di riparazione convalidati nella retrospettiva ed esegue le azioni seguenti:

Classifica le soluzioni come Preventive o Generali:

Gli elementi preventivi sono quelli che prevengono attivamente il ripetersi dell’incidente
Gli elementi generali non sono solo preventivi di per sé, ma risolvono una parte fondamentale delle circostanze dell'incidente
Assegna la priorità alle soluzioni per impostare gli SLA di risposta. Questo esercizio comprende le seguenti attività:

Identifica i team tecnici responsabili dell’elaborazione dell’elemento di riparazione
Collega l’elemento di riparazione alla causa principale identificata a cui si rivolge
Aggiungi l’elemento di riparazione al backlog di lavoro del team tecnico responsabile
Aggiungi l’elemento di riparazione al report SLA di progettazione per monitorare il raggiungimento degli SLA

Di seguito è riportato un grafico che i team di progettazione del prodotto usano per determinare quando una soluzione è prioritaria e pianificata per il loro lavoro.

SLA Zendesk Remediation Item Priority

Il team dell’assistenza clienti Zendesk che partecipa alla retrospettiva crea le descrizioni rivolte ai clienti degli incidenti, delle cause principali e delle eventuali soluzioni identificate. Questo è pubblicato in Articolo del Centro assistenza associato all’incidente.

Esempio di incidente di disponibilità del servizio Continua

Ecco come è stata condotta una retrospettiva per questo incidente.

4 giorni lavorativi dopo il verificarsi dell’incidente, il team di risposta agli incidenti e i tecnici si sono riuniti per esaminare l’incidente, collaborare alle cause principali e creare o aggiornare gli elementi di riparazione. Tutti gli elementi correttivi vengono accettati in base al consenso dei partecipanti alla riunione.

Ogni persona coinvolta nell’incidente ha avuto un ruolo nella retrospettiva dell’incidente:

I dettagli esaminati e discussi durante la riunione includevano:

Area	Esempio
Cronologia	20:02 UTC - Nuove versioni del contenitore distribuite ai servizi host con certificati aggiornati 20:08 UTC - Vengono visualizzati gli avvisi di connettività del container 20:37 UTC - Prima evidenza che i servizi non sono in grado di connettersi ai nuovi container, causando così un ritardo/interruzione del servizio 20:57 UTC - Il servizio interno Zendesk interrompe l’elaborazione delle richieste, causando errori di timeout nelle applicazioni Support, Guide & Talk ospitate nel pod 17 21:02 UTC - La scalabilità automatica del cluster inizia a creare nuovi contenitori per i servizi che non possono essere raggiunti 21:07 UTC - Completamento del provisioning completo dei contenitori di servizi compatibili con le configurazioni dei servizi esistenti 21:49 UTC - Pulizia dei contenitori irraggiungibili completata 22:07 UTC - L’incidente è stato completamente risolto
Cause principali	Dopo la modifica del servizio certificati di sicurezza, i contenitori non sono stati ricostruiti per raccogliere le modifiche codificate nello script. I container non ridistribuiti non facevano riferimento al provider di certificati di sicurezza corretto e non erano considerati attendibili da altri servizi e container Zendesk
Fattori di influenza	Non abbiamo aggiornato gli script di distribuzione per fare riferimento correttamente al nuovo provider di certificati di sicurezza durante la creazione di nuovi contenitori Ha distribuito i nuovi contenitori troppo rapidamente e ampiamente per poterli adattare dopo che si sono verificati errori Nessuna funzionalità di ripristino automatico
Rimedi	Cambia il modo in cui viene valutata la conformità dei certificati di sicurezza quando vengono creati e distribuiti nuovi container Aggiungi un metodo diverso e più affidabile per la verifica dei certificati prima di avviare nuove istanze Documenta la strategia di distribuzione per l’infrastruttura con scalabilità orizzontale Abilita il rollback automatico delle distribuzioni in caso di avvisi Scopri come l’ingegneria della piattaforma può ricostruire i componenti dell’infrastruttura con maggiore frequenza Scopri come rendere più distribuita e tollerante ai guasti un’infrastruttura critica

Affinché ci fosse un’analisi approfondita per generare azioni concrete per il team tecnico, tutti i membri del team hanno fornito input per raccontare l’incidente e sviluppare attività di riparazione. Una volta che tutte le domande o i problemi sono stati risolti dal team di risposta agli incidenti, la retrospettiva degli incidenti è stata considerata completa.

Al termine della riunione retrospettiva interna è stato chiesto al responsabile dell’assistenza clienti Zendesk responsabile della retrospettiva degli incidenti pubblici se avesse domande o se avesse bisogno di ulteriori informazioni da parte del team per creare la documentazione pubblica. Non ha avuto ulteriori domande e ha aggiunto le informazioni retrospettive seguenti all’articolo relativo all’incidente di servizio pubblico nella sezione Notifiche di servizio in il nostro centro assistenza.

Informazioni retrospettive pubbliche per l’incidente VM di disponibilità del servizio

I tre risultati importanti di questa retrospettiva sugli incidenti che hanno migliorato i prodotti e i servizi Zendesk sono stati:

Le cause principali dell’incidente sono state identificate e saranno prese in considerazione da tutti i team dei prodotti Zendesk nello sviluppo futuro

Le soluzioni sono state identificate e assegnate ai team di progettazione con SLA

La retrospettiva pubblica è stata pubblicata dall’assistenza clienti Zendesk nel Centro assistenza ed è stata inviata ai clienti interessati che hanno inviato ticket

Chiusura di un incidente di servizio

Come best practice, Zendesk chiude tutti i ticket aperti con i clienti per assicurarsi che tutto sia adeguatamente documentato e comunicato per l’incidente.

Tutti gli incidenti di servizio completati sono riepilogati in un report digest settimanale degli incidenti di servizio, ampiamente condiviso in Zendesk. Le descrizioni degli incidenti, l’impatto sui clienti e le soluzioni importanti sono inclusi in questo report e sono anche inclusi in un report di verifica delle operazioni bisettimanale condiviso con il team esecutivo di Zendesk.

Dopo che le informazioni retrospettive sono state pubblicate nel Centro assistenza e i ticket aperti sono stati aggiornati con i risultati della retrospettiva, la fase di analisi e report per l’incidente del servizio è considerata completa. L’assistenza clienti Zendesk collega i ticket all’incidente del servizio e vengono contrassegnati come chiusi.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.