Incidentmanagement voor razendsnelle teams
Het incidentmanagementproces uitvoeren als een IT-Ops pro
Door Nick Wright, Service Operations Manager van Atlassian
Laat me eerst even iets zeggen: mensen die eerstelijnssupport zijn, zijn de weinig geprezen helden van elk bedrijf.
Elk. Bedrijf.
Ik ben er echt van overtuigd dat technische support moet worden beschouwd als een dienstverlening en dat klanten fooien moeten kunnen achterlaten voor agents die uitstekende service leveren. Ik had graag een fooi achtergelaten voor elke medewerker van Killer Support die mijn problemen snel en met een glimlach heeft helpen afsluiten.
Maar ik dwaal af. Als je dit leest, heb je waarschijnlijk de leiding over of zit je in een helpdeskteam. Waarschijnlijk is het chaos. Iedereen rent als een kip zonder kop rond. Alle structuur ontbreekt. Dus laten we daar iets aan doen en je proces voor IT-incidentmanagement weer onder controle krijgen.
Maar voordat we ingaan op incidentmanagement, laten we het even hebben over veelvoorkomende terminologie.
ITSM en incidentmanagement
Als je in de IT werkt, ben je waarschijnlijk bekend met ITIL, ITSM, incidenten en problemen. Om te zorgen dat iedereen op dezelfde golflengte zit, volgen er nu definities van enkele trefwoorden:
ITIL (IT Infrastructure Library of bibliotheek voor IT-infrastructuur) is een verzameling best practices voor ITSM (zie het als een draaiboek).
ITSM (IT-servicebeheer) is een veelvoorkomende aanpak om IT-services te maken, te ondersteunen en te beheren. Het kernconcept van ITSM is de overtuiging dat IT als service moet worden geleverd. En een van de kernpraktijken van ITSM is incidentmanagement.
Incidenten zijn ongeplande gebeurtenissen die de kwaliteit van een service kunnen verstoren of verminderen (of dreigen dit te doen). Een bedrijfstoepassing die offline gaat, is een incident. Een trage webserver die het nog maar net doet kan ook een incident zijn. Deze zijn traag en staan de productiviteit in de weg. En wat nog erger is, het kan volledig uitvallen.
Een probleem is de nog niet bekende oorzaak achter een of meer incidenten. In het bovenstaande incident, waar het netwerk traag is en een bedrijfstoepassing offline is, kan een verkeerd configureerde router voor beiden het onderliggende probleem zijn.
Het belang van incidentmanagement als ITSM-praktijk
Dus waarom incidentmanagement? Waarom maakt dit eigenlijk deel uit van de ITSM-wereld?
Het antwoord zit 'm in de impact. Uit onderzoek blijkt dat ernstige incidenten bedrijven gemiddeld tussen de $ 100.000 en $ 300.000 kosten voor elk uur dat een systeem uit is gevallen.
Met een goed gedefinieerd incidentmanagementproces kunnen deze kosten aanzienlijk verlaagd worden. De voordelen van een goed gedefinieerd proces zijn onder andere:
- Snellere incidentoplossing
- Verminderde kosten of winstverlies voor de organisatie
- Betere communicatie tijdens incidenten, zowel intern als extern
- Voortdurend leren en verbeteren
Workflow in incidentbeheer
Ik zal het ITIL-framework gebruiken om je een algemeen overzicht te geven van de juiste ticketafhandeling, maar in de meeste andere populaire frameworks worden ongeveer vergelijkbare concepten beschreven alleen in een iets andere verwoording.
Het belangrijkste van incidentmanagement is een (goed) proces hebben en daaraan vasthouden.
Ik weet het, alleen dat kan al ontmoedigend werken. Maar het goede nieuws is dat je van de ervaringen van duizenden andere IT-serviceteams kunt leren.
Een van de meest voorkomende fouten van drukke, groeiende IT-organisaties is dat ze het wiel opnieuw willen uitvinden en processen helemaal opnieuw willen aanmaken. Maak gebruik van best practices en verspil geen tijd aan het bouwen van een eigen ontwikkelde tool voor het indienen van tickets.
Identificeer een incident en leg het vast
Een incident kan overal vandaan komen. Een werknemer kan je vragen om het te melden, of het valt je letterlijk in de schoot uit het plafond, in het geval van een slecht bevestigde netwerkhub en zwak dak. (Niet dat ik uit ervaring spreek ... *kuch kuch*)
Ongeacht de bron zijn de eerste twee stappen eenvoudig: iemand identificeert een incident en iemand legt het vast.
Als je het incident ontvangt dat al via je servicedesk vastgelegd is, zijn deze eerste twee stappen al voor je gedaan. Als je gebeld wordt of het incident wordt via e-mail, sms of postduif gemeld, is het de taak van het servicedeskteam om deze op de juiste manier in je servicedesk vast te leggen.
Deze incidentlogs (d.w.z. tickets) bevatten doorgaans:
- De naam van degene die het incident rapporteert
- De datum en tijd waarop het incident wordt gerapporteerd
- Een beschrijving van het incident (wat er offline is of niet goed werkt)
- Een uniek identificatienummer dat aan het incident wordt toegewezen om het te volgen
Categoriseer je incident
Deze volgende twee stappen, categoriseren en prioriteiten stellen, zijn cruciaal maar worden vaak over het hoofd gezien. Ze onderscheiden ook de 'verstandigere' servicedesks waarmee ik heb gewerkt van de ... nou ja, niet zo verstandige.
Wijs, als eerst, een logische, intuïtieve categorie toe (en waar nodig een subcategorie) aan elk incident. Als je dat niet doet, heb je later niet de mogelijkheid om je gegevens te analyseren en te zoeken naar trends en patronen, wat een cruciaal onderdeel is van effectief probleembeheer en het voorkomen van toekomstige incidenten.
Dus zorg er gewoon voor dat je het niet vergeet. En kies een ITSM-servicedeskoplossing waarmee je eenvoudig incidentcategorieën kunt aanpassen.
Geef prioriteit aan je incident
Ten tweede moet elk incident prioriteit krijgen.
Om prioriteit te geven aan een incident, moet je eerst de impact ervan op het bedrijf beoordelen. Denk eraan dat het aantal mensen dat beïnvloed wordt en de mogelijke implicaties op financieel, beveiligings- en nalevingsgebied om te bepalen hoeveel impact het incident veroorzaakt en hoe dringend het is dat het bedrijf dit incident oplost.
De aanbevolen werkwijze is het definiëren van de ernst en prioriteitsniveaus voordat een incident plaatsvindt. Zo kunnen incidentmanagers snel en eenvoudig de prioriteit bepalen.
En als je twijfelt over de prioriteit? Kies voor het hogere prioriteitsniveau. Het is beter om te voorzichtig te zijn dan dat je iets ernstigs over het hoofd ziet.
Als je de prioriteiten hebt ingesteld, kun je alle open incidenten behandelen op volgorde van prioriteit. De meeste organisaties hebben duidelijke serviceovereenkomsten ingesteld rondom elk prioriteitsniveau, zodat klanten weten hoe snel ze een reactie en oplossing kunnen verwachten. Ik raad die werkwijze ten zeerste aan.
Reageren
Incidentrespons is een vrij brede term, dus laten we het een beetje verder opsplitsen in de meest waarschijnlijke stappen die je uitvoert zodra je een incident hebt geïdentificeerd, gecategoriseerd en geprioriteerd.
Eerste diagnose
Beschouw dit als de triage die een ziekenhuis uitvoert bij nieuwe patiënten. De werknemer bij de servicedesk formuleert een snelle hypothese bij wat er waarschijnlijk mis is, zodat ze een oplossing kunnen bedenken of de juiste procedures volgen en de juiste bronnen kunnen samenstellen om het op te lossen.
Kennisdatabases en diagnostische handleidingen zijn nuttige bronnen bij deze stap.
Als de eerste servicedeskagent die reageert het incident kan oplossen op basis van hun oorspronkelijke diagnose, beschikbare kennis en tools, wordt het incident opgelost. Anders moet het geëscaleerd worden.
Incidentescalatie
Escalatie klinkt als een negatief woord, maar dat is het niet.
Je supportteam bij de frontoffice moet in staat zijn om veel van de meest voorkomende incidenten op te lossen zonder te escaleren. Maar van wat ze niet kunnen oplossen, moeten ze de juiste informatie verzamelen en vastleggen zodat tweede- en derdelijnssupport (de meer technische personen) snel weer bij kunnen zijn en het incident snel kunnen oplossen.
Onderzoek en diagnose
ITIL noemt dit zijn ene eigen stap. In werkelijkheid gebeurt dit gedurende de hele cyclus van het incident.
De eerstelijnssupportagent onderzoekt tot op zekere hoogte al iets als hij of zij informatie verzamelt. Mogelijk kan diegene zelfs de juiste diagnose stellen en het incident oplossen zonder dat er escalatie nodig is.
In dat geval sla je de volgende paar stappen meteen over: oplossing, herstel en sluiting van het incident.
Anders vinden het onderzoek en de diagnose plaats bij elke stap naarmate je escaleert naar supportniveau 2 of 3 of externe bronnen raadpleegt of andere collega's erbij haalt die kunnen helpen bij het oplossen.
Oplossing en herstel
Uiteindelijk, en bij voorkeur binnen je gevestigde service level agreements (SLA's) kom je tot een diagnose en kun je de nodige stappen uitvoeren om het incident op te lossen. Herstel houdt simpelweg in hoe lang het kan duren voordat de bewerkingen volledig zijn hersteld, aangezien sommige oplossingen (zoals bugpatches, enz.) mogelijk moeten worden getest en geïmplementeerd, zelfs nadat de juiste oplossing is vastgesteld.
Afsluiten van incidenten
Het incident wordt dan teruggestuurd naar de servicedesk (als het was geëscaleerd) om te worden gesloten. Om de kwaliteit te waarborgen en een soepel proces te garanderen, mogen alleen medewerkers van de servicedesk incidenten sluiten en moet de eigenaar van het incident contact opnemen met de persoon die het incident heeft gemeld om te bevestigen dat de oplossing bevredigend is en dat het incident daadwerkelijk kan worden gesloten.
Conclusie: sla geen stappen over
Het proces lijkt misschien onnodig formeel, vooral als je maar een paar analisten van de servicedesk hebt. Maar ongeacht de structuur van je team is de levenscyclus van het incident nog steeds hetzelfde.
Stel dat je maar één servicedesk-analist hebt, dus er is geen support op niveau drie. Maar incidenten die de kennis van je servicedesk-analist te boven gaan, moeten ergens heen, of het nou naar je hoofdengineer of een externe consultant is, of zelfs naar jou, toch?
Voilà! Je hebt inderdaad support van niveau twee of niveau drie, alleen jij en je engineer zijn dat.
Mijn punt? Ook al lijkt het erop dat ITIL helemaal over semantiek gaat, probeer er niet in verstrikt te raken. Zoek naar eenvoudige manieren om je organisatiehiërarchie en procesworkflows aan te passen zodat ze passen bij een eenvoudig framework voor IT-servicebeheer, zoals hierboven geschetst.
Door dat te doen, bied je een veel betere service en krijg je veel meer waarde voor het bedrijf. (Bovendien is het veel minder snel chaos op de afdeling - bonuspunten!)
Tot slot nog een paar herinneringen:
- Leg elk incident vast. Geef het een uniek nummer. En leg belangrijke gegevens (zoals datum, tijd en beschrijving) vast in een centraal helpdesksysteem.
- Als je een groot intern of extern publiek hebt om updates over incident aan te geven, overweeg dan een statuspagina voor incidentcommunicatie.
- Wijs een categorie toe aan elk incident (en indien nodig een subcategorie).
- Geef elk incident een prioriteitsniveau en elk prioriteitsniveau een SLA.
- Zorg voor duidelijk gedefinieerde rollen voor respondenten, zoals incidentcommandant, grootschalige incidentmanager, communicatie lead.
- Geef je eerstelijnssupportteam waar mogelijk artikelen uit de kennisdatabase en diagnostische scripts voor incidenten, zodat ze incidenten snel kunnen oplossen.
- Zorg ervoor dat de servicedesk altijd de controle behoudt over de voortgang, de route en de status van incidenten.
- En leg niet alleen gegevens over incident vast. Analyseer ze ook! Zoek naar trends, patronen en mogelijke onderliggende problemen die het aantal incident kunnen verminderen en het risico kunnen beperken.
Over de auteur
Nick Wright
Manager Service Operations bij Atlassian
Mijn team en ik zorgen ervoor dat de cloudtoepassingen en -infrastructuur van Atlassian uitstekend presteren, en ik wil graag delen hoe we dat doen, terwijl we snel opschalen. Ik ben een Kiwi, maar ondanks die taalkundige handicap kan ik nog steeds 'Fish and Chips' uitspreken. In mijn vrije tijd ben ik aan het fietsen, gamen en tijd spenderen met mijn vrouw en lieve kleine meid.
Ontdek incidentcommunicatie met Statuspage
In deze tutorial laten we je zien hoe je incidentsjablonen kunt gebruiken om effectief te communiceren tijdens storingen. Aanpasbaar voor de vele soorten serviceonderbrekingen.
Lees deze tutorialSjablonen en voorbeelden voor incidentcommunicatie
Bij het reageren op een incident zijn communicatiesjablonen van onschatbare waarde. Download de sjablonen die onze teams gebruiken, plus meer voorbeelden voor veelvoorkomende incidenten.
Lees dit artikel