Chiudi
Manuale degli imprevisti Atlassian

Risposta a un imprevisto

Caution alert exclamation point

Risposta a un imprevisto

Le sezioni seguenti descrivono il processo di Atlassian per la risposta agli imprevisti. L'Incident manager (IM) segue questa serie di passaggi per condurre l'imprevisto dal rilevamento alla risoluzione.

Workflow of Atlassian incident response from new to fixing to resolved
Book illustration with a light bulb over it

Panoramica

Definire imprevisti e valori inerenti gli imprevisti. Conoscere gli strumenti giusti e i ruoli del team.

Illustration of different kinds of charts

Analisi post mortem degli imprevisti

Come svolgere un'analisi post mortem senza biasimi, identificare le cause e pianificare interventi correttivi.

Detect

Le persone della tua azienda possono venire a conoscenza di imprevisti in molti modi diversi. Possono essere allertati dagli strumenti di monitoraggio, attraverso segnalazioni dei clienti o osservandoli direttamente. Comunque un imprevisto si verifichi, il primo passo del team è la registrazione di un ticket per l'imprevisto (nel nostro caso, una issue di Jira). 

Utilizziamo un URL breve e semplice da ricordare che reindirizza gli addetti di Atlassian a un portale Jira Service Desk interno. I tecnici possono verificare se vi è già un imprevisto in corso esaminando una dashboard Jira o una macro Jira in Confluence. I team, come il nostro team di assistenza clienti, dispongono di dashboard installati in ubicazioni ben note per monitorare gli imprevisti in corso.

Per ogni imprevisto compiliamo i seguenti campi:

Campo Jira

Tipo

Testo guida

Summary

Testo

Qual è l'emergenza?

Description

Testo

Qual è l'impatto sui clienti? Includi i tuoi dati di contatto in modo che chi risponde possa rintracciarti.

Gravità

Selezione singola

(Collegamento ipertestuale a una pagina Confluence con la nostra scala di gravità) Scegliendo Gravità 2 o 1, ritieni che il problema debba essere risolto immediatamente - le persone verranno contattate.

Servizio in errore

Selezione singola

Il servizio con il malfunzionamento che sta causando l'imprevisto. Formula l'ipotesi migliore, in caso di incertezza. Seleziona "Sconosciuto", se non noto.

Prodotti interessati

Caselle di controllo

Quali prodotti sono interessati da questo imprevisto? Seleziona tutti quelli pertinenti.

Una volta creato l'imprevisto, la sua chiave issue è utilizzata in tutte le comunicazioni interne relative all'imprevisto.

