De toekomst van IT-incidentmanagement, -respons en -preventie

Als kijkt naar vijf jaar geleden en een IT-team van toen vroeg wie er verantwoordelijk was voor incidentmanagement, was het antwoord bijna altijd wel 'wij'.

Als je tegenwoordig het team dezelfde vraag stelt, bevat het antwoord waarschijnlijk niet alleen IT, maar ook DevOps-, SecOps en architectuurteams. Veel organisaties verschuiven langzaam aan naar het idee 'jij bouwt het, jij voert het uit.'

De logische voordelen van deze aanpak zijn dat ze de druk op de IT-teams verlichten en de responstijden verminderen door de verantwoordelijkheid te verschuiven naar de mensen die het bekendst zijn met de code. Hierdoor wordt de downtime geminimaliseerd en teamproductiviteit gemaximaliseerd. Daarnaast wordt ook het schrijven van goede code gestimuleerd. (Als je om 3 uur 's nachts wakker wordt om een bug op te lossen, is de kans groot dat je de code dubbel en dwars zult controleren als die live gaat, zodat je de volgende keer niet om 3 uur 's nachts wakker gebeld wordt.)

Het uitdagende van deze aanpak is dat organisaties nog steeds een vorm van centralisatie nodig hebben. Het management heeft toegang nodig tot rapporten en documentatie. Zakelijke belanghebbenden willen updates. Ze willen incidentstatistieken zien, zoals de gemiddelde tijd voor het vinden van oplossingen en de gemiddelde tijd voor bevestiging. Ze verwachten duidelijke updates over incidenten, postmortemrapporten van incidenten en herstelwerkzaamheden.

Voor veel bedrijven die op weg zijn naar decentralisatie en goed presteren, kan deze uitdaging worden aangegaan met technologie die decentralisatie en teamautonomie mogelijk maakt. Daardoor blijft incidentoplossing wendbaar en kunnen ze toch informatie centraliseren, zodat iedereen in het bedrijf op de hoogte blijft.

Zoals bij elke andere grote verandering die workflows kan verstoren en onvoorziene gevolgen aan het licht kan brengen, is het logisch dat veel organisaties decentralisatie in kleine stapjes uitvoeren.

Als eerst identificeren ze een team dat bij cultureel geschikt is voor een dergelijke verandering en dat een toepassing of product met een laag risico beheert. Vervolgens verplaatsen ze het incidentmanagement voor de specifieke toepassing of het specifieke product naar dat team. Ze trainen ze, passen een opafroeprooster toe en houden hun voortgang in de loop der tijd bij door vragen te stellen zoals:

• Is de hersteltijd verbeterd?
• Op welke culturele barrières zijn ze gestuit?
• Welke tools moest het IT-team inzetten?
• Welke processen waren nodig bij de communicatie?
• Komen er betere systeemupdates van dat team?
• Is het aantal incidenten gedaald?
• Als we besluiten om deze decentralisatie in andere teams te gebruiken, wat kunnen we dan van deze eerste test leren?

Deze testcases bieden een basis om te beslissen of er in het hele bedrijf een 'jij bouwt het, jij ondersteunt het'-benadering moet worden geïmplementeerd en, zo ja, hoe deze effectief kan worden uitgerold naar verschillende teams.

Deze stap naar decentralisatie vereist ook een verschuiving naar samenwerking tussen teams. Als DevOps betrokken is bij het incidentmanagement, heeft DevOps een plaats nodig aan tafel tijdens vergaderingen over het beheer van IT-incidenten. Als IT nog steeds helpt als leidraad voor het incidentmanagement, moeten ze betrokken worden bij postmortembeoordelingen door andere teams.

Elk team brengt zijn eigen sterke punten met zich mee tijdens incidentmanagement. IT-teams zijn goed in het ontwikkelen van werkwijzen, documenteren en het volgen van richtlijnen. DevOps-teams zijn goed in verandering en kennis opdoen. SecOps kan een beveiligingsgericht perspectief bieden.

Om voor meer en betere samenwerking tussen teams te zorgen, doen bedrijven er oed aan om informatie open te delen, empathie tussen teams te stimuleren, vingerwijzen tussen teams te vermijden, chat te gebruiken om teams betrokken te houden tijden incidenten en incidentbeoordeling te prioriteren waarbij iedereen een plekje aan tafel heeft.

In de ITIL-richtlijnen wordt incidentmanagement doorgaans gezien als een andere werkwijze dan incidentpreventie. Beide zijn belangrijke stukjes van de ITSM-puzzel, maar ze komen niet vaak samen voor.

Het probleem met deze aanpak is dat incidentmanagement reactief blijft. Opafroepmedewerkers hebben de taak om branden te blussen, en zodra de brand geblust is, gaan ze door naar de volgende brand. Hun enige doel is herstel: het systeem weer aan de praat krijgen.

Maar herstel is niet het volledige beeld. En steeds meer IT-teams beseffen dit en omarmen dit gaandeweg door preventie op te nemen in het proces van incidentmanagement en gebruiken statistieken zoals de gemiddelde tijd om op te lossen in plaats van de gemiddelde tijd tot herstel om hun prestaties te beoordelen.

Deze aanpak wordt vaak probleembeheer genoemd en heeft tot doel processen dichter bij elkaar te brengen om ervoor te zorgen dat teams niet alleen reageren op de ene brand en overgaan naar de volgende brand, maar dat ze reageren, herstellen en leren van het incident. Dat doen ze door die kennis toe te passen op zowel het probleem in kwestie als op de grotere product- en servicesystemen die ze beheren.

Veel IT-organisaties van bedrijven zullen een speciale praktijk hebben voor probleembeheer. Ze behandelen dit doorgaans als een afzonderlijk proces voor een apart team. Bij Atlassian pleiten we ervoor om nog een stap verder te gaan en een gemengde aanpak toe te passen waarbij IT-agenten en ontwikkelteams de praktijk van probleembeheer opnemen in hun incidentpraktijken. Dit zorgt voor een beter zicht op het hele incident en zorgt ervoor dat de analyse van het incident niet lang nadat het incident daadwerkelijk is gebeurd, plaatsvindt.

Juist omdat het op de lange termijn waardevoller is om incidenten te voorkomen dan om er snel op te reageren.

Een van de uitdagingen die inherent zijn aan deze verschuiving naar teamoverschrijdende samenwerking op het gebied van incidentmanagement is dat sommige teams relaxter zijn dan andere wat processen en documentatie betreft.

Dit is een van de facetten waar IT overzicht en aanzienlijke waarde kan bieden, zelfs als andere teams het beheer van hun eigen producten op zich nemen. Omdat niemand om 3 uur 's nachts een ernstig incident met slaap in de ogen wil aanpakken zonder een robuust plan.

Wanneer teams worden betrokken bij het incidentmanagementproces, kan IT hen helpen de belangrijkste vragen te beantwoorden die bepalend zullen zijn voor dat plan. Bijvoorbeeld:

• Wat is jullie incidentrespons?
• Wat zijn de waarden die je zult volgen?
• Wat is jullie respons op een incident?
• Waar is de informatie die je nodig hebt voor de support van je kritieke systemen? Als deze over meerdere systemen verspreid is, hoe kun je die informatie dan samenbrengen en eenvoudig toegankelijk maken voor de opafroepmedewerkers?
• Zijn jullie proces en documentatie samenwerkingsgericht en kunnen ze worden beoordeeld door het team?

Deze verschuiving naar decentralisatie, samenwerking en een combinatie van incidentmanagement en probleembeheer vereist meer dan alleen het opnieuw verdelen van verantwoordelijkheid en het inplannen van een IT-professional voor een DevOps-postmortem. De sleutel tot succes ligt niet in de technologie of zelfs in de processen. Het ligt in het creëren van een interne cultuur die deze veranderingen ondersteunt.

Dit is het onderdeel dat veel bedrijven proberen over te slaan, maar het is de basis voor een succesvolle transitie. Dus hoe ziet een cultuur eruit die decentrale, samenwerkingsgerichte en toekomstgerichte incidentmanagement ondersteunt?

Bij Atlassian zie we de volgende componenten als het allerbelangrijkst: