Escalation policy per una gestione efficace degli imprevisti

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.

Usa la tua escalation policy 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 tua programmazione 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 escalation policy 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 escalation policy.

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.