Wat is een escalatiebeleid?

Belangrijkste punten: een escalatiebeleid definieert wie op de hoogte wordt gebracht wanneer er een incidentwaarschuwing afgaat, aan wie het incident wordt doorgeschoven als de eerste contactpersoon niet beschikbaar is of het niet kan oplossen, en hoe die overdrachten plaatsvinden. Dit alles is meestal afhankelijk van de ernst, duur en scope.

• Wat het is: een gedocumenteerd pad, vaak vastgelegd in een escalatiematrix, met drie typen escalatie: hiërarchisch (op basis van anciënniteit), functioneel (op basis van expertise) en automatisch (op basis van een regel, wanneer er niet op tijd wordt gehandeld bij een waarschuwing).

• Waarom dit belangrijk is: zonder zo een beleid lopen zaken vast terwijl mensen uitzoeken wie ze moeten bellen, en met zo een beleid wordt binnen enkele minuten de juiste responder ingeschakeld en wordt niemand voor het verkeerde opgeroepen.

• Hoe Jira Service Management helpt: met een op afroep-rooster en waarschuwingen kunnen teams escalatieregels definiëren per service en ernst, niet-bevestigde waarschuwingen automatisch escaleren en binnen het incidentrapport escaleren, zodat elke overdracht wordt bijgehouden.

Een escalatiebeleid is het vastgelegde plan voor wat er gebeurt wanneer de eerste persoon die voor een incident wordt gewaarschuwd dit niet alleen kan afhandelen: wie als eerste op de hoogte wordt gebracht, wie het overneemt als diegene niet beschikbaar is of het incident niet kan oplossen, hoe snel de overdracht plaatsvindt en via welk kanaal. Het is de tegenhanger van een op afroep-rooster, waarin wordt aangegeven wie beschikbaar is. In het beleid wordt aangegeven hoe het incident tussen die personen wordt doorgegeven.

In het beste geval lost de beschikbare engineer zelfstandig een incident op. Het komt vaker voor dat je een groter team, gespecialiseerde kennis of meer geavanceerde vaardigheden nodig hebt om het incident op te lossen. Elke organisatie met meer dan een paar technische medewerkers heeft een escalatieplan nodig. In deze gids behandelen we de soorten escalatie, de escalatiematrix en best practices voor het opstellen van een effectief beleid.

Wat is escalatie van incidenten?

Incidentescalatie vindt plaats wanneer een werknemer een incident niet zelf kan oplossen en de taak moet overdragen aan een meer ervaren of gespecialiseerde werknemer.

Wat is een escalatiebeleid?

De vragen lijken eenvoudig, maar hoe groter je organisatie en hoe complexer je technologisch ecosysteem, hoe meer de antwoorden om details vragen. Als je bijvoorbeeld bepaalt wie er op de hoogte moet worden gebracht wanneer er een incidentwaarschuwing binnenkomt, kan het antwoord niet alleen verschillen afhankelijk van wie dienst heeft of beschikbaar is, maar ook afhankelijk van ernstniveaus, de duur van het incident, enzovoort. 

Voor sommige bedrijven kan één op afroep-persoon als eerste op de hoogte worden gebracht, ongeacht de ernst van het incident. Voor anderen kan het zinvol zijn om een junior ontwikkelaar te waarschuwen als het incident een SEV 3 is en een meer senior persoon of gespecialiseerd team op de hoogte te stellen als het SEV 1 is.

Daarnaast kunnen sommige bedrijven vertrouwen op hun respondent om een incident te escaleren indien dat nodig is. Anderen kunnen een automatische escalatie naar een meer senior ontwikkelaar of gespecialiseerd team activeren als een incident een bepaalde tijd overschrijdt of een groter aantal systemen of gebruikers begint te beïnvloeden.

Een escalatiebeleid moet niet alleen betrekking hebben op hoe je bedrijf incidenten escaleert en naar wie, maar ook of er nuance is op basis van het type incident, SEV-niveau, duur en omvang van het incident.

Escalatieprocessen voor incidenten

Voor bedrijven die de best practices van ITSM volgen, staat de servicedesk doorgaans centraal bij incidentescalatie. Als de eerste responder een incident niet kan oplossen, keren ze terug naar de servicedesk, waar ze het probleem naar de juiste volgende aangewezen verantwoordelijke(n) escaleren. Met gebruik van Jira Service Management kunnen responders incidenten escaleren binnen het incidentticket. Responders hebben toegang tot workflows om het oplossingsproces te begeleiden en kunnen automatiseringen uitvoeren of acties aanpassen wanneer dat nodig is. Het toewijzen van een ernstniveau kan responders naar de geschikte workflow leiden.

Andere bedrijven, zoals Google, geven een SRE de leiding over incidenten en die persoon is verantwoordelijk voor eventuele noodzakelijke escalatie (evenals het bevriezen van nieuwe releases in het geval dat een incident het team over hun acceptabele downtime duwt volgens hun SLA/SLO).

Voor nog andere bedrijven kan de respondent een ontwikkelaar of een incidentmanager zijn of kunnen er meerdere eerste contactpunten zijn (vooral wanneer er een waarschuwing binnenkomt voor een incident met een hoge ernst) en kan er escalatie plaatsvinden via vooraf gedefinieerde processen rechtstreeks in en tussen die teams.

Of het proces nu via de servicedesk verloopt, wordt gefaciliteerd door een SRE of automatisch gebeurt binnen je incidentvolgsystemen; er zijn doorgaans drie manieren dat escalatiebeleid volgt.

