Risposta a un imprevisto

Rilevamento

I dipendenti della tua azienda possono venire a conoscenza degli imprevisti in molti modi diversi: avvisi degli strumenti di monitoraggio, segnalazioni dei clienti o osservazione diretta. Quale che sia il modo in cui si verifica un imprevisto, il primo passo che un team intraprende è quello di registrare un ticket per l'imprevisto (nel nostro caso, un ticket Jira).

Generazione di un nuovo imprevisto

Quando la issue dell'imprevisto è stata creata ma non ancora assegnata a un Incident manager (IM), l'imprevisto è in stato nuovo . Questo è lo stato iniziale nel nostro flusso di lavoro degli imprevisti in Jira.

Disponiamo di un servizio che utilizza webhook di Jira per attivare un avviso di convocazione quando viene creato un nuovo imprevisto grave. L'avviso avverte un IM di turno in base al servizio selezionato. Ad esempio, un imprevisto di Bitbucket avverte un Incident manager di Bitbucket. Disponiamo inoltre di un elenco globale di Incident manager noto come "Incident Manager on call" o IMOC.

L'avviso di convocazione include la chiave issue dell'imprevisto, la gravità e il riepilogo, che spiega all'Incident manager da dove iniziare per gestire l'imprevisto (la issue di Jira), la natura generale del malfunzionamento e la gravità.

Apertura delle comunicazioni

La prima azione dell'IM, non appena è online, è di assegnare a se stesso il ticket dell'imprevisto e farlo avanzare allo stato in fase di correzione. Il campo dell'assegnatario nel ticket Jira mostra inoltre l'identità dell'IM corrente. In una risposta di emergenza, è molto importante indicare in modo chiaro chi sia il responsabile, quindi siamo piuttosto rigidi nell'assicurarci che questo campo sia compilato con precisione.

Successivamente, l'IM imposta i canali di comunicazione del team responsabile dell'imprevisto. L'obiettivo ora è organizzare e focalizzare tutte le comunicazioni del team responsabile dell'imprevisto su strumenti ben noti. Normalmente utilizziamo tre metodi di comunicazione per il team, ognuno dei quali è rappresentato da un campo sulla issue di Jira, per ciascun imprevisto:

• Chat in Slack o in un altro servizio di messaggistica. Consente al team di comunicare, condividere osservazioni, link e screenshot in una modalità che prevede la marcatura con data e ora e la memorizzazione. Assegnare al canale chat lo stesso nome dell'identificatore ticket (ad es. HOT-1234) consente un accesso più semplice alla conversazione da parte dei tecnici che devono essere coinvolti.
• Videochat in un'app di videoconferenza come Skype, Blue Jeans o simili; se si è tutti nello stesso ambiente lavorativo, preferiamo riunire il team in una sala. Riteniamo che la comunicazione faccia a faccia permetta ai team di lavorare in modo più rapido e riduca il "botta e risposta".
• Una pagina Confluence denominata "documento sullo stato dell'imprevisto". Quando i tecnici modificano simultaneamente la stessa pagina, possono vedere in tempo reale le informazioni che vengono raccolte. È un ottimo modo per tenere traccia di modifiche (ad esempio, una tabella di chi ha modificato cosa, quando, come, perché; come tornare allo stato precedente, ecc.), flussi di lavoro multipli o una sequenza temporale estesa. Un documento sullo stato dell'imprevisto è estremamente utile come fonte di dati attendibili nel corso di imprevisti complessi o estesi.

Abbiamo notato che utilizzare sia la videochat che la chat fornisce i migliori risultati durante un imprevisto, in quanto entrambi gli strumenti sono ottimizzati per scopi diversi. La videochat eccelle nel creare rapidamente un'immagine mentale condivisa dell'imprevisto attraverso la discussione di gruppo, mentre la chat di testo è ottima per tenere una traccia con sequenza temporale dell'imprevisto, link condivisi alle dashboard, schermate e altri URL.

Questi metodi possono anche essere utilizzati per registrare osservazioni importanti, modifiche e decisioni che avvengono in conversazioni non registrate. L'IM o qualsiasi altro tecnico del team di risposta agli imprevisti è in grado di farlo in modo semplice prendendo nota di osservazioni, modifiche e decisioni nella chat dedicata, man mano che si verificano in tempo reale. È una tecnica molto utile, anche se può dare l'impressione che le persone parlino da sole! Queste annotazioni sono incredibilmente preziose durante l'analisi retrospettiva, quando i team devono ricostruire la sequenza temporale dell'imprevisto e individuarne la causa.

