Wat is incidentmanagement?

Incidentmanagement is het proces dat door ontwikkelings- en IT Ops-teams wordt gebruikt om te reageren op een ongeplande gebeurtenis of serviceonderbreking en om de service weer operationeel te maken.

Bij Atlassian definiëren we een incident als een gebeurtenis die leidt tot verstoring of een vermindering van de kwaliteit van een service waarvoor een noodoplossing vereist is. Teams die ITIL- of ITSM-praktijken volgen, kunnen hiervoor in plaats daarvan de term Ernstig incident gebruiken.

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

Incidentmanagement is een van de meest kritieke processen die een organisatie nodig heeft om goed te kunnen werken. Serviceonderbrekingen kunnen duur zijn voor het bedrijf en teams hebben een efficiënte manier nodig om deze problemen snel op te lossen en op te lossen. Teams hebben een betrouwbare methode nodig om incidenten te prioriteren, sneller tot een oplossing te komen en gebruikers een betere service te bieden.

Als teams met een incident worden geconfronteerd, hebben ze een plan nodig dat hen helpt om:

• effectief te reageren zodat ze snel kunnen herstellen.
• duidelijk met klanten, belanghebbenden, service-eigenaren en anderen in de organisatie te communiceren.
• effectief samen te werken om als team het probleem sneller op te lossen en barrières weg te nemen die hen ervan weerhouden het probleem op te lossen.
• continue te verbeteren om van deze storingen te leren en lessen toe te passen om een service te verbeteren en hun proces voor de toekomst te verfijnen.

Verschillende soorten bedrijven neigen naar verschillende soorten incidentmanagementprocessen. Geen enkel proces is het beste voor alle bedrijven, dus je zult waarschijnlijk verschillende benaderingen zien bij verschillende bedrijven.

Veel teams vertrouwen op een meer traditioneel incidentmanagementproces in IT-stijl, zoals beschreven in ITIL-certificeringen. Andere teams neigen naar een incidentmanagementproces in de stijl van Site Reliability Engineer (SRE) of DevOps.

Een incidentmanagementproces helpt IT-teams bij het onderzoeken, registreren en oplossen van serviceonderbrekingen of -uitval. De ITIL-workflow voor incidentmanagement is bedoeld om de downtime te verminderen en de impact van incidenten op de productiviteit van werknemers te minimaliseren. Met behulp van sjablonen die zijn ontworpen om incidenten te beheren, kun je een herhaalbare workflow voor incidentmanagement aanmaken, die ervoor zorgt dat teams incidenten loggen, diagnosticeren en oplossen, en een overzicht hebben van hun activiteiten.

Het ITIL-kader wordt voornamelijk gebruikt door IT-teams die services binnen bedrijven uitvoeren. Meestal nemen teams wat ze nodig hebben van ITIL, dat betrekking heeft op bijna elk type incident, probleem en proces waarmee IT-teams te maken kunnen krijgen, en laten ze de rest voor wat het is. ITIL is geweldig wanneer teams zich moeten concentreren op het creëren van een cultuur van actieve probleemoplossing. De voorgeschreven processen helpen teams om incidenten en acties op een consistente manier te volgen, wat de rapportage en analyse verbetert en kan leiden tot een gezondere service en een succesvoller team.

Een incident kan overal vandaan komen: een werknemer, een klant, een leverancier, bewakingssystemen. Ongeacht de bron, de eerste twee stappen zijn eenvoudig: iemand identificeert een incident en vervolgens logt iemand het.

• De naam van de persoon die het incident meldt
• De datum en tijd waarop het incident is gemeld
• Een omschrijving van het incident (wat niet werkt of niet goed werkt)
• Een uniek identificatienummer dat aan het incident is toegewezen, voor tracking

Wijs een logische, intuïtieve categorie toe (en waar nodig een subcategorie) aan elk incident. Hiermee kun je je gegevens analyseren op trends en patronen, wat een cruciaal onderdeel is van effectief probleembeheer en het voorkomen van toekomstige incidenten.

Elk incident moet prioriteit krijgen.Begin met het beoordelen van de impact op het bedrijf, het aantal mensen dat zal worden getroffen, eventuele toepasselijke SLA's, evenals de mogelijke financiële, veiligheids- en nalevingsimplicaties van het incident.  Vergelijk dit incident met alle andere openstaande incidenten om de relatieve prioriteit te bepalen. 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. 

• Eerste diagnose: idealiter kan je eerstelijnssupportteam een incident van dichtbij bekijken, maar als dat niet het geval is, is de volgende stap het loggen van alle relevante informatie en het escaleren naar het team op het volgende niveau.
• Escaleren: het volgende team neemt de geregistreerde gegevens en gaat verder met het diagnoseproces, en als het volgende team het incident niet kan diagnosticeren, escaleert het naar het volgende team.
• Communiceren: het team deelt regelmatig updates met betrokken interne en externe belanghebbenden.
• Onderzoek en diagnose: dit gaat door totdat de aard van het incident is vastgesteld. Soms schakelen teams externe middelen of andere afdelingsleden in om te overleggen en te helpen bij de oplossing.
• Oplossing en herstel: in deze stap komt het team tot een diagnose en voert het de nodige stappen uit om het incident op te lossen. Herstel houdt simpelweg in hoeveel tijd het kan duren voordat de bewerkingen volledig zijn hersteld, aangezien sommige oplossingen (zoals bugpatches, enz.) getest en geïmplementeerd moeten worden, zelfs nadat de juiste oplossing is gevonden.
• Afsluiting: als het incident is geëscaleerd, wordt het uiteindelijk teruggestuurd naar de servicedesk om het af te sluiten. Om de kwaliteit te behouden 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 kan worden afgesloten.

Met een DevOps- of SRE-benadering voor incidentmanagement voert het team dat de service bouwt de service ook uit en lost het op als de service kapot gaat. Deze aanpak is enorm populair geworden, naast de groei van cloudservices die altijd zijn ingeschakeld, wereldwijd toegankelijke webapplicaties, microservices en software as a service.

De software waar je voor je leven en werk op vertrouwt, wordt steeds vaker niet gehost op een server op dezelfde fysieke locatie als jij. Het is waarschijnlijk een webtoepassing die in een datacenter wordt geïmplementeerd voor duizenden of miljoenen gebruikers over de hele wereld. Voor teams die deze services moeten beheren, zijn flexibiliteit en snelheid van het grootste belang. Downtime kan gevolgen hebben voor duizenden organisaties, niet slechts voor één.

Een voordeel van de 'je bouwt het, je beheert het'-benadering is dat het de flexibiliteit biedt die agile teams nodig hebben, maar dat het ook kan verdoezelen wie waarvoor verantwoordelijk is en wanneer. DevOps-teams kunnen comfortabel en succesvol zijn met minder gestructureerde ontwikkelingsprocessen. Maar het is het beste om een kernpakket van processen voor incidentmanagement te standaardiseren, zodat er geen twijfel is over hoe je moet reageren in de hitte van een incident, en zodat je issues kunt volgen en kunt rapporteren hoe ze zijn afgesloten.

• Wissel wie wanneer op afroep is ingepland: in plaats van bepaalde teamleden die gespecialiseerd zijn in op afroep beschikbaar zijn, rouleren DevOps-teams meestal volgens een op afroep-rooster waarbij alle leden de last delen dat ze mogelijk 's nachts wakker worden om te reageren op een incident.
• De engineer die het heeft gebouwd, is de beste persoon om het op te lossen: het centrale idee van 'je bouwt het, je beheert het' is dat de mensen die het meest bekend zijn met de service (de bouwers) degenen zijn die het best uitgerust zijn om een uitval op te lossen.
• Bouw snel, maar wees verantwoordelijk: als engineers weten dat zij en hun teamgenoten aan de beurt zijn tijdens uitval, is er een extra stimulans om ervoor te zorgen dat er code van hoge kwaliteit wordt geïmplementeerd.

Deze aanpak zorgt voor snelle responstijden en snellere feedback voor de teams die moeten weten hoe ze een betrouwbare service kunnen bouwen.

We schetsen een zeer DevOps-vriendelijke benadering van incidentmanagement in ons Atlassian Incidentengids.

Incidentmanagement doe je niet alleen met een tool, maar met de juiste combinatie van tools, werkwijzen en mensen.

• Incidenttracking: elk incident moet worden bijgehouden en gedocumenteerd, zodat je trends kunt identificeren en in de loop van de tijd kunt vergelijken.
• Chatroom: realtime tekstcommunicatie is de sleutel om het incident als team te diagnosticeren en op te lossen. En het levert een uitgebreide set gegevens op voor responsanalyse later.
• Videochat: videochat is een aanvulling op tekstchat voor veel incidenten. Videochat in het team kan helpen de bevindingen te bespreken en een reactiestrategie uit te stippelen.
• Waarschuwingssysteem: een tool zoals Jira Service Management integreert met je bewakingssysteem en beheert op afroep-roulaties en escalaties.
• Documentatietool: een tool zoals Confluence kan documenten over de status van incidenten en postmortems vastleggen.
• Statuspage: door via Statuspage de status te communiceren met zowel interne belanghebbenden als klanten, blijft iedereen op de hoogte.