Gestione degli incidenti, parte 2: Come Zendesk gestisce gli incidenti di servizio

Questa è la parte 2 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 (questo articolo)
• Parte 3: Monitoraggio di un incidente pubblico del servizio Zendesk
• Parte 4: Analisi e report degli incidenti successivi alla soluzione

In questo articolo, parte 2, imparerai a comprendere how i team Zendesk rispondono agli incidenti di servizio all’interno dei nostri prodotti in base ai livelli di gravità. Zendesk adotta un approccio completo per comprendere un incidente, dalla causa principale all'impatto totale sui clienti interessati, e comunica il livello di dettaglio appropriato.

L’articolo include le seguenti sezioni:

• Gravità dell’incidente
• Struttura del team di risposta agli incidenti
• Cronologia delle comunicazioni per gli incidenti
• Processo di incidente a bassa gravità

Gravità dell’incidente

Una delle decisioni chiave prese quando viene creato un incidente di servizio è l’assegnazione della gravità dell’incidente. La gravità di un incidente determina come e quali team Zendesk affrontano il problema e come viene comunicato ai clienti interessati.

Zendesk usa un sistema che raggruppa gli incidenti di servizio in 5 livelli di gravità in base alle caratteristiche dell'incidente:

Sistema di valutazione della gravità Zendesk

Diversi percorsi di escalation e team vengono coinvolti per indagare, comunicare e risolvere l’incidente in base al livello di gravità. Ciò garantisce il giusto livello di rigore a ciascun incidente. Il diagramma seguente descrive le attività chiave che si verificano durante e dopo la cancellazione di un incidente in base al suo livello di gravità:

Processo per livello di gravità

Sebbene gli incidenti di alta gravità siano sottoposti a rigorose attività di analisi e soluzione, ogni incidente, indipendentemente dal livello di gravità, viene sottoposto a una risposta in tempo reale e a un processo di indagine. Ciò produce:

• Aggiornamenti alla pagina distato Zendesk quando l’incidente è pubblico
• Analisi delle cause principali e soluzioni degli incidenti
• Report sugli incidenti Zendesk (interno).

Esempio di incidente di disponibilità del servizio Zendesk

Ecco un esempio di come la gravità degli incidenti viene impostata da Zendesk e di come i team Zendesk rispondono internamente:

Esempio di individuazione e risposta di incidente

Nell’esempio, viene visualizzato il seguente workflow:

1. Il centro operativo di rete Zendesk (ZNOC) ha identificato un problema quando gli avvisi di sistema mostravano che i nodi di servizio nel Pod 17 non potevano essere raggiunti dalle richieste. Il team Zendesk Network Engineering ha verificato che i problemi di accesso interessavano direttamente i servizi clienti e si è subito reso conto che i servizi Support, Guide e Talk per più clienti non funzionavano come previsto. È stato creato un nuovo incidente di servizio Zendesk.
2. Era noto che questo incidente riguardava due clienti quando è stato creato inizialmente, ma a causa della natura dell’interruzione, un numero maggiore di clienti ha riscontrato il problema e ha iniziato a segnalare i propri problemi con l’assistenza clienti Zendesk. Il team tecnico ha assegnato all’incidente una valutazione di gravità pari a 1, un incidente con priorità alta che richiede un’attenzione immediata. 
3. Il team di risposta agli incidenti è stato contattato immediatamente. Nel giro di pochi minuti dalla creazione dell’incidente, un responsabile dell’incidente ha raccolto informazioni e raccolto ulteriori risorse di progettazione per risolvere e risolvere l’incidente del servizio.

Struttura del team di risposta agli incidenti

Zendesk dispone di un team globale dedicato alla risposta agli incidenti per garantire che ogni incidente sia guidato attraverso il processo di gestione degli incidenti del servizio e portato ai livelli appropriati di leadership Zendesk, come garantito. 

Ruoli e responsabilità della gestione degli incidenti

Questa struttura del team consente a Zendesk di condurre un'analisi approfondita dell'incidente con risorse tecniche e di comunicare in tempo reale ai clienti tramite l'assistenza clienti Zendesk. 

Cronologia delle comunicazioni per gli incidenti

Zendesk si impegna a garantire che gli incidenti siano adeguatamente comunicati e risolti nei tempi appropriati per il cliente. Abbiamo stabilito delle tempistiche interne per la distribuzione dei dettagli degli incidenti. La sequenza temporale si basa sul livello di gravità dell’incidente e sulle fasi di gestione degli incidenti del servizio.

Fase	Tempistiche di risposta
Annuncio pubblico	Chiamata entro 15 minuti dall’incidente
Aggiornamenti incidenti	Ogni 30 minuti fino al ripristino del servizio o alla disponibilità di nuove informazioni
Analisi eventi  (per incidenti di gravità 0 e 1)	Entro 48 ore dalla soluzione dell’incidente
Analisi della causa principale	Entro 72 ore dalla soluzione dell’incidente
Retrospettiva sugli incidenti pubblici	Entro 96+ ore dalla soluzione dell’incidente

Gli incidenti con un livello di gravità compreso tra 0 e 2 sono considerati alti incidenti di gravità. Quando si verifica un incidente di gravità elevata, il team globale di risposta agli incidenti è disponibile 24 ore su 24, 7 giorni su 7 per rispondere a questi incidenti. Il team è composto dai seguenti ruoli:

Ruoli del team di risposta agli incidenti

Ubicazioni del team globale di risposta agli incidenti

Quando il team reperibile viene chiamato, la diagnosi dell’incidente inizia entro pochi minuti dalla dichiarazione dell’incidente. Vengono creati un canale Slack e una chiamata Zoom per consentire la comunicazione del team di risposta in tempo reale. Man mano che il team di risposta agli incidenti valuta l’incidente e valuta l’ambito, i team tecnici reperibile vengono chiamati in base ai prodotti e ai servizi interessati.

Un post pubblico nella pagina di stato di Zendesk viene effettuato entro 15 minuti dalla creazione dell’incidente per informare i clienti sull’incidente noto. Successivamente, gli aggiornamenti vengono pubblicati ogni 30 minuti fino a quando non saranno disponibili nuove informazioni. A seconda del problema e del numero di nuove informazioni identificate, questa cadenza può essere ridotta o allungata in base alle esigenze.  I clienti possono monitorare gli incidenti di servizio attivi nella pagina Stato Zendesk, procedura descritta in parte 3 di questa guida.

Oltre ai team globali di risposta agli incidenti disponibili, Zendesk ha definito procedure per la notifica e l’escalation della leadership. Se un incidente di gravità elevata soddisfa determinati criteri, abilitiamo il livello di risposta successivo, ovvero la gestione delle crisi.

Esempio di incidente di disponibilità del servizio Zendesk continua

Continuando a usare l’incidente di disponibilità del servizio come esempio, ecco come è andata avanti la risposta all’incidente attraverso il processo di gestione degli incidenti in Zendesk:

Tempistica di risposta agli incidenti di disponibilità del servizio

Come puoi vedere nell’esempio, una volta creato l’incidente nel portale incidenti Zendesk, sono state intraprese una serie di azioni automatizzate:

• Il team di pronto intervento per la risposta agli incidenti è stato chiamato per rispondere all’incidente

• È stato creato automaticamente un canale Slack per incidenti e il team di risposta agli incidenti è stato aggiunto al canale Slack dedicato

• Una chiamata Zoom è stata avviata automaticamente e pubblicata sul canale Slack per consentire a tutti i risponditori di partecipare

• È stato creato automaticamente un documento di riepilogo dell’evento per documentare l’incidente e condividere i progressi internamente in Zendesk

Durante la chiamata Zoom, il responsabile dell’incidente ha convalidato la gravità iniziale e ha confermato l’ambito e l’impatto del problema. 

È stato rapidamente stabilito che più nodi contenitore nel Pod 17 non erano accessibili e non potevano essere usati dai servizi dipendenti, inclusi i prodotti Support, Guide e Talk. Un tipo di nodo in particolare non aveva repliche disponibili in altri pod. Ciò potrebbe causare la mancata risposta di questi prodotti per più clienti.

