Een uitgebreide handleiding over beheer van grote incidenten in ITIL

Het is maandagochtend en alles gaat vrij normaal bij uw servicedesk. Plotseling krijgt u een waarschuwingsticket dat een kritieke service buiten werking is, en binnen de volgende 15 minuten begint u een toestroom van tickets te krijgen die hetzelfde probleem melden. Het zou kunnen wijn dat uw website buiten werking is, dat uw verkooppuntsoftware niet meer werkt, of iets dat zelfs nog ingrijpender is, zoals het dalen van de aandelenbeurs of vliegtuigen die aan de grond worden gehouden. Wanneer uw bedrijf ernstig wordt beïnvloed door een IT-probleem dat zorgt voor een verlies van inkomsten en/of reputatie, hebt u te maken met een groot incident.

De manier waarop u reageert op een groot incident maakt al het verschil bij het minimaliseren van de impact van het incident en bij het weer in bedrijf stellen van de services. Zoals men zegt, tijd is geld, en in dit geval geldt dit temeer. Als uw organisatie een proces voor beheer van grote incidenten (MIM) heeft, kunt u snel reageren op grote incidenten en deze oplossen. Als u niet een dergelijk proces hebt, is het tijd om een rampenplan op te stellen, ook wel een proces voor reactie op grote incidenten genoemd.

De belangen van een groot incident zijn groter dan ooit tevoren, en volgens een studie van Information Technology Intelligence Consulting, verliest 98 procent van de organisaties ten minste $100.000 bij een uur uitvaltijd. Dit versterkt het belang van het configureren van een MIM-proces dat grote incidenten effectief en efficiënt kan aanpakken.

Elke organisatie richt zich op het wegnemen van grote incidenten, maar de basis is dat grote incidenten onmogelijk volledig te voorkomen zijn en dat het enige dat u kunt doen, is erop voorbereid zijn.

In deze handleidingen kijken we naar het instellen van een effectief MIM-proces, veelgemaakte fouten die van invloed kunnen zijn op het MIM van uw organisatie, en beste werkwijzen voor het verbeteren van uw MIM-proces.

Maar eerst, wat maakt een incident een groot incident?

Een groot incident is een urgent probleem met hoge impact dat doorgaans van invloed is op de gehele organisatie of een groot deel ervan. Een groot incident leidt er bijna altijd toe dat de services van een organisatie niet meer beschikbaar zijn, waardoor de zaken van de organisatie een klap oplopen, wat uiteindelijk van invloed is op de financiële positie. Er bestaan twee manieren waarop een groot incident van invloed kan zijn op de services van een organisatie:

• Door voorkomen dat klanten toegang hebben tot de services van de organisatie. De storing van Cloudflare in juli 2019 is een voorbeeld van klanten die worden beïnvloed door een groot incident. Deze grote storing was van invloed op bijna de helft van het internet en zorgde ervoor dat miljoenen internetgebruikers geen toegang hadden tot diverse services.
• Door verstoren van het vermogen van werknemers om hun werk op tijd af te krijgen, wat leidt tot een verstoring van de bedrijfsvoering. IndiGo's storing in november 2019 was van invloed op het incheckproces van de luchtvaartmaatschappij, wat leidde tot lange vertragingen en wat duizenden passagiers trof.

Een goed voorbereide servicedesk is uitgerust voor het beoordelen van grote incidenten en het bedenken van oplossingen of workarounds voor het reduceren en beheersen van de impact van een groot incident.

Een MIM-proces is een must voor organisaties, omdat het ze helpt bij het minimaliseren van de impact van een groot incident op het bedrijf. Het MIM-proces bestaat in de eerste plaats uit de volgende stappen:

1. Identificatie

Het grote incident aangeven:

De eerste stap is het identificeren van mogelijke grote incidenten. Het is belangrijk dat organisaties meerdere methoden instellen voor het identificeren van bedreigingen. Grote incidenten kunnen worden aangegeven door technici wanneer zij ongebruikelijke tickets tegenkomen, of ze kunnen worden gedetecteerd door oplossingen zoals hulpprogramma's voor netwerkmonitoring die een netwerkprobleem automatisch kunnen aangeven en een ticket kunnen aanmaken om de servicedesk te waarschuwen. Organisaties kunnen tevens een specifieke hotline instellen waarmee personeel van de servicedesk vermoedelijke grote incidenten kan aangeven.

Belanghebbenden informeren:

Wanneer een groot incident is geïdentificeerd, moet het worden gecommuniceerd met alle belangrijke belanghebbenden. Er zijn vier hoofdgroepen die moeten worden geïnformeerd over grote incidenten:

• Technisch team: Het is belangrijk om het technische team onmiddellijk te informeren zodat zij een beslissing kunnen nemen betreffende de stappen om het probleem te corrigeren.
• Management: Het hoogste management, zoals de CIO, op de hoogte houden van grote incidenten helpt bij de verantwoording. Organisaties moeten tevens het management geïnformeerd houden over alle stappen die worden genomen om grote incidenten op te lossen.
• Belangrijke belanghebbenden: De afdelingshoofden en personeel van bedrijfsmanagement op serviceniveau moet tevens geïnformeerd worden over grote incidenten en moet regelmatige statusupdates ontvangen.
• Gebruikers: Gebruikers moeten weten welke services niet beschikbaar zijn als gevolg van een groot incident.

2. Beheersing

Het team voor grote incidenten samenstellen:

Een team voor grote incidenten, of MIT in het kort, bestaat uit technici, managementhoofden op serviceniveau en andere belangrijke belanghebbenden; soms wordt uiterst bekwaam extern personeel ingebracht om een groot incident op te lossen. Het MIT werkt samen voor het zoeken van een oplossing voor een groot incident en om de bedrijfsactiviteiten weer normaal te laten functioneren.

Een conferentiebrug instellen:

Een conferentiebrug, beter bekend als een conferentiegesprek, helpt bij effectieve foutoplossingen gecentraliseerde communicatie. Het functioneert als een duidelijk, snel kanaal van communicatie tussen leden van het MIT.

Een aangewezen ‘war room’ klaarmaken:

Door het hebben van een aangewezen ‘war room’ kunnen alle leden van het MIT samenkomen en het incident oplossen. Dit vergroot de inspanningen van samenwerking, wat het MIT helpt om sneller tot een oplossing te komen.

Een probleemticket aanmaken voor het identificeren van onderliggende problemen:

Een probleemticket kan worden aangemaakt voor het ontdekken en begrijpen van de hoofdoorzaak van het grote incident. Dit kan helpen bij het voorkomen van vergelijkbare grote incidenten in de toekomst door het aanpakken van de oorzaken van het grote incident.

4. Onderhoud

Een controle na de implementatie uitvoeren:

Het is belangrijk om de balans op te maken van het incident over een bepaalde periode om ervoor te zorgen dat het werkelijk opgelost is. Als onderliggende problemen onopgelost blijven, zouden ze kunnen leiden tot een ander groot incident.

Duidelijke documentatie produceren:

Het documenteren van het gehele proces van het oplossen van het grote incident helpt de organisatie om zich voor te bereiden op vergelijkbare incidenten in de toekomst. Met de juiste documentatie van incidenten uit het verleden kan de organisatie de beproefde en geteste oplossing onmiddellijk implementeren wanneer ze staan voor een ander vergelijkbaar incident, waarbij de impact wordt gereduceerd.

Metrieken meten:

Het meten van de prestatie van de servicedesk helpt bij het meten van de effectiviteit van de servicedesk en het MIM-process. Enkele belangrijke metrieken om te meten zijn mean time to acknowledge (MTTA), mean time to resolve (MTTR), totaal aantal grote incidenten, en gemiddelde uitvaltijd voor grote incidenten.

Een groot incident vraagt om een speciale groep personeel om het incident aan te pakken en op te lossen. MIM-rollen omvatten:

Technici van de servicedesk:

Technici van de servicedesk vormen de eerste verdedigingslinie tegen grote incidenten. Zij analyseren incidenttickets en escaleren ze naar de incidentmanager. Technici van de servicedesk zijn tevens betrokken bij de implementatie van oplossingen.

Manager van grote incidenten:

De manager van grote incidenten is de eigenaar van het grote incident. Hun rol omvat het verklaren van het incident als groot incident en ervoor zorgen dat het MIM-proces wordt gevolgd en dat het incident zo snel mogelijk wordt opgelost. Zij fungeren als het belangrijkste punt van contact voor enige informatie over het grote incident, en zij beheren van het MIT.

MIT:

Een MIT is een gespecialiseerd team dat verantwoordelijk is voor het analyseren van het grote incident en het formuleren van een actieplan voor het afhandelen van de bedreiging. Het MIT bestaat idealiter uit technici van de servicedesk, managementpersoneel op serviceniveau, technisch personeel, andere relevante belanghebbenden, en externe adviseurs als de situatie dat vereist.

Technisch personeel:

Het gespecialiseerde personeel dat verantwoordelijk is voor het onderhoud van infrastructuur en bedrijfsactiviteiten, inclusief systeembeheerders, netwerkbeheerders en informatiebeveiligingspersoneel, dat het technische personeel van een organisatie vormt. Het technische personeel helpt bij foutoplossing van het grote incident en is in de eerste plaats verantwoordelijk voor het implementeren van de oplossing voor het grote incident.

Beheerder van wijziging:

De beheerder van de wijziging is de eigenaar van de wijziging die wordt aangemaakt voor het implementeren van de oplossing voor het grote incident. De beheerder van de wijziging neemt de volledige verantwoordelijkheid voor het wijzigingsticket en is er aansprakelijk voor.

Probleembeheerder:

Als een probleem wordt gecreëerd als reactie op een groot incident, is de probleembeheerder verantwoordelijk voor het probleemticket. De probleembeheerder probeert de hoofdoorzaken van het incident vast te stellen en ervoor te zorgen dat het niet meer gebeurt, of dat de organisatie ten minste voorbereid is voor de volgende keer dat het incident zich voordoet.

Externe adviseurs of derde leveranciers:

In sommige gevallen vereist het grote incident uiterst gespecialiseerd personeel om te helpen bij inzicht in en foutoplossing van het incident. De beheerder van het grote incident identificeert het vereiste personeel en voegt hen toe aan het MIT om te helpen bij het reduceren van de impact van het grote incident.

Hier vindt u 5 veelgemaakte fouten die uw MIM-proces kunnen belemmeren:

1. Handmatige communicatie en escalatie:

   Verreweg de grootste uitdaging bij MIM is communicatie. In het geval van een groot incident moeten diverse belanghebbenden worden geïnformeerd over de status van het incident, de ernst ervan, en welke foutoplossing is uitgevoerd om het te corrigeren. Dit alles handmatig communiceren is een lastige taak, en kan leiden tot inconsistente communicatie, wat alles alleen maar erger maakt. Door het automatiseren van het proces worden belangrijke belanghebbenden gedurende de gehele levenscyclus van het ticket op de hoogte gehouden, en de manager van grote incidenten kan zijn/haar volledige aandacht richten op het corrigeren van het probleem.

2. Ineffectieve kanalen voor melden van grote incidenten:

   Elke servicedesk ontvangt tientallen if zelfs honderden tickets per dag, variërend van laptopproblemen tot serviceaanvragen; in deze berg van tickets zouden er een paar potentiële grote incidenten kunnen zitten. Het niet instellen van een apart kanaal voor het melden van grote incidenten vertraagt de identificatie van grote incidenten.

3. Duplicatie van inspanningen:

   Het niet op een georganiseerde manier delegeren van taken kan leiden tot een duplicatie van inspanningen binnen het MIT. Het is belangrijk om taken toe te wijzen en het MIT geïnformeerd te houden over welke taken elk lid heeft gekregen.

4. Slechte documentatie:

   Gebrek aan juiste documentatie zal het MIT dwingen om het wiel opnieuw uit te vinden bij elke keer dat een vergelijkbaar groot incident zich voordoet, wat leidt tot vertragingen bij het oplossen van grote incidenten en onnodige uitvaltijd.

5. Het niet analyseren van de hoofdoorzaak:

   Net als incidentbeheer kan MIM een kortzichtig bereik hebben, aangezien de primaire focus ligt op het corrigeren van hert probleem en de services weer laten functioneren binnen de kortst mogelijke tijd. Als het niet wordt gecombineerd met probleembeheer voor het identificeren van onderliggende problemen, zal de onderliggende oorzaak van een groot incident de organisatie kwetsbaar blijven maken voor grote incidenten.

Hier vindt u de beste manieren om het MIM-proces te benaderen.

1. Schakel meerdere kanalen in voor melden van grote incidenten:

   Wanneer het gaat om het afhandelen van grote incidenten, is tijd van essentieel belang. Het is voor organisaties van essentieel belang om grote incidenten te identificeren en in te delen op het moment dat ze worden gedetecteerd. Door gebruikers meerdere manieren te bieden om incidenten te melden, wordt het gehele proces sneller en beter toegankelijk. U kunt het aanmaken van tickets mogelijk maken via e-mail of een webportal, of u kunt zelfs een specifieke hotline instellen voor het melden van vermoedelijke grote incidenten. Het instellen van software voor netwerkmonitoring voor het detecteren van anomalieën kan u helpen bij het proactief omgaan met grote incidenten.

2. Automatiseer processen van de servicedesk:

   Snelheid en efficiëntie spelen een essentiële rol bij het beheersen van de impact van een groot incident, en het automatiseren van diverse processen van de servicedesk helpt om dit te bereiken door het bevrijden van uw technici van herhalende taken, zoals het informeren van belanghebbenden. Het automatiseren van het meldingssysteem en het instellen van workflows voor grote incidenten zijn goede manieren van het automatiseren van processen van de servicedesk voor het verbeteren van de oplossingstijd en het geven van structuur aan het MIM-proces.

3. Streef naar snelle, relevante communicatie:

   Het is belangrijk om het management van uw organisatie en belangrijke belanghebbenden geïnformeerd te houden over elk groot incident. Het op de hoogte houden van het management zal helpen bij het verkrijgen van de noodzakelijke goedkeuringen en toestemmingen die nodig zijn voor het corrigeren van het grote incident. Directe communicatie zorgt ervoor dat al het personeel voor grote incidenten zich op dezelfde pagina bevindt en maakt soepele, effectieve samenwerking mogelijk; het houdt eindgebruikers tevens geïnformeerd over enige mogelijke uitvaltijd zodat zij zich daarop voor kunnen bereiden.

4. Maak duidelijke documentatie:

   Duidelijke documentatie helpt de beheerder van het grote incident bij het registreren van al het uitgevoerde werk om het grote incident te corrigeren, de impact ervan, de getroffen services en andere belangrijke informatie over het grote incident. Deze documentatie is belangrijk om het management het voordeel te laten zien van het hebben van een MIM-proces, inclusief de ROI. Duidelijke documentatie zal tevens helpen bij enig vergelijkbaar groot incident in de toekomst.

5. Benut diepgaande integraties met ITOM-software:

   Sterke integraties met ITOM-software maken het voor de IT-afdeling mogelijk om grote incidenten proactief aan te pakken. Reactieve identificatie van grote incidenten vertrouwt op een instroom van tickets om een waarschuwingslampje te doen branden dat een groot incident gaande is. Aan de andere kant heeft een proactief MIM-proces dat gebruik maakt van ITOM-integraties systemen voor het monitoren van netwerken en services, en kan automatisch afwijkingen aangeven die potentiële grote incidenten zouden kunnen zijn.

Het is belangrijk om eraan te denken dat niet alle incidenten met hoge prioriteit grote incidenten zijn. Aangezien het MIM-proces een aanzienlijke inzet van hulpbronnen betreft, zoals het implementeren van een apart MIT, is het belangrijk om grote incidenten zorgvuldig te classificeren.

Bron: https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

De storing bij Cloudflare in 2019 is een zeer goed voorbeeld van wat een groot incident definieert. In dit geval heeft een standaard bedrijfsprocedure van het bijwerken van een beheerde regel voor de web application firewall (WAF) geleid tot een piek in het gebruik van CPU’s gericht op het bedienen van HTTP/HTTPS-verkeer naar bijna 100 procent over de servers in het netwerk van Cloudflare. De daarop volgende storing leidde tot een reductie van 80 procent in de bezoekersaantallen van Cloudflare, en beïnvloedde miljoenen internetgebruikers over de hele wereld.

Impact: Groot

Door de storing zagen Cloudflare-klanten (en hun klanten) een 502-foutpagina bij het bezoeken van een Cloudflare-domein. De 502-fouten werden gegenereerd door de ‘front-end’ Cloudflare-webservers die nog steeds CPU-kernen beschikbaar hadden, maar die de processen die het HTTP/HTTPS-verkeer bedienen, niet konden bereiken. De schatting is dat ten minste de helft van het gehele internet niet toegankelijk was gedurende een uitvaltijd van zevenentwintig minuten.,/

Urgentie: Hoog

Alle Cloudflare-websites waren ontoegankelijk, wat leidde tot serviceverstoringen voor duizenden organisaties en miljoenen gebruikers. De storing was ook van invloed op de interne bedrijfsactiviteiten van Cloudflare, waarbij de werknemers van Cloudflare werden belemmerd bij de toegang tot diverse services, zoals het hulpprogramma van het bedrijf voor wijzigingsbeheer en het interne bedieningspaneel. De storing moest worden aangepakt voor het hervatten van de normale service-activiteiten.

Tijdlijn van voorvallen van detectie tot oplossing:

De door WAF beheerde regel werd geïmplementeerd om 13:42 uur; drie minuten later begonnen de hulpprogramma’s voor netwerkbediening van Cloudflare de daling in verkeer aan te geven, vele andere end-to-end testen van Cloudflare-services begonnen een storing te geven, eindgebruikers bemerkten diverse 502-fouten, en Cloudflare ontving vele rapporten van CPU-uitputting van haar punten van aanwezigheid in steden over de hele wereld.

Het technische team van betrouwbaarheid op locatie, het technische team uit Londen en andere relevante teams werden samengebracht voor foutoplossing en het komen tot een oplossing. Om 14:00 uur werd de WAF geïdentificeerd als de oorzaak van het incident. En om 14:07 uur werd een wereldwijde WAF-kill geïmplementeerd om de verkeersniveaus weer terug naar normaal te brengen.

Om 14:52 uur was Cloudflare 100 procent tevreden dat zij de oorzaak van de storing begreep en een oplossing ervoor had, dus de WAF werd wereldwijd opnieuw ingeschakeld.

Wijziging:

De toevoeging, aanpassing of verwijdering van alles dat een direct of indirect effect kan hebben op services.

Wijzigingsbeheer:

Het proces van tot voltooiing brengen van wijzigingen met minimale verstoringen en conflicten.

Escalatie:

De handeling van het overdragen van eigendom van een ticket gebaseerd op een functionele of hiërarchische behoefte.

Gebeurtenis:

Een voorval dat van belang is voor het beheer van een service of activum.

Mislukt:

Een voorval waarbij een service of activum niet functioneert volgens de overeengekomen SLA.

Hiërarchische escalatie:

De handeling van verticaal overdragen van verantwoordelijkheid naar een technicus van de servicedesk op hoger niveau of relevante autoriteit.

Impact:

Een maat van de ernst van een incident.

Incident:

Een ongeplande onderbreking van een IT-service, of een reductie van de kwaliteit van een IT-service. Storing van een configuratie-item, zelfs als het de service nog niet heeft beïnvloed, is ook een incident (bijv. storing van één schijf van een spiegelset).

Incidentbeheer:

Het proces van het beheren van de levenscyclus van alle incidenten om de normale service-activiteiten zo snel mogelijk te herstellen en de impact op het bedrijf te minimaliseren.

Prioritering van incidenten:

Toewijzen van prioriteiten aan incidenten en definiëren wat een groot incident vormt.

Groot incident:

Een incident met een hoge impact en hoge urgentie, wat een afzonderlijk proces van incidentbeheer vereist.

Manager van grote incidenten:

De persoon die verantwoordelijk is voor het MIT en de implementatie van het MIT-proces.

Mean Time To Acknowledge (MTTA):

Een maat van hoe snel een incident wordt bevestigd door de servicedesk.

Mean Time To Detect (MTTD):

Een maat van hoe snel een potentiële bedreiging voor een service of configuratie-item wordt gedetecteerd.

Mean Time Between Failures (MTBF):

Een maat van hoe vaak een service of activum een storing geeft.

Mean time to repair/resolve/respond/recover (MTTR):

Een maat van hoe snel een service wordt hersteld na storing.

Normale service-activiteiten:

Een service-activiteit die zich houdt aan de Service Level Agreement (SLA, serviceniveau-overeenkomst)

Probleem:

Een oorzaak of potentiële oorzaak van een of meerdere incidenten.

RACI-matrix:

Het definieert de rollen en verantwoordelijkheden in functieoverschrijdende of afdelingsprojecten en -processen.

Servicedesk:

Het punt van communicatie tussen serviceproviders en de gebruikers van de organisatie.

Manager van servicedesk:

Degene die toezicht houdt op dagelijkse activiteiten van de servicedesk en die verantwoordelijk is voor de prestatie daarvan.

Service-level objective (SLO, doelstelling op serviceniveau):

Het definieert de doelstelling van de serviceproviders, en is een manier om hun prestatie te meten.

SLA:

Een overeenkomst tussen de serviceprovider en de klant over het verwachte serviceniveau en de verwachte tijd waarin de service wordt geleverd.

Urgentie:

Een maat van hoe snel een incident moet worden opgelost.