La maggior parte dei sistemi chat dispongono di una funzionalità argomento . L'IM aggiorna l'argomento della chat con informazioni sull'imprevisto e collegamenti utili, tra cui:

• Il riepilogo e la gravità dell'imprevisto.
• Chi ricopre quale ruolo, a partire dall'IM.
• Collegamenti alla issue dell'imprevisto, alla videochat e al documento sullo stato dell'imprevisto.

Questo consente a chiunque abbia la chiave issue di unirsi alla chat ed essere tempestivamente aggiornato sull'imprevisto (ricordiamo che il canale chat ha lo stesso nome della chiave issue dell'imprevisto, ad es. HOT-1234).

Infine, l'IM imposta il proprio stato chat personale sull'identificatore ticket dell'imprevisto che sta gestendo. Questo consente ai colleghi di sapere che l'IM è impegnato nella gestione di un imprevisto.

Valutazione

Dopo che i canali di comunicazione del team addetto alla risoluzione dell'imprevisto sono stati impostati, è il momento di valutare l'imprevisto, in modo che il team possa decidere cosa comunicare riguardo l'imprevisto e chi coinvolgere per correggerlo.

Gli IM rivolgono ai propri team la seguente serie di domande:

• Qual è l'impatto sui clienti (interni o esterni)?
• Cosa stanno notando i clienti?
• Quanti clienti sono interessati (alcuni, tutti)?
• Quando è iniziato il malfunzionamento?
• Quanti casi di supporto hanno aperto i clienti?
• Vi sono altri fattori, ad es. Twitter, sicurezza o perdita di dati?

Ora è un buon momento per iniziare a popolare la sequenza temporale dell'imprevisto. Le osservazioni del team saranno registrate in modo che i tecnici coinvolti possano essere tempestivamente informati. Inoltre, questi particolari saranno importanti in seguito, durante il processo di analisi post mortem. Occorre assicurarsi di annotare se l'ora di inizio dell'imprevisto corrisponda a una modifica (ad esempio, una distribuzione Bamboo) affinché sia possibile eseguire il roll-back della modifica per risolvere eventualmente l'imprevisto.

In base all'impatto dell'imprevisto e alla quantità di lavoro che i nostri team ritengono necessaria per risolverlo, al problema è assegnato uno dei seguenti livelli di gravità:

Invio delle comunicazioni iniziali

Quando si è ragionevolmente sicuri che l'imprevisto è reale, lo si dovrebbe comunicare internamente ed esternamente il prima possibile. L'obiettivo della comunicazione interna iniziale è di focalizzare la risposta agli imprevisti su un unico punto e ridurre la confusione. L'obiettivo della comunicazione esterna è spiegare ai clienti che il malfunzionamento è noto e che lo si sta analizzando con urgenza. Comunicare in modo rapido e accurato gli imprevisti aiuta a creare fiducia nello staff e tra i clienti.

Per le comunicazioni sugli imprevisti utilizziamo Statuspage sia internamente che esternamente. Disponiamo di pagine di stato separate per il personale interno all'azienda e per i clienti esterni. Approfondiremo in seguito in che modo utilizzarle, ma per ora l'obiettivo è aprire un canale di comunicazione il più rapidamente possibile. Per farlo, seguiamo questi modelli:

Riassegna

Hai assunto il comando dell'imprevisto, predisposto le comunicazioni del team, valutato la situazione e comunicato al personale e ai clienti che è in corso un imprevisto. E poi?

I primi a rispondere potrebbero essere tutti i tecnici che ti occorrono per risolvere l'imprevisto, ma più spesso sei tu a dover coinvolgere altri team nella risoluzione dell'imprevisto, contattandoli direttamente. La chiamiamo escalation.

Il sistema cruciale in questa fase è un sistema di turni e segnalazioni di convocazione come OpsGenie. OpsGenie e sistemi analoghi consentono di definire i turni di reperibilità, affinché in ogni team vi sia una rotazione del personale contattabile e disponibile a rispondere in caso di emergenza. Questa scelta è preferibile rispetto all'esigenza di avere una persona specifica occupata a tempo pieno ("chiama di nuovo Bob"), perché i singoli con sempre saranno disponibili (di tanto in tanto, tendono ad andare in ferie, cambiano lavoro o si esauriscono quando li chiami troppo spesso. È inoltre preferibile alla reperibilità "al meglio" perché è chiaro quali siano le persone responsabili della risposta.

Includere sempre la chiave issue Jira dell'imprevisto nella segnalazione di convocazione sull'imprevisto. È la chiave utilizzata dal personale che riceve la segnalazione per collegarsi alla chat dell'imprevisto.

Delega

Dopo aver effettuato l'escalation, i convocati si connettono online e l'IM delega loro un ruolo . Se capiscono le attività richieste al loro ruolo, saranno in grado di lavorare rapidamente ed efficacemente come parte del team coinvolto sull'imprevisto.

I ruoli che utilizziamo in Atlassian sono:

• Gestore imprevisti, descritto nella pagina di panoramica.
• Leader tecnico, un tecnico d'intervento esperto. È responsabile di elaborare teorie sulla natura e sul motivo del malfunzionamento, di decidere le modifiche e di gestire il team tecnico. Lavora a stretto contatto con l'IM.
• Responsabile comunicazioni, una persona che ha familiarità con le comunicazioni pubbliche, meglio se proveniente dal team di assistenza clienti o dalle pubbliche relazioni. È responsabile della redazione e dell'invio di comunicazioni interne ed esterne sull'imprevisto.

Noi usiamo l'argomento della chat per indicare chi attualmente ricopre un determinato ruolo e aggiorniamo l'informazione se durante un imprevisto i ruoli cambiano.

L'IM può anche definire e delegare i ruoli in base alle esigenze dell'imprevisto, ad esempio, incaricando più leader tecnici se è in corso più di un flusso di lavoro, o responsabili comunicazioni interne ed esterne separati.

In caso di imprevisti complessi o di grandi dimensioni, è consigliabile coinvolgere un altro Incident manager qualificato, come "controllo di sicurezza" a supporto dell'IM. Può dedicarsi a compiti specifici che riducono la pressione sull'IM, come mantenere traccia della sequenza temporale.

Invio delle comunicazioni di follow-up

Hai già inviato le comunicazioni iniziali, ma una volta che il team coinvolto sull'imprevisto si sta muovendo, devi aggiornare lo staff e i clienti sulla situazione.

Tenere sempre informato il personale interno è importante perché offre un quadro sempre condiviso dell'imprevisto. Quando si verifica un problema, le informazioni scarseggiano, specialmente durante le prime fasi, e se non si stabilisce una fonte di riferimento attendibile sull'accaduto e sul modo in cui si sta rispondendo, le persone tendono a trarre le proprie conclusioni personali.

Per le comunicazioni interne, noi seguiamo questo schema:

• Comunicare tramite la nostra pagina Statuspage interna e via e-mail, come precedentemente descritto in "Comunicazioni iniziali".
• Utilizzare la stessa convenzione per la formattazione del nome dell'imprevisto e dell'oggetto dell'e-mail ( - - )
• Aprire con un riepilogo di 1-2 frasi circa lo stato corrente e l'impatto.
• Una sezione "Stato attuale" con un elenco di 2-4 punti.
• Una sezione "Prossimi passi" con un elenco di 2-4 punti.
• Indicare quando e dove verrà inviato il giro di comunicazioni successivo.

Utilizziamo questa checklist per verificare la completezza delle comunicazioni:

• Qual è l'impatto effettivo sui clienti?
• Quanti clienti interni ed esterni sono interessati?
• Se la causa primaria è nota, qual è?
• Se è possibile indicare un tempo stimato per il ripristino, qual è?
• Quando e dove verrà effettuato il prossimo aggiornamento?

Incoraggiamo i nostri Incident manager a essere espliciti riguardo alle incognite nelle loro comunicazioni interne. Questo permette di ridurre l'incertezza. Ad esempio, se non si conosce ancora quale sia la causa primaria, è preferibile dire "la causa primaria è attualmente sconosciuta" piuttosto che limitarsi a non fare alcun cenno ad essa.

L'aggiornamento dei clienti esterni è importante, perché aiuta a creare fiducia. Benché interessati dal problema, saranno in grado di proseguire con altri impegni, purché sappiano che verranno tenuti aggiornati.

Per le comunicazioni esterne semplicemente aggiorniamo l'imprevisto aperto in precedenza su Statuspage esterna, cambiando in modo appropriato il suo stato. Cerchiamo di mantenere gli aggiornamenti "brevi e concisi" perché i clienti esterni non sono interessati ai dettagli tecnici dell'imprevisto - vogliono solo sapere se il problema è stato già corretto e, in caso contrario, quando lo sarà. Generalmente, 1-2 frasi saranno sufficienti.

Le comunicazioni sugli imprevisti sono un'arte: maggiore è la pratica, migliori risulteranno. Nell'addestramento dei nostri Incident manager, simuliamo un ipotetico imprevisto, scriviamo le relative comunicazioni e le leggiamo al resto della classe. Questo è un buon modo per costruire l'abilità necessaria prima di farlo sul serio. È anche sempre una buona idea chiedere a qualcun altro di rivedere le comunicazioni, come "secondo parere", prima di inviarle.

Rivedi

Non esiste un unico processo prescrittivo che risolve tutti gli imprevisti; se ci fosse, sarebbe sufficiente automatizzarlo e il lavoro sarebbe concluso. Noi, invece, iteriamo la procedura seguente per adattarci rapidamente a una varietà di scenari di risposta agli imprevisti:

• Osservare che cosa sta succedendo. Condividere e verificare le osservazioni.
• Sviluppare teorie sui motivi di ciò che sta succedendo.
• Sviluppare esperimenti che dimostrino o confutino queste teorie. Svolgere tali esperimenti.
• Ripetere.

Ad esempio, si osserva un elevato tasso di errore in un servizio correlato a un errore che il provider dell'infrastruttura regionale o locale ha pubblicato nella sua Statuspage. Si può teorizzare che l'errore è isolato in questa regione, decidere di eseguire il failover in un'altra regione e osservarne i risultati.

Le maggiori sfide per l'IM, a questo punto, riguardano il saper mantenere la disciplina del team:

• Il team sta comunicando in modo efficace?
• Quali sono al momento le osservazioni, le teorie e i flussi di lavoro?
• Stiamo prendendo decisioni in modo efficace?
• Stiamo apportando modifiche in modo deliberato e attento? Sappiamo quali modifiche stiamo apportando?
• I ruoli sono chiari? Le persone stanno facendo il loro lavoro? Abbiamo bisogno di fare escalation su altri team?

In ogni caso, mai farsi prendere dal panico: non aiuta. Resta calmo e il resto della team seguirà l'esempio.

L'IM deve sorvegliare attentamente l'affaticamento dello staff e pianificare i passaggi di consegne. Un team dedicato può rischiare di bruciarsi durante la risoluzione di imprevisti complessi - Gli IM devono prestare attenzione e sapere per quanto tempo i membri sono rimasti svegli e per quanto tempo hanno lavorato sull'imprevisto, e decidere chi ricoprirà i loro ruoli in un secondo momento.

Risoluzione

Un imprevisto è risolto qua l'impatto attuale o imminente sul business è terminato. A quel punto, la risposta all'emergenza si conclude e il team passa a alle eventuali attività di ripulitura e post mortem.

Le attività di ripulitura possono essere facilmente collegate e tracciate come collegamenti a problemi dalla issue Jira dell'imprevisto.

In Atlassian, utilizziamo i campi personalizzati di Jira per tenere traccia del tempo di inizio dell'impatto, del tempo di rilevamento e del tempo di fine dell'impatto di ogni imprevisto. Impieghiamo questi campi per calcolare il tempo di recupero (TTR), ossia l'intervallo tra l'inizio e la fine, e il tempo di rilevamento (TTD), ossia l'intervallo tra l'inizio e il rilevamento. La distribuzione dei TTD e TTR di un imprevisto è spesso una metrica aziendale importante.

Inviamo comunicazioni interne ed esterne definitive quando l'imprevisto è risolto. Le comunicazioni interne riportano un riepilogo dell'impatto e della durata dell'imprevisto, incluso quanti casi di supporto sono stati aperti e altre importanti dimensioni dell'imprevisto, e indichiamo chiaramente che l'imprevisto è stato risolto e che non vi saranno ulteriori comunicazioni a riguardo. Le comunicazioni esterne sono di solito brevi e informano i clienti che il servizio è stato ripristinato e che eseguiremo un follow-up post mortem.

Segui il pulsante qui sotto per scoprire in che modo Jira Service Management aiuta i team a eseguire ogni passaggio del processo di risposta, dalla centralizzazione degli avvisi e organizzazione della comunicazione degli imprevisti all'unificazione dei team per una migliore collaborazione fino all'esecuzione delle analisi retrospettive per esaminare le cause principali.