Close

De weg naar beter incidentmanagement begint hier

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

Vroeger was het team dat moest reageren op technologische incidenten bijna altijd IT. Vaak controleerde een team in een netwerkoperatiecentrum, of NOC, systemen en reageerde op storingen. Een leverancier kan de software dan wel gebouwd hebben, maar het IT Ops-team van de klant was verantwoordelijk voor de implementatie en activiteiten. Tegenwoordig bouwt de leverancier de software en is deze ook verantwoordelijk voor de implementatie en activiteiten, zeker met de toename van clouddiensten.

Toch blijft incidentmanagement nog steeds een kerntaak van ITSM. IT is al lang betrokken bij de ontwikkeling van richtlijnen, budgetmanagement en de volledige last van diagnosticeren, repareren, documenteren en voorkomen van ernstige incidenten.

Natuurlijk is het verleden, net zoals bij alles in de tech-wereld, niet per se een indicatie van de toekomst, en vallen ook de huidige incidentmanagementwerkwijzen ten prooi aan verandering. DevOps-, SecOps- en architectuurteams worden steeds vaker betrokken. Nieuwe technologie en onderling gekoppelde producten hebben de manier waarop we omgaan met incidenten veranderd. En denkwijzen, werkwijzen en teamstructuren veranderen om dit bij te houden.

Dus, hoe verandert het incidentmanagement en wat betekent dat voor de toekomst van onze rollen, producten, processen en teams?

Een stap in de richting van decentralisatie

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.

De moeizame weg naar decentralisatie

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.

Decentralisatie betekent teamoverschrijdend samenwerken

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.

De verschuiving van reactief naar proactief

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.

Met behulp van processen en documentatie op koers blijven

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?

Is jouw bedrijfscultuur klaar voor verandering?

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:

Openheid en uitwisseling van informatie

Wanneer teams niet weten wat andere teams doen en daar geen toegang tot hebben, gaan mogelijke aha-momenten verloren die kunnen leiden tot betere communicatie, processen en producten.

Klantgericht denken

Als we vragen stellen als 'Wat is echt het beste voor de klant?' komen soms de antwoorden die we bedenken niet overeen met onze huidige werkwijzen. Er is een doelbewuste klantgerichtheid voor nodig om te zorgen dat we op zo'n manier communiceren, processen uitvoeren en structurele efficiëntie leveren die uiteindelijk onze producten beter maakt voor klanten.

Regelmatige health checks

Hoe gaat het met elk team? Hoe denken afzonderlijke teamleden over de situatie? Wat kan het team verbeteren? Waar blinken ze echt in uit? Bij Atlassian hebben we een teamdraaiboek dat ons helpt om de gezondheid van teams te controleren en dat ze kennis laat maken met nieuwe manieren van werken.

Empathie

Als DevOps met de vinger naar IT wijst en de IT met de ogen rolt naar de meer relaxte benadering van DevOps, dan is dat geen goede basis voor samenwerking. Empathie en een gevoel van verbondenheid bevorderen tussen teams is essentieel als we willen dat deze teams goed communiceren, innoveren en samenwerken.

Empowerment

Teams moeten problemen snel kunnen oplossen en waar mogelijk onafhankelijk beslissingen kunnen nemen. Afzonderlijke leden binnen die teams moeten zich veilig voelen hun mening te geven als ze een vraag, suggestie of probleem hebben, ongeacht hun positie in het team of hun ervaring.

Als junior ontwikkelaars het gevoel hebben dat ze tijdens vergaderingen een hand kunnen opsteken en een probleem kunnen signaleren, zelfs als iemand in een hogere functie verantwoordelijk is voor die code, resulteert dit in innovatieve ideeën, verbeterde processen en het opsporen van bugs voordat ze met de code gereleased worden.