Hiërarchische escalatie

Hiërarchische escalatie is wanneer een incident wordt doorgegeven aan een team of persoon op basis van hun ervaring of niveau binnen de organisatie. 

De eerste respondent kan bijvoorbeeld een junior ontwikkelaar zijn die nieuw is in het team. Als deze een probleem niet kan oplossen, wordt het probleem in een hiërarchische organisatie overgedragen aan een meer senior ontwikkelaar. Als de meer senior ontwikkelaar het probleem ook niet kan oplossen, gaan ze opnieuw over op een meer senior ontwikkelaar, en zo steeds verder totdat het probleem is opgelost.

Functionele escalatie

Functionele escalatie is wanneer een incident wordt overgedragen aan een team dat of persoon die het best uitgerust is om het op te lossen op basis van hun vaardigheden of systeemkennis, niet hun senioriteit. 

De eerste respondent kan bijvoorbeeld een junior ontwikkelaar zijn van een team dat zich richt op de back-end van product X. Als ze ontdekken dat het kernprobleem lijkt te komen van een integratie met product Y, kunnen ze het incident escaleren naar een andere junior ontwikkelaar in het product Y-team.

Automatische escalatie

Voor teams die werken met een platform zoals Opsgenie kun je ook regels instellen die het systeem vertellen een incident automatisch te escaleren als de primaire op afroep-persoon een waarschuwing niet erkent of niet sluit.

Sommige teams geven de voorkeur aan de ene escalatiemethode boven de andere, maar ze sluiten elkaar niet uit en veel teams gebruiken een mix van hiërarchische, functionele en automatische escalatie.

De escalatiematrix

Een escalatiematrix is een document of systeem dat bepaalt wanneer escalatie moet plaatsvinden en wie incidenten op elk escalatieniveau moet afhandelen. 

De term wordt in een aantal industrieën gebruikt. Human resources hebben mogelijk een escalatiematrix voor interne problemen. Callcenters hebben mogelijk een escalatiematrix voor problemen met de klantenservice. En IT- en DevOps-teams hebben mogelijk een of meer matrices waarmee technici kunnen weten hoe en wanneer ze een incident moeten escaleren. 

Het detailniveau in een matrix verschilt sterk per bedrijf. Sommige organisaties hebben mogelijk een eenvoudig hiërarchisch diagram, waarbij elke ontwikkelaar naar een ontwikkelaar met een hoger vaardigheidsniveau escaleert als dat nodig is. Andere organisaties hebben mogelijk situatiespecifieke matrices die ontwikkelaars vertellen met welke teams ze contact moeten opnemen voor verschillende soorten incidenten of verschillende ernstniveaus. Zoals met de meeste zaken op het gebied van incidentmanagement, is er geen eenduidig antwoord voor hoe je de matrix van je organisatie kunt ontwikkelen.

Goede praktijken voor het ontwikkelen van een escalatiebeleid

Behandel je escalatiebeleid als richtlijnen, niet als een reeks vaste regels

Technologie is niet statisch en je teams ook niet. Google stelt voor dat als je SRE denkt dat een specifiek geval om een andere escalatiestrategie vraagt, je hen de vrijheid geeft om die beslissing te nemen. Het gaat hier niet om het maken van onflexibele regels, maar om het creëren van richtlijnen die in de meeste situaties van toepassing zijn.

Controleer je op afroep-rooster regelmatig

Zijn er hiaten in het rooster? Heb je de juiste mensen op afroep? Heb je de juiste mensen op je tweede en derde op afroep-niveau? Je op afroep-roosters en escalatiebeleid moeten samenwerken voor sneller incidentmanagement.

Slimme drempels instellen voor escalatie

Niet elk incident is gelijk; dit betekent dat niet elk incident hetzelfde escalatiebeleid kan of moet volgen. 

Voor kleine incidenten wil je de beschikbare engineer misschien pas tijdens kantooruren waarschuwen. Bij grote incidenten heb je die engineer waarschijnlijk nodig, ongeacht het tijdstip van de dag. In het geval van meerdere incidenten moet je engineer weten wat hij eerst moet aanpakken en of hij het ene incident onmiddellijk moet escaleren naar een tweede engineer.   

Er is hier een evenwichtsoefening tussen ervoor zorgen dat je systemen maximale uptime hebben en hun SLA-beloften en SLO-doelen nakomen en ervoor zorgen dat engineers niet opgebrand zijn, overwerkt raken, slaapgebrek hebben en onderhevig zijn aan waarschuwingsmoeheid.

Duidelijke processen instellen voor escalatie

Moet de escalerende ontwikkelaar rechtstreeks contact opnemen met het juiste team of de juiste persoon of moet hij de helpdesk inschakelen? Is er een systeem dat de ontwikkelaar zou moeten gebruiken? Hoe ga je de escalatie volgen? Welke verantwoordelijkheden heeft de respondent om ervoor te zorgen dat het incident door de volgende persoon wordt opgepakt?

Deze vragen moeten duidelijk worden behandeld in je beleid en duidelijk worden gecommuniceerd aan alle op afroep-ontwikkelaars om escalaties soepel te laten verlopen en incidenten sneller op te lossen.

Lees meer over hoe Jira Service Management je werkwijze voor incidentmanagement kan verrijken door een gezamenlijke oplossing te bieden voor incidentescalatie om tot snellere oplossingen te komen.