I clienti spesso aprono casi di supporto su un imprevisto che li riguarda. Se i nostri team di assistenza clienti stabiliscono che tutti questi casi si riferiscono a un imprevisto, assegnano un'etichetta a quei casi, corrispondente alla chiave issue dell'imprevisto, per monitorare l'impatto sul cliente e poter più facilmente ricontattare i clienti interessati quando l'imprevisto è risolto.

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, è assegnare a sé la issue dell'imprevisto e far avanzare a in fase di correzione lo stato della issue. Il campo dell'assegnatario nella issue di Jira mostra inoltre l'identità dell'IM corrente. In una risposta di emergenza, è molto importante chiarire chi sia il responsabile, quindi siamo piuttosto rigidi nell'assicurarci che questo campo sia accurato. 

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 altro servizio di messaging. Questo consente al team di comunicare, condividere osservazioni, collegamenti e schermate in una modalità che prevede la marcatura con data e ora e la memorizzazione. Assegnare al canale chat lo stesso nome della chiave issue (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 all'imprevisto è in grado di farlo semplicemente annotando osservazioni, modifiche e decisioni nella chat dedicata , man mano che si verificano in tempo reale. Non è sbagliato, anche se sembra che le persone parlino da sole! Queste annotazioni sono incredibilmente preziose durante la fase post mortem, 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 alla chiave issue 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 incaricato della risoluzione dell'imprevisto sono stati impostati, è tempo 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, alle issue è assegnato uno dei seguenti livelli di gravità

Gravità

Description

Examples

1

Un imprevisto critico con un impatto molto elevato

  • Un servizio rivolto ai clienti, come Jira Cloud, è inattivo per tutti i clienti

  • La riservatezza o la privacy sono state violate.

  • Sì è verificata una perdita di dati dei clienti


2

Un imprevisto grave con un impatto significativo

  • Un servizio rivolto ai clienti non è disponibile per un sottoinsieme di clienti

  • Una funzionalità di base (ad es. push git, creazione di issue) ha subito un impatto significativo.

3

Un imprevisto minore a basso impatto

  • Un piccolo inconveniente per i clienti, soluzione alternativa disponibile.

  • Un degrado delle prestazioni disponibili.

Una volta stabilito l'impatto dell'imprevisto, adattare o confermare la gravità della relativa issue e comunicare tale gravità al team. Riteniamo che numerare il livello è molto utile per comunicare chiaramente la gravità.

In Atlassian, gli imprevisti di gravità 3 vengono trasmessi ai team di delivery per la risoluzione in orario di lavoro, mentre i livelli di gravità 1 e 2 esigono il coinvolgimento dei membri del team per una correzione immediata. La differenza di risposta tra le gravità 1 e 2 è più sfumata e dipende dal servizio interessato.

La matrice di gravità deve essere documentata e concordata tra tutti i team per ottenere una risposta coerente agli imprevisti in base all'impatto sui clienti.

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:

 

Statuspage interna

Statuspage esterna

Nome dell'imprevisto

<Chiave issue dell'imprevisto> - <Gravità> - <Riepilogo dell'imprevisto>

Stiamo effettuando indagini sui problemi di <prodotto>

Messaggio

Stiamo analizzando un imprevisto che riguarda il <prodotto x>, il <prodotto y> e il <prodotto z>. Forniremo aggiornamenti via e-mail e Statuspage a breve.

Stiamo effettuando indagini sui problemi di <prodotto> e forniremo qui aggiornamenti a breve.

Oltre a creare un imprevisto in Statuspage, inviamo un'e-mail a una lista di distribuzione per le comunicazioni degli imprevisti che include la nostra direzione tecnica, i principali Incident manager e altro personale interessato. Questa e-mail ha lo stesso contenuto dell'imprevisto interno in Statuspage. L'e-mail consente al personale di porre domande e rispondere, mentre Statuspage rappresenta più una comunicazione diffusa a senso unico.

Si noti che includiamo sempre la chiave issue Jira dell'imprevisto su tutte le comunicazioni interne relative all'imprevisto, pertanto lo staff sa in quale chat inserirsi per ulteriori domande.

Escalation

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:

  • Incident Manager, 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.

L'aggiornamento del personale interno è importante perché crea una verità costantemente condivisa riguardo l'imprevisto. Quando qualcosa non funziona, le informazioni sono scarse, specialmente durante le prime fasi e, se non si stabilisce una fonte di verità attendibile su quanto accaduto e su come sta procedendo la risposta, le persone tendono a saltare ognuna alle proprie conclusioni. 

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 (<Chiave issue dell'imprevisto> - <Gravità> - <Riepilogo dell'imprevisto>)

  • 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.

Usiamo 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 prescritto che risolve tutti gli imprevisti - se ci fosse, basterebbe automatizzarlo e avremmo finito. Piuttosto, noi 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 riguardo al motivo per cui 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.

Book illustration with a light bulb over it

Panoramica

Definire imprevisti e valori inerenti gli imprevisti. Conoscere gli strumenti giusti e i ruoli del team.

Illustration of different kinds of charts

Analisi post mortem degli imprevisti

Come svolgere un'analisi post mortem senza biasimi, identificare le cause e pianificare interventi correttivi.

Cerchi uno strumento che ti aiuti nel processo di gestione degli imprevisti?