Cos'è una policy di escalation?

Punti chiave: i criteri di escalation definiscono chi viene avvisato quando si attiva un avviso di imprevisto, a chi viene passato l'imprevisto se la persona incaricata di rispondere per prima non è disponibile o non riesce a risolverlo e come avvengono questi passaggi, di solito in base a gravità, durata e ambito.

• Che cos'è: un percorso documentato, spesso riportato in una matrice di escalation, che utilizza tre tipi di escalation, cioè gerarchica (in base al livello di anzianità), funzionale (in base alle competenze) e automatica (in base a una regola, quando un avviso non viene riconosciuto in tempo).

• Perché è importante: senza, gli imprevisti si bloccano mentre le persone cercano di capire chi chiamare, con, la persona giusta viene coinvolta in pochi minuti e non vengono avvertite le persone per la cosa sbagliata.

• Come ti aiuta Jira Service Management: il programma di reperibilità e gli avvisi consentono ai team di definire le regole di escalation per servizio e gravità, eseguire automaticamente l'escalation degli avvisi non confermati ed eseguire l'escalation all'interno del record dell'imprevisto, così ogni passaggio di consegne viene tracciato.

I criteri di escalation sono il piano documentato per ciò che accade quando la prima persona avvisata di un imprevisto non riesce a gestirlo da sola: chi viene avvisato per primo, chi subentra se non è disponibile o non è in grado di risolvere il problema, quanto rapidamente avviene il passaggio di consegne e tramite quale canale. È il corrispettivo di un programma di reperibilità, il programma indica chi è disponibile, i criteri indicano come l'imprevisto passa da una persona all'altra.

Il caso migliore è che l'Ingegnere reperibile risolva un imprevisto da solo. Nei casi in cui per la risoluzione servono un team più ampio, una conoscenza specialistica o competenze più avanzate, spesso qualsiasi organizzazione con più di un paio di persone del team tecnico ha bisogno di un piano di escalation. Questa guida illustra i tipi di escalation, la matrice di escalation e le best practice per scrivere criteri efficaci.

Cos'è l'escalation degli imprevisti?

L'escalation degli imprevisti si verifica quando un dipendente non è in grado di risolvere un imprevisto in autonomia e deve affidare il task a una persona più esperta o specializzata.

Cos'è una policy di escalation?

Le domande sembrano semplici, ma più grande è l'organizzazione e più complesso è l'ecosistema tecnologico, più le risposte devono essere dettagliate. Ad esempio, nel determinare chi occorre avvertire quando arriva un avviso di imprevisto, la risposta può variare non solo in base a chi è reperibile o disponibile, ma anche in base ai livelli di gravità, alla durata dell'imprevisto e altro ancora. 

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 il programma di reperibilità

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 l'ingegnere reperibile fino al normale orario di lavoro. Per gli incidenti gravi, probabilmente hai bisogno di quell'ingegnere, a prescindere dall'ora del giorno. In caso di imprevisti multipli, l'ingegnere dovrà sapere di quale imprevisto occuparsi per primo e se deve eseguire immediatamente l'escalation di un imprevisto a un secondo ingegnere.   

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.