Incidentmanagement voor razendsnelle teams
Escalatiebeleid voor effectief incidentmanagement
Wanneer een incident toeslaat, is het beste scenario dat je op afroep-engineer of SRE het snel en zelfstandig kan oplossen.
Natuurlijk is dat in de echte wereld niet altijd het geval. Soms vraagt een oplossing om een groter team, gespecialiseerde kennis of meer senior-vaardigheden. Daarom heeft elke organisatie met meer dan twee technische professionals een plan en beleid nodig voor escalatie van incidenten.
Wat is escalatie van incidenten?
Incidentescalatie is wat er gebeurt 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?
Een escalatiebeleid geeft antwoord op de vraag hoe je organisatie omgaat met deze overdrachten. Het geeft aan wie op de hoogte moet worden gebracht wanneer een incidentwaarschuwing binnenkomt, naar wie een incident geëscaleerd moet worden als de eerste respondent niet beschikbaar is, wie het moet overnemen als en wanneer de respondent het probleem niet zelf kan oplossen, en hoe die overdrachten moeten gebeuren (via de servicedesk? Direct van de ene technicus naar de andere? Via een incidentmanagementtool?).
Op het eerste gezicht lijken deze vragen eenvoudig, maar hoe groter je organisatie en hoe complexer je technische ecosysteem, hoe meer de antwoorden om details vragen. Wanneer bijvoorbeeld wordt vastgesteld wie op de hoogte moet worden gebracht wanneer een incidentwaarschuwing binnenkomt, kan het antwoord variëren, niet alleen afhankelijk van wie er bereikbaar of beschikbaar is, maar ook op basis van ernstniveaus, duur van het incident, enz.
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 van bedrijf tot 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 op afroep-engineer misschien pas tijdens de kantooruren waarschuwen. Voor grote incidenten heb je die engineer waarschijnlijk ongeacht het tijdstip van de dag al nodig. 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.
Een op afroep-rooster opstellen met Opsgenie
In deze tutorial leer je hoe je een op afroep-rooster instelt, overschrijfregels toepast, op afroep-meldingen configureert en meer, allemaal binnen Opsgenie.
Lees deze tutorialEen betere aanpak van op afroep-roosters
Een effectief op afroep-rooster is de sleutel tot het behoud van een gezonde op afroep-cultuur. Leer veelgemaakte fouten, soorten roulatieroosters en hoe je dit goed kunt doen.
Lees dit artikel