Lo ZNOC ha contattato il team tecnico di rete appropriato per la chiamata Zoom per iniziare a indagare su come risolvere il problema immediato del ripristino dell’accesso al servizio e all’API per i clienti.  Anche le PMI di ingegneria perimetrale sono state contattate e hanno aderito alla chiamata. Nel giro di 5 minuti, è stata identificata e distribuita una soluzione in modo che i nodi interessati fossero nuovamente accessibili alle chiamate e ai servizi API. 

L’assistenza clienti Zendesk ha creato un ticket di problema per tenere traccia delle segnalazioni dei clienti. Questo ticket è stato aggiunto al canale Slack dell’incidente per consentire l’aggiunta rapida di nuovi report non appena arrivano.

Mentre le indagini proseguivano, il responsabile dell’escalation degli incidenti ha creato e pubblicato il primo aggiornamento pubblico dello stato Zendesk pochi minuti dopo la creazione dell’incidente. 

Pubblicazione del primo incidente di disponibilità del servizio nella pagina di stato del sistema Zendesk

Mentre i team indagavano sull’incidente, le segnalazioni dei clienti pervenute erano collegate al ticket del problema principale associato all’incidente. Ciò ha consentito al team di risposta agli incidenti di inviare aggiornamenti a tutti i clienti interessati quando inviavano notifiche pubbliche.

Il team tecnico della rete ha stabilito che la modifica del modo in cui i certificati venivano generati e usati era responsabile dell’incidente e ha intrapreso le seguenti azioni per ripristinare il servizio per i clienti interessati:

• Nodi irraggiungibili disattivati

• Creati nuovi nodi di servizio con certificati referenziati correttamente

• Verificato che i nuovi nodi di servizio fossero accessibili per i servizi e tramite chiamate API

• Abbiamo monitorato il traffico in ingresso per verificare che le richieste in ingresso venissero gestite correttamente

Con il progredire dell’incidente, sono stati apportati altri due aggiornamenti pubblici: Uno 14 minuti dopo la creazione dell’incidente e un altro 63 minuti dopo la creazione dell’incidente. La cronologia delle comunicazioni pubbliche e le informazioni retrospettive sugli incidenti pubblicate sono disponibili nella pagina Notifiche di servizio per l’incidente.

Come mostrato nell’esempio, gli incidenti con gravità elevata sono sottoposti a un processo rigoroso in cui vengono determinate le cause principali e vengono creati elementi di soluzione per consentire ai team di progettazione del prodotto di risolvere il problema alla base dell’incidente. Questa analisi viene eseguita durante la nostra retrospettiva sugli incidenti ed è discussa in modo più dettagliato nel Sezione Analisi incidente post soluzione.

Processo di incidente a bassa gravità

Gli incidenti di servizio di gravità inferiore (livello 3-4) sono meno critici perché interessano un numero inferiore di clienti e non impediscono a tali clienti di usare le funzioni aziendali critiche dei prodotti Zendesk. Questi incidenti vengono risolti in base alle linee guida precedenti, ma non vengono pubblicati sui canali pubblici.

Gli incidenti di gravità 3 vengono gestiti più o meno allo stesso modo degli incidenti di gravità 0-2. I tempi di risposta previsti sono estesi a causa del ridotto impatto aziendale. Anche se il team reperibile non viene chiamato, questi incidenti vengono gestiti tramite canali Slack specifici di Zendesk associati ai team di assistenza tecnica dei prodotti e i team tendono a rispondere con la stessa rapidità degli incidenti di gravità maggiore. La maggior parte degli incidenti di gravità 3 non usa canali di comunicazione pubblici. Al contrario, i team dell’assistenza clienti Zendesk contattano i clienti usando notifiche proattive se è necessaria un’azione specifica da parte di un sottoinsieme di clienti.

Gli incidenti di gravità 4 non influiscono direttamente sull’uso dei servizi Zendesk da parte dei clienti, ma potrebbero farlo se non risolti. Questi incidenti vengono creati come risposte proattive a potenziali problemi. I team di progettazione del prodotto interagiscono allo stesso modo del processo di gravità 3.

Ulteriori informazioni

Questo completa la Parte 2, Come Zendesk gestisce gli incidenti di servizio, della Panoramica della gestione degli incidenti in Zendesk.

Per ulteriori informazioni, puoi passare alla parte successiva di questa guida: Parte 3: Monitoraggio di un incidente pubblico del servizio Zendesk. 

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.