Escalation policy per una gestione efficace degli imprevisti

Quando si verifica un imprevisto, la migliore delle ipotesi è che il tuo tecnico su chiamata o lo SRE possano risolverlo rapidamente e autonomamente. 

Certo, nel mondo reale, non è sempre così. A volte la risoluzione richiede un team più ampio, conoscenze specializzate o competenze più avanzate. Ecco perché qualsiasi organizzazione con più di due professionisti del settore tecnologico ha bisogno di un piano e di una policy per l'escalation degli imprevisti.

Cos'è l'escalation degli imprevisti?

L'escalation degli imprevisti si verifica quando un dipendente non è in grado di risolvere un imprevisto da solo e deve affidare il task a un dipendente più esperto o specializzato.

Cos'è una policy di escalation?

Una policy di escalation risponde alla domanda sulla modalità con cui la tua organizzazione gestisce questi passaggi di consegne. Indica chi deve essere avvisato quando arriva un avviso di imprevisto, a chi deve essere passato un imprevisto se il primo addetto alla risposta non è disponibile, chi dovrebbe subentrare se o quando l'addetto alla risposta non riesce a risolvere il ticket da solo e come dovrebbe avvenire il passaggio di consegne (tramite il service desk? direttamente da un tecnico all'altro? mediante uno strumento di gestione degli imprevisti?).

A prima vista, queste domande sembrano semplici, ma più grande è la tua organizzazione e più complesso è il tuo ecosistema tecnologico, più le risposte devono essere dettagliate. Ad esempio, una volta identificata la persona che deve essere avvisata quando arriva un avviso di imprevisto, la risposta può variare in base non solo a chi è reperibile o disponibile, ma anche in base ai livelli di gravità, alla durata dell'imprevisto, ecc. 

Per alcune aziende, è possibile che esista una sola persona reperibile che deve essere avvisata per prima indipendentemente dalla gravità dell'imprevisto. Per altre, potrebbe avere senso avvisare uno sviluppatore junior se l'imprevisto ha un livello di gravità 3 e avvisare una persona più anziana o un team specializzato se si tratta di imprevisto con gravità di livello 1.

Allo stesso modo, alcune aziende potrebbero fare affidamento sul primo addetto alla risposta per eseguire, se necessario, l'escalation di un imprevisto. Altre potrebbero attivare un'escalation automatica a uno sviluppatore più esperto a un team specializzato se un imprevisto supera un determinato periodo di tempo o inizia a influire su un numero maggiore di sistemi o utenti.

Una policy di escalation dovrebbe occuparsi non solo del modo in cui la tua azienda eseguirà l'escalation degli imprevisti e di chi li riceverà, ma anche delle possibili differenze di trattamento in base al tipo di imprevisto, al livello di gravità, alla durata e all'ambito dell'imprevisto.

Processi di escalation degli imprevisti

Per le aziende che seguono le best practice ITSM, in genere il service desk è al centro dell'escalation degli imprevisti. Se il primo addetto alla risposta non riesce a risolvere un imprevisto, l'imprevisto torna al service desk, che lo passa alla linea di difesa appropriata successiva. Utilizzando Jira Service Management, gli addetti alla risposta possono inoltrare gli imprevisti all'interno del ticket dell'imprevisto. Gli addetti alla risposta hanno accesso ai flussi di lavoro per guidare il processo di risoluzione e possono implementare l'automazione o personalizzare le azioni secondo necessità. La definizione di un livello di gravità può indirizzare gli addetti alla risposta al flusso di lavoro appropriato.

Altre società, come Google, affidano a uno SRE la responsabilità degli imprevisti e quella persona è responsabile di ogni eventuale escalation necessaria (oltre che del congelamento dei nuovi rilasci nel caso in cui un imprevisto spinga il team oltre la soglia di inattività accettabile in base al proprio SLA/SLO).

