Incidentmanagement voor razendsnelle teams
De veranderende rol van incident- en probleemmanagement
In het afgelopen decennium is incidentmanagement ingrijpend veranderd.
ITIL-richtlijnen zijn bijgewerkt. IT-teams zijn begonnen met het delen van verantwoordelijkheid met DevOps en SecOps. Steeds ingewikkelder systemen hebben geleid tot meer complexe oplossingen voor incidentmanagement. En veel bedrijven omarmen postmortems zonder schuldvraag en nieuwe manieren om prestaties te meten.
Incidentmanagement blijft verschuiven en evolueren, maar dat geldt eveneens voor een goede bekende ervan: probleembeheer, en de relatie tussen beide.
Wat is een probleem en wat is het verschil met een incident?
ITIL definieert een probleem als 'een oorzaak of mogelijke oorzaak van een of meer incidenten'.
En een incident is een enkele ongeplande gebeurtenis die een onderbreking van de service veroorzaakt.
Met andere woorden: incidenten zijn de vervelende episodes die oproepmedewerkers doorgaans proberen om zo snel en volledig mogelijk op te lossen. En problemen zijn de hoofdoorzaak van die ontwrichtende gebeurtenissen.
Een probleem kan een enkel incident veroorzaken of tot meerdere incidenten leiden. En een incident kan worden herleid tot een enkel probleem of, soms, tot meerdere problemen.
De uitval van vijf uur die Delta Airlines in 2016 $ 150 miljoen kostte, was bijvoorbeeld een incident. Het probleem dat dit incident veroorzaakte, was een stroomstoring in een operationeel centrum, waarbij vermoedelijk geen reserveplan voor mogelijke stroomstoringen aanwezig was.
Ook de uitval van de app store van 12 uur die Apple naar schatting $ 25 miljoen kostte was een incident. Het probleem erachter? Een probleem met de DNS.
Als we deze termen buiten de technische wereld zouden gebruiken, zou een haastig doktersbezoekje in verband met migraine een incident zijn. De oorzaak van de migraine, allergieën of problemen met het gezichtsvermogen of stress, zou dan het probleem zijn.
Probleembeheer vs. incidentmanagement
Uiteraard zijn problemen en incidenten onlosmakelijk met elkaar verbonden. Het ene veroorzaakt het andere en teams moeten op beide letten.
De nieuwste ITIL-richtlijnen vragen traditionele IT-teams om zowel problemen als incidenten te beheren, maar om dit afzonderlijk te doen. Probleembeheer is een praktijk die is gericht op het voorkomen van incidenten of het verminderen van de impact ervan. Incidentmanagement is gericht op het in realtime aanpakken van incidenten.
Het voordeel van de ITIL-aanpak is dat deze prioriteit geeft aan de kerndoelen van zowel probleembeheer als incidentmanagement. Door er afzonderlijke en even belangrijke werkwijzen van te maken, proberen de richtlijnen vermoedelijk het veelvoorkomende probleem te vermijden waarbij IT-teams voortdurend brandjes blussen zonder de hoofdoorzaak van die branden aan te pakken.
Als een incidentmanager als belangrijkste doel het snel oplossen van incidenten heeft en een probleemmanager primair problemen moet voorkomen, kan het combineren van deze rollen betekenen dat een van die doelen, die beide van vitaal belang zijn voor een organisatie, minder prioriteit kan krijgen ten gunste van de andere.
Het nadeel van deze aanpak is dat het scheiden van beide handelswijzen, die in de praktijk zo nauw met elkaar verbonden zijn, kan leiden tot kennislacunes en een storing in de communicatie tussen incidentoplossing en de oorzaakanalyse die tot de onderliggende oorzaak leidt.
DevOps en de veranderende rol van probleem- en incidentmanagement
Zoals gewoonlijk heeft de collaboratieve DevOps-beweging de grenzen van het traditionele IT-denken vervaagd: probleem- en incidentmanagement worden niet langer gezien als twee afzonderlijke praktijken, maar als overlappende helften van een holistische kijk.
Deze verschuiving komt niet alleen voort uit het feit dat de handelswijzen twee kanten van dezelfde medaille zijn, incidenten voorkomen en oplossen, maar ook van een DevOps-benadering die doorgaans bevestigt dat:
- Er vaak meer dan één hoofdoorzaak van een incident is
- Postmortems geen schuldige aan moeten wijzen en elk team moeten betrekken dat door een incident wordt getroffen
- Samenwerking de kern vormt van continue verbetering
De overlap in probleem- en incidentmanagement kan ook verband houden met de branchebrede verschuiving naar een 'je bouwt het, je voert het uit'-benadering. Naarmate de teams die systemen bouwen verantwoordelijk worden voor het oplossen van incidenten binnen die systemen, is het logisch dat hetzelfde team verantwoordelijk is voor het uitvoeren van postmortems, het uitvoeren van het detectivewerk om de hoofdoorzaak van een incident te achterhalen en het doen van aanbevelingen die de impact van toekomstige incidenten voorkomen of verminderen.
De brug tussen probleem- en incidentmanagement is hier de postmortem zonder schuldvraag, waarbij incidentmanagers, zodra de urgentie is afgenomen, detective worden en zich richten op probleembeheer en -preventie.
De belangrijkste uitdaging waarmee DevOps-teams worden geconfronteerd die de grenzen tussen deze twee handelswijzen proberen te slechten, is ervoor te zorgen dat probleembeheer met zijn minder urgente maar zeer waardevolle langetermijndoelen niet wordt gedeprioriteerd ten gunste van de urgentie van incidentmanagement.
Natuurlijk is het vaak makkelijker gezegd dan gedaan om incidentmanagement en probleembeheer samen te brengen, maar het is absoluut noodzakelijk om de hoofdoorzaak te vinden en op te lossen. Ontdek hoe de oplossing voor incidentmanagement Jira Service Management teams de flexibiliteit biedt om samen te werken: leg de context vast en maak uitgebreide tijdlijnen aan en los incidenten op en gebruik die om teams te helpen problemen beter te beheren.
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 tutorialDe voor- en nadelen van verschillende benaderingen van op afroep-beheer
Op afroep-teams evolueren snel. Ontdek de voor- en nadelen van verschillende benaderingen van op afroep-beheer.
Lees dit artikel