En omfattende guide til håndtering af større hændelser i ITIL

Det er mandag morgen, og tingene er temmelig normale ved din servicedesk. Pludselig får du en alarmanmodning om, at en kritisk service er nede, og inden for de næste 15 minutter begynder du at få en tilstrømning af anmodninger, der rapporterer det samme problem. Det kan være, at dit websted er nede, din POS-software er stoppet med at fungere, eller noget endnu mere vidtgående, som fx at børsen går ned eller fly har flyveforbud. Når din virksomhed er hårdt ramt af et IT-problem, der forårsager tab af indtægter og / eller omdømme, har du at gøre med en større hændelse.

Hvordan du reagerer på en større hændelse gør hele forskellen i at minimere virkningen af hændelsen og bringe tjenester tilbage. Som man siger, tid er penge, og i dette tilfælde kunne det ikke være mere sandt. Hvis din organisation har en MIM-process (Major Incident Management) på plads, kan du hurtigt reagere på og løse større hændelser. Hvis du ikke har en sådan proces på plads, er det tid til at udarbejde en beredskabsplan, også kendt som en responsproces på større hændelser.

Indsatsen ved en større hændelse er højere end nogen sinde, og ifølge en undersøgelse fra Information Technology Intelligence Consulting, mister 98 % af organisationer mindst $100.000 grundet en times nedetid. Dette forstærker vigtigheden af at etablere en MIM-proces, der effektivt kan håndtere større hændelser.

Hver organisation sigter mod at eliminere større hændelser, men sagens kerne er, at større hændelser er umulige at forhindre fuldstændigt, og det eneste, du kan gøre, er at være forberedt på dem.

I denne guide skal vi se på, hvordan du etablerer en effektiv MIM-proces, på de almindelige fejl, der kan påvirke din organisations MIM, og bedste praksis til forbedring af din MIM-proces.

Men først, hvad gør en hændelse til en større hændelse?

En større hændelse er et stort, presserende problem, der normalt påvirker hele organisationen eller en stor del af den. En større hændelse resulterer næsten altid i, at en organisations tjenester bliver utilgængelige, hvilket rammer organisationens forretning og i sidste ende påvirker dens økonomiske status. Der er to måder, hvor en større hændelse kan påvirke en organisations tjenester:

• Ved at forhindre kunder i at få adgang til organisationens tjenester. Cloudflare-afbrydelse i juli 2019 er et eksempel på, at kunder bliver påvirket af en større hændelse. Denne store afbrydelse ramte næsten halvdelen af internettet og efterlod millioner af internetbrugere ude af stand til at få adgang til forskellige tjenester.
• Ved at forstyrre medarbejdernes evne til at afslutte deres arbejde til tiden, hvilket fører til en driftsforstyrrelse. IndiGos strømafbrydelse i november 2019 påvirkede flyselskabets indtjekningsproces, hvilket førte til lange forsinkelser og berørte tusinder af passagerer.

En velforberedt servicedesk er udstyret til at kunne vurdere større hændelser og komme med løsninger eller workarounds, der reducerer og kontrollerer virkningen af en større hændelse.

En MIM-proces er et must-have for organisationer, da det hjælper dem med at minimere forretningsmæssig virkning af en større hændelse. MIM-processen består primært af følgende trin:

1. Identifikation

Erklæring om den største hændelse:

Det første trin er at identificere mulige større hændelser. Det er vigtigt for organisationer at oprette flere metoder til at identificere trusler. Større hændelser kan markeres af teknikere, når de støder på usædvanlige anmodninger, eller de kan opdages ved hjælp af løsninger som netværksovervågningsværktøjer, der automatisk kan markere et netværksproblem og oprette en anmodning til at advare servicedesk. Organisationer kan også oprette en dedikeret hotline for servicedesk-personale til at markere mistanke om større hændelser.

Informere interessenter:

Når en større hændelse er identificeret, skal den meddeles til alle vigtigste interessenter. Der er fire hovedgrupper, der skal informeres om større hændelser:

• Teknisk team: Det er vigtigt at informere det tekniske team straks, så de kan begynde at beslutte et handlingsforløb for at løse problemet.
• Ledelse: At holde den øverste ledelse, som informationschef, informeret om større hændelser styrker ansvarlighed. Organisationer bør også holde ledelsen informeret om alle de skridt, der er taget for at løse større hændelser.
• Vigtigste interessenter: Afdelingslederne og forretningsledelse på serviceniveau skal også informeres om større hændelser og ce skal modtage regelmæssige statusopdateringer.
• Brugere: Brugere skal vide, hvilke tjenester der muligvis ikke er tilgængelige på grund af en større hændelse.

2. Inddæmning

Samling af teamet til større hændelser:

Et team til større hændelse (Major Incident Team, MIT) består af teknikere, administrationsledere på serviceniveau og andre vigtige interessenter; undertiden hentes der højt kvalificeret eksternt personale for at håndtere en større hændelse. MIT arbejder sammen for at finde en løsning på den større hændelse og bringe operationerne tilbage til det normale.

Opsætning af en konferencebro:

En konferencebro, mere almindeligt kendt som et telefonmøde, hjælper med effektiv fejlfinding og centraliseret kommunikation. Det fungerer som en klar, hurtig kanal for kommunikation mellem medlemmer af MIT.

Forberedelse af et udpeget strategilokale:

Hvis man har et udpeget strategilokale, kan alle medlemmer af MIT have mulighed for at hente og fejlfinde hændelsen. Dette øger samarbejdsindsatsen, hvilket hjælper MIT med at komme hurtigere med en løsning.

Oprettelse af en problemanmodning til identificering af underliggende problemer:

Der kan oprettes en problemanmodning for at opdage og forstå den grundlæggende årsag til den større hændelse. Dette kan hjælpe med at forhindre lignende større hændelser i fremtiden ved at håndtere årsagerne til den større hændelse.

4. Vedligeholdelse

Udførelse af en gennemgang efter implementering:

Det er vigtigt at lave status over hændelsen over en periode for at sikre, at den virkelig er løst. Hvis underliggende problemer ikke løses, kan de føre til en anden større hændelse.

Oprettelse af klar dokumentation:

Dokumentation af hele processen med at løse den større hændelse hjælper organisationen med at forberede sig på lignende hændelser i fremtiden. Med korrekt dokumentation af tidligere hændelser kan organisationen implementere den afprøvede løsning straks, når den står over for en anden lignende større hændelse, hvilket reducerer dens indvirkning.

Målesystem:

Måling af servicedeskets ydelse hjælper med at måle effektiviteten af servicedesk og MIM-processen. Nogle vigtige parametre, der skal måles, er gennemsnitlig anerkendelsestid (Mean Time to Acknowledge, MTTA), gennemsnitlig løsningstid (Mean Time to Resolve, MTTR), det samlede antal større hændelser, og gennemsnitlig nedetid for større hændelser.

En større hændelse kræver en særlig gruppe af personale til at håndtere og løse den. MIM-roller inkluderer:

Servicedesk-teknikere:

Servicedesk-teknikere er i den første forsvarslinje mod større hændelser. De analyserer hændelsesanmodninger og eskalerer dem til hændelsesmanageren. Servicedesk-teknikere er også involveret i implementeringen af løsninger.

Manager af større hændelse:

Manageren af større hændelse er ejeren af den større hændelse. Hans/hendes rolle omfatter at erklære hændelsen som en større hændelse og sikre, at MIM-processen følges, og at hændelsen løses hurtigst muligt. Manageren fungerer som det vigtigste kontaktpunkt for enhver information om den større hændelse og administrerer MIT.

MIT:

Et MIT er et specialiseret team, der er ansvarlig for at analysere den større hændelse og udarbejde en handlingsplan til håndtering af truslen. MIT består ideelt af servicedesk-teknikere, serviceadministrationspersonale, teknisk personale, andre relevante interessenter og eksterne konsulenter, hvis situationen kræver det.

Teknisk personale:

Det specialiserede personale, der er ansvarlig for vedligeholdelse af infrastruktur og operationer, herunder sysadmins, netværksadministratorer og IT-sikkerhedspersonale, der udgør en organisations tekniske personale. Det tekniske personale hjælper med at fejlfinde den større hændelse og er primært ansvarlig for implementering af løsningen.

Ændringsmanager:

Ændringsmanageren er ejeren af den ændring, der oprettes for at implementere håndteringen af den større hændelse. Ændringsmanageren tager fuldt ejerskab af ændringsanmodningen og er ansvarlig for den.

Problemmanager:

Hvis der oprettes et problem som svar på den større hændelse, ejer problemmanageren problemanmodningen. Problemmanageren forsøger at fastslå de grundlæggende årsager til hændelsen og sikrer, at den ikke forekommer igen, eller at organisationen i det mindste er forberedt til næste gang, hændelsen finder sted.

Eksterne konsulenter eller tredjepartsleverandører:

I nogle tilfælde kan den større hændelse kræve meget specialiseret personale til at hjælpe med at forstå og fejlfinde hændelsen. Manager for den større hændelse identificerer det krævede personale og tilføjer dem til MIT for at hjælpe med at reducere virkningen af hændelsen.

Her er 5 almindelige fejl, der kan hindre din MIM-proces:

1. Manuel kommunikation og eskalering:

   Den absolut største udfordring for MIM er kommunikation. I tilfælde af en større hændelse skal forskellige interessenter informeres om status for hændelsen, dens alvorlighed og hvilken fejlfinding der er gjort for at løse den. At kommunikere alt dette manuelt er en besværlig opgave og kan føre til usammenhængende kommunikation, hvilket kun forværrer tingene. Ved at automatisere processen underrettes vigtige interessenter gennem hele anmodningscyklussen, og manager for den større hændelse kan henlede hele deres opmærksomhed på at løse problemet.

2. Ineffektive kanaler til rapportering af større hændelser:

   Hver servicedesk modtager ti eller endda hundreder af anmodninger om dagen, lige fra problemer med bærbare computere til serviceanmodninger; blandt dette bjerg af anmodninger kunne der være et par potentielle større hændelser. Hvis man ikke opretter en separat kanal til rapportering af større hændelser, kan det forsinke identificeringen af større hændelser.

3. Kopiering af indsats:

   Manglende delegering af opgaver på en organiseret måde kan medføre overlapning af indsatsen inden for MIT. Det er vigtigt at tildele opgaver og holde MIT informeret om, hvad hvert medlem har til opgave.

4. Dårlig dokumentation:

   Manglende korrekt dokumentation tvinger MIT til at genopfinde den dybe tallerken, hver gang en lignende større hændelse opstår, hvilket fører til forsinkelser i løsning af større hændelser og forårsager unødvendig driftsstop.

5. Manglende analyse af den primære årsag:

   I lighed med hændelsesstyring kan MIM være nærsynet, da dens primære fokus er at løse problemet og få tjenester i gang inden for kortest mulig tid. Hvis det ikke kombineres med problemstyring for at identificere underliggende problemer, vil den underliggende årsag til en større hændelse fortsat gøre organisationen sårbar overfor større hændelser.

Her er de bedste måder at gribe MIM-processen an.

1. Aktiver flere kanaler til rapportering om større hændelser:

   Ved håndtering af større hændelser er tiden den vigtigste faktor. Det er vigtigt for organisationer at identificere og klassificere større hændelser, så snart de opdages. Hvis du tilbyder brugere flere måder at rapportere hændelser, kan du gøre hele processen hurtigere og mere tilgængelig. Du kan aktivere oprettelse af anmodninger via e-mail eller en webportal eller endda oprette en dedikeret hotline til at rapportere mistanke om større hændelser. Opsætning af software til netværksovervågning til at opdage afvigelser kan hjælpe dig med proaktivt at håndtere større hændelser.

2. Automatiser servicedesk-processer:

   Hastighed og effektivitet spiller en vigtig rolle i styringen af virkningen af en større hændelse, og automatisering af forskellige servicedesk-processer hjælper med at opnå dette ved at frigøre dine teknikere fra gentagne opgaver, som f.eks. underettelse af interessenter. Automatisering af meddelelsessystemet og etablering af arbejdsgange for større hændelser er gode måder at automatisere servicedesk-processer for at forbedre løsningstiden og bringe struktur til din MIM-proces.

3. Stræb efter hurtig og relevant kommunikation:

   Det er vigtigt at holde din organisations ledelse og vigtige interessenter informeret om enhver større hændelse. At holde ledelsen opdateret vil hjælpe med at få de nødvendige godkendelser og tilladelser, der kræves for at løse den større hændelse. Hurtig kommunikation sikrer, at al personale, der skal håndtere en større hændelse, er på samme side og giver mulighed for et problemfrit, effektivt samarbejde; den holder også slutbrugere informeret om eventuel nedetid, så de kan forberede sig på det.

4. Skab klar dokumentation:

   Klar dokumentation hjælper manageren af større hændelse med at registrere alt det arbejde, der er gjort for at ordne den større hændelse, dens indflydelse, de berørte tjenester og andre centrale oplysninger om den større hændelse. Denne dokumentation er vigtig for at vise ledelsen fordelen ved at have en MIM-proces, herunder dens investeringsafkast. Klar dokumentation vil også hjælpe med at håndtere enhver lignende større hændelse i fremtiden.

5. Brug dybe integrationer med ITOM-software:

   Stærk integration med ITOM-software giver IT-afdelingen mulighed for proaktivt at håndtere større hændelser. Reaktiv identifikation af større hændelser er afhængig af en tilstrømning af anmodninger for at rejse et rødt flag om, at en større hændelse er i gang. På den anden side har en proaktiv MIM-proces, der anvender ITOM-integration, systemer til at overvåge netværk og tjenester, og kan automatisk markere afvigelser, der kan være potentielle større hændelser.

Det er vigtigt at huske, at ikke alle højprioriterede hændelser er større hændelser. Da MIM-processen involverer et betydeligt engagement af ressourcer som implementering af en separat MIT, er det vigtigt omhyggeligt at klassificere større hændelser.

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

Cloudflare-afbrydelse i 2019 er et meget godt eksempel på, hvad der definerer en større hændelse. I dette tilfælde forpurrede en standard driftsprocedure til opdatering af en administreret regel for webapplikations firewall (WAF) brug af CPU'er dedikeret til at betjene HTTP / HTTPS-trafik i næsten 100 procent på tværs af serverne i Cloudflares netværk. Den udfaldstid, der fulgte, resulterede i en reduktion på 80 procent af Cloudflares trafik og påvirkede millioner af internetbrugere over hele verden.

Påvirkning: Stor

Udfaldstiden resulterede i, at Cloudflare-kunder (og deres kunder) så en 502-fejlside, når de besøgte ethvert Cloudflare-domæne. 502-fejlene blev genereret af de forreste Cloudflare-webservere, der stadig havde CPU-kerner, men ikke var i stand til at nå de processer, der betjener HTTP / HTTPS-trafik. Det anslås, at mindst halvdelen af hele internettet var utilgængeligt i de syvogtyve minutter af nedetid.

Vigtighed: Høj

Alle Cloudflare-websteder var utilgængelige, hvilket forårsagede serviceforstyrrelser for tusinder af organisationer og millioner af brugere. Udfaldstiden påvirkede også de interne operationer i Cloudflare og forhindrede Cloudflare-medarbejderne i at få adgang til forskellige tjenester, såsom firmaets ændringsstyringsværktøj og det interne kontrolpanel. Udfaldstiden måtte håndteres for at genoptage normal serviceoperation.

Tidslinje for hændelser fra detektion til løsning:

WAF-styrede regel blev implementeret kl. 13:42; tre minutter senere begyndte Cloudflares netværksoperationsværktøjer at markere faldet i trafik, mange andre ende-til-ende-tests af Cloudflare-tjenester begyndte at mislykkes, slutbrugerne bemærkede forskellige 502-fejl, og Cloudflare modtog mange rapporter om CPU-overbelastning fra dens punktspålogninger i byer over hele verden.

Teknikere, der stod for webstedets pålidelighed, Londons tekniker-team og andre relevante team blev samlet til fejlfinding og til at finde en løsning. Kl. 14.00 blev WAF identificeret som årsagen til hændelsen. Og klokken 14:07 blev et globalt WAF-kill implementeret for at bringe trafikniveauer tilbage til det normale.

Ved 14:52 var Cloudflare 100 procent tilfreds med, at den forstod årsagen til udfaldet og havde en rettelse på plads, så WAF blev genaktiveret globalt.

Ændring

Tilføjelse, ændring eller fjernelse af noget, der kan have en direkte eller indirekte indvirkning på tjenester.

Styring af ændring:

Processen med at tage ændringer til færdiggørelse med minimale forstyrrelser og kollisioner.

Eskalering:

Overførsel at ejerskab af en anmodning baseret på et funktionelt eller hierarkisk behov.

Begivenhed:

En begivenhed, der har betydning for styringen af en tjeneste eller et aktiv.

Fejl:

En begivenhed, hvor en tjeneste eller et aktiv ikke fungerer i henhold til den aftalte SLA.

Hierarkisk eskalering:

Overførsel af ejerskabet lodret til en servicedesk-tekniker eller en højere relevant myndighed.

Påvirkning:

Måling af alvorsgraden af en hændelse.

Hændelse:

En ikke-planlagt afbrydelse af en IT-service eller en reduktion i kvaliteten af en IT-service. Fejl i et konfigurationselement, selvom det endnu ikke har påvirket en tjeneste, er også en hændelse (f.eks. en fejl på en disk fra et spejlsæt).

Hændelsesadministration:

Processen med at styre livscyklussen for alle hændelser for at gendanne normale servicefunktioner så hurtigt som muligt og minimere påvirkning af forretningen.

Prioritering af hændelser:

Tildeling af prioriteter til hændelser og definition af, hvad der udgør en større hændelse.

Større hændelse:

En hændelse, der har stor indvirkning og stor presserende karakter, der kræver en separat proces fra hændelsesstyring.

Manager af større hændelse:

Den person, der er ansvarlig for MIT og implementeringen af MIM-processen.

Gennemsnitlig anerkendelsestid (Mean Time to Acknowledge, MTTR):

En måling af, hvor hurtigt en hændelse anerkendes af servicedesken.

Gennemsnitlig tid til at opdage (Mean Time to Detect, MTTD):

En måling af, hvor hurtigt en potentiel trussel mod en tjeneste eller konfigurationselement registreres.

Gennemsnitstid mellem fiasko (Means Time Between Failure, MTBF):

En måling af, hvor ofte en tjeneste eller et aktiv fejler.

Gennemsnitstid til reparation / løsning / reaktion / gendannelse (MTTR):

En måling af, hvor hurtigt en service gendannes efter fejl.

Normal service:

En serviceoperation, der overholder serviceniveauaftalen (SLA).

Problem:

En årsag eller mulig årsag til en eller flere hændelser.

RACI-matrix:

Definerer roller og ansvar i tværfunktionelle eller afdelingsprojekter og processer.

Servicedesk:

Kommunikationssted mellem tjenesteudbydere og organisationens brugere.

Servicedesk-manager:

Den, der fører tilsyn med de daglige aktiviteter i servicedesken og er ansvarlig for dens ydeevne.

Mål på serviceniveau:

Definerer målsætningen for tjenesteudbyderne og er et middel til at måle deres ydeevne.

SLA:

En aftale mellem tjenesteudbyderen og kunden om det forventede serviceniveau og det forventede tidspunkt, hvor det leveres.

Vigtighed:

Et mål for, hvor hurtigt en hændelse skal løses.