Per altre società ancora, il primo addetto alla risposta può essere uno sviluppatore o un gestore imprevisti oppure possono esserci più primi punti di contatto (soprattutto quando l'avviso segnala un imprevisto di elevata gravità) e l'escalation può verificarsi attraverso processi predefiniti direttamente all'interno e tra questi team.

Sia che il processo passi attraverso il service desk, sia facilitato da uno SRE o avvenga automaticamente all'interno dei tuoi sistemi di tracciamento degli imprevisti, in genere le escalation policy seguono tre percorsi.

Escalation gerarchica

L'escalation gerarchica si verifica quando un imprevisto viene trasmesso a un team o a una persona in base al suo livello di esperienza o anzianità all'interno dell'organizzazione. 

Ad esempio, il primo addetto alla risposta reperibile potrebbe essere uno sviluppatore junior appena entrato nel team. In un'organizzazione gerarchica, se quest'ultimo non riesce a risolvere un ticket, lo trasmette a uno sviluppatore più anziano. Se anche lo sviluppatore più anziano non riesce a risolverlo, viene trasmesso a uno sviluppatore ancora più anziano e si procede così finché il ticket non viene risolto.

Escalation funzionale

L'escalation funzionale si verifica quando un imprevisto viene trasmesso a un team o a una persona più preparata per risolverlo in base alle sue competenze o conoscenze dei sistemi e non alla sua anzianità. 

Ad esempio, il primo addetto alla risposta reperibile potrebbe essere uno sviluppatore junior di un team che si concentra sul back-end del prodotto X. Se quest'ultimo scopre che il problema principale sembra derivare da un'integrazione con il prodotto Y, potrebbe eseguire l'escalation dell'imprevisto a un altro sviluppatore junior del team del prodotto Y.

Escalation automatica

Per i team che lavorano con una piattaforma come Opsgenie, puoi anche impostare regole che dicono al sistema di eseguire automaticamente l'escalation di un imprevisto se la persona reperibile principale non riconosce o non chiude un avviso.

Alcuni team possono preferire un metodo di escalation rispetto a un altro, ma i vari metodi non si escludono a vicenda e molti team utilizzano un mix di escalation gerarchica, funzionale e automatica.

La matrice di escalation

Una matrice di escalation è un documento o un sistema che definisce quando deve avvenire l'escalation e chi deve gestire gli imprevisti a ogni livello. 

Il termine è usato in diversi settori. Le risorse umane possono avere una matrice di escalation per i ticket interni. I call center possono avere una matrice di escalation per i ticket del servizio clienti. E i team IT e DevOps potrebbero disporre di una o più matrici che aiutano gli ingegneri a sapere come e quando eseguire l'escalation di un imprevisto. 

Il livello di dettaglio in una matrice varia notevolmente da un'azienda all'altra. Alcune organizzazioni potrebbero avere un semplice diagramma gerarchico, con ogni sviluppatore che esegue l'escalation a un altro sviluppatore con un livello di competenza più elevato, se necessario. Altre organizzazioni potrebbero disporre di matrici specifiche per la situazione che indicano agli sviluppatori quali team contattare per diversi tipi di imprevisti o diversi livelli di gravità. Come per la maggior parte degli aspetti della gestione degli imprevisti, non esiste una risposta valida per tutti su come sviluppare la matrice della tua organizzazione.

Buone pratiche per lo sviluppo di una policy di escalation

Usa la tua policy di escalation come una linea guida, non come un insieme di regole rigide

La tecnologia non è statica e non lo sono nemmeno i tuoi team. Google suggerisce che se il tuo SRE ritiene che un caso specifico richieda una strategia di escalation diversa, devi concedergli la libertà di esprimere quel giudizio. Il punto qui non è creare regole rigide, ma piuttosto linee guida che possano essere applicate nella maggior parte delle situazioni.

Verifica regolarmente la tuaprogrammazione su chiamata

Ci sono delle lacune nella programmazione? Hai le persone giuste in servizio? Hai le persone giuste nel tuo secondo e terzo livello di servizio su chiamata? Le tue programmazioni su chiamata e la tua policy di escalation dovrebbero lavorare di concerto per accelerare la gestione degli imprevisti.

Imposta soglie intelligenti per l'escalation

Non tutti gli imprevisti sono uguali, il che significa che non tutti gli imprevisti possono o devono seguire la stessa policy di escalation. 

Per gli imprevisti minori, potresti non voler avvisare il tecnico su chiamata fino al normale orario di lavoro. Per gli imprevisti gravi, probabilmente hai bisogno di quel tecnico a prescindere dall'orario. In caso di imprevisti multipli, il tuo tecnico dovrà sapere di quale imprevisto occuparsi per primo e/o se deve eseguire immediatamente l'escalation di un imprevisto a un secondo tecnico.   

Occorre trovare un equilibrio tra garantire che i sistemi abbiano la massima operatività e rispettino le promesse dello SLA e gli obiettivi dello SLO e assicurarsi che gli ingegneri non siano esausti, oberati di lavoro, privi di sonno e soggetti a un forte stress da avvisi.

Stabilisci procedure chiare per l'escalation

Lo sviluppatore che esegue l'escalation deve contattare direttamente il team o la persona appropriata o deve rivolgersi all'help desk? Esiste un sistema che lo sviluppatore dovrebbe usare? Come monitorerai l'escalation? Il primo addetto alla risposta ha la responsabilità di assicurarsi che l'imprevisto venga rilevato dalla persona successiva?

La tua policy deve rispondere con chiarezza a queste domande e tali risposte devono essere fornite a tutti gli sviluppatori su chiamata affinché la procedura di escalation proceda senza intoppi e gli imprevisti vengano risolti con maggiore rapidità.

Scopri di più su come Jira Service Management può arricchire le tue pratiche di gestione degli imprevisti offrendo una soluzione collaborativa all'escalation degli imprevisti per velocizzare i tempi di risoluzione.