Wat is incidentmanagement?

Soorten incidentmanagementprocessen

Verschillende soorten bedrijven hebben vaak te maken met 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 traditionele IT-stijl van incidentmanagementprocessen, zoals beschreven in ITIL-certificeringen. Andere teams neigen naar een meer Site Reliability Engineer- (SRE) of DevOps-stijl voor het incidentbeheerproces.

IT-incidentmanagementproces

Een incidentbeheerproces helpt IT-teams service-uitvallen of -onderbrekingen te onderzoeken, vast te leggen en oplossen. De ITIL-workflow voor incidentmanagement is bedoeld om 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 incidentbeheer aanmaken, die ervoor zorgt dat teams incidenten registreren, diagnosticeren en oplossen, en een overzicht hebben van hun activiteiten.

Het ITIL-framework wordt voornamelijk gebruikt door IT-teams die services binnen bedrijven uitvoeren. Teams gebruiken doorgaans wat ze nodig hebben van ITIL, dat bijna elk type incident en issue en proces dekt waarmee IT-teams te maken kunnen krijgen, en laten de rest links liggen. ITIL is geweldig wanneer teams zich moeten concentreren op het cultiveren van een cultuur van actieve probleemoplossing. De voorgeschreven processen helpen teams 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.

Stappen in het beheerproces voor IT-incidenten

Identificeer een incident en leg het vast

Een incident kan overal vandaan komen: een werknemer, een klant, een leverancier, monitoringsystemen. Ongeacht de bron zijn de eerste twee stappen eenvoudig: iemand identificeert een incident en iemand legt het vast. 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

Categoriseren

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.

Prioriteren

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.

Reageren

• Eerste diagnose: idealiter kan je eerstelijns ondersteuningsteam een incident vanaf de diagnose tot het einde doorlopen, maar als ze dat niet kunnen, is de volgende stap het registreren van alle relevante informatie en escaleren naar het volgende team.
• Escaleren: indien nodig neemt het volgende team de gelogde gegevens en gaat verder met het diagnoseproces, en als dit 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 halen teams externe middelen of andere leden van de afdeling binnen om de oplossing te raadplegen en te helpen.
• 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 hoe lang het kan duren voordat de bewerkingen volledig zijn hersteld, aangezien sommige fixes (zoals bugpatches, enz.) mogelijk moeten worden getest en geïmplementeerd, zelfs nadat de juiste oplossing is vastgesteld.
• Sluiting: als het incident is geëscaleerd, wordt het uiteindelijk teruggestuurd naar de servicedesk 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.

DevOps- en SRE-incidentbeheer

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

In toenemende mate wordt de software waarop je vertrouwt niet gehost op een server op dezelfde fysieke locatie als jij. Het is waarschijnlijk een webtoepassing die wordt geïmplementeerd in een datacenter voor duizenden of miljoenen gebruikers over de hele wereld. Voor teams die belast zijn met het uitvoeren van deze services, zijn wendbaarheid en snelheid van het grootste belang. Elke downtime heeft het potentieel om duizenden organisaties te treffen, niet slechts één.

Een voordeel van de 'je bouwt het, je voert het uit'-aanpak is dat deze de flexibiliteit biedt die agile teams nodig hebben, maar deze kan ook onduidelijk maken wie verantwoordelijk is voor wat en wanneer. DevOps-teams kunnen comfortabel, en succesvol, zijn met minder gestructureerde ontwikkelingsprocessen. Het is echter het beste om te standaardiseren op een kernset van processen voor incidentmanagement, zodat er geen twijfel is over hoe je moet reageren middenin een incident, zodat je problemen kunt volgen en kunt rapporteren over hoe ze worden afgesloten.

Drie overtuigingen van DevOps-incidentmanagementteams

• Op afroepdiensten afwisselen: in plaats van bepaalde teamleden die gespecialiseerd zijn in op afroep zijn, roteren DevOps-teams doorgaans een op afroeprooster waarbij alle leden aande beurt komen om 's nachts mogelijk wakker te moeten worden om op een incident te reageren.
• De engineer die het heeft gebouwd, is de aangewezen persoon om het te repareren: het centrale idee van de ethos 'je build het, je voert het uit' is dat de mensen die het meest bekend zijn met de service (de bouwers) degenen zijn die het best een uitval op kunnen lossen.
• Bouw snel, maar wees verantwoord: wanneer ingenieurs weten dat zij en hun teamgenoten aan tijdens uitval moeten handelen, is er een extra stimulans om ervoor te zorgen dat je kwaliteitscode implementeert.

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

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

Tools voor incidentmanagement

Incidentbeheer gebeurt niet alleen met een tool, maar met de juiste combinatie van tools, praktijken en mensen. Hier zijn een paar van de meest voorkomende toolcategorieën voor effectief incidentmanagement:

• Incidenttracking: elk incident moet worden bijgehouden en gedocumenteerd, zodat je in de loop der tijd trends kunt identificeren en vergelijkingen kunt maken.
• Chatruimte: een realtime kanaal voor communicatie via tekst is van fundamenteel belang om het incident als team te diagnosticeren en op te lossen. En het biedt een uitgebreide set gegevens voor responsanalyse later.
• Videochat: videochat is een aanvulling op tekstchat voor veel incidenten, teamvideochats kunnen helpen de bevindingen te bespreken en een responsstrategie in kaart te brengen.
• Waarschuwingssysteem: een tool zoals Jira Service Management integreert met je bewakingssysteem en beheert roulaties op afroep en escalaties.
• Documentatietool: een tool zoals Confluence kan documenten over incidentstatus en postmortems vastleggen.
• Statuspage: het communiceren van de status aan zowel interne belanghebbenden als klanten via Statuspage zorgt ervoor dat iedereen op de hoogte blijft.