En omfattande guide för hantering av allvarliga incidenter inom ITIL

Det är måndag morgon och allt är som vanligt vid din servicedesk. Plötsligt får du ett varningsärende om att en kritisk tjänst är nere, och inom de kommande 15 minuterna börjar du få en tillströmning av ärenden som rapporterar samma problem. Det kan vara så att din webbplats är nere, din försäljningsplats har upphört att fungera eller något ännu mer långtgående, som till exempel att börsen kraschar eller flygplan som inte lyfter. Du har att göra med en allvarlig incident när ditt företag är svårt påverkat av ett IT-problem som leder till förlorade intäkter och/eller skadat rykte.

Hur du reagerar på en allvarlig incident är avgörande när det gäller att minimera effekterna av incidenten och återföra tjänsterna. Tid är som sagt pengar, och det stämmer extra väl i det här fallet. Om din organisation har en MIM-process (hantering av allvarliga incidenter) kan du snabbt svara på och åtgärda allvarliga incidenter. Om du inte har en sådan process är det dags att utarbeta en beredskapsplan, vilket även kallas för en process för respons på allvarliga incidenter.

Mer än någonsin står på spel vid en allvarlig incident, och enligt en studie från Information Technology Intelligence Consulting förlorar 98 procent av organisationerna minst 100 000 USD vid en timmes driftstopp. Detta förstärker vikten av att inrätta en MIM-process som effektivt kan hantera allvarliga incidenter.

Varje organisation har som mål att eliminera allvarliga incidenter, men det är viktigt att förstå att det inte går att helt förebygga allvarliga incidenter och att det enda du kan göra är att vara förberedd på dem.

I den här guiden tittar vi på hur du skapar en effektiv MIM-process, vanliga misstag som kan påverka din organisations MIM och bästa praxis för att förbättra din MIM-process.

Men innan vi börjar, vad gör en incident till en allvarlig incident?

En allvarlig incident är en brådskande fråga med stor påverkan som vanligtvis berör hela organisationen eller en stor del av den. En allvarlig incident leder nästan alltid till att en organisations tjänster blir otillgängliga, vilket drabbar organisationens verksamhet och slutligen påverkar dess ekonomiska ställning. En allvarlig incident kan påverka en organisations tjänster på två sätt:

• Den kan hindra kunder från att komma åt organisationens tjänster. Cloudflare-avbrottet i juli 2019 är ett exempel på att kunder som påverkas av en allvarlig incident. Detta omfattande avbrottet drabbade nästan hälften av internet och lämnade miljontals internetanvändare som inte kunde komma åt olika tjänster.
• Den stör anställdas förmåga att slutföra sitt arbete i tid, vilket leder till en affärsstörning. IndiGos avbrott i november 2019 påverkade flygbolagets incheckningsprocess, vilket ledde till långa förseningar och drabbade tusentals passagerare.

En väl förberedd servicedesk är rustad att utvärdera allvarliga incidenter och komma med lösningar för att minska och kontrollera effekterna av en allvarlig incident.

En MIM-process är ett måste för organisationer, eftersom det hjälper dem att minimera effekten som en allvarlig incident har på affärsverksamheten. MIM-processen består huvudsakligen av följande stadier:

1. Identifiering

Förklara den allvarliga incidenten:

Det första steget är att identifiera möjliga allvarliga incidenter. Det är viktigt för organisationer att skapa flera metoder för att identifiera hot. Allvarliga incidenter kan flaggas av tekniker när de stöter på ovanliga ärenden, eller så kan de upptäckas av lösningar som exempelvis nätverksövervakningsverktyg som automatiskt kan flagga ett nätverksproblem och skapa ett ärende för att varna serviceavdelningen. Organisationer kan också inrätta en dedikerad hotline som servicepersonal kan använda för att flagga misstänkta allvarliga incidenter.

Informera intressenter:

När en allvarlig incident har identifierats måste den meddelas till alla viktiga intressenter. Det finns fyra huvudgrupper som måste informeras om allvarliga incidenter:

• Tekniskt team: Det är viktigt att informera det tekniska teamet omedelbart så att de kan börja besluta om en åtgärd för att lösa problemet.
• Ledning: Det underlättar arbetet med att tilldela ansvar om ledningen, som t.ex. CIO, hålls informerad om allvarliga incidenter. Organisationer ska också hålla ledningen informerad om alla åtgärder som vidtagits för att åtgärda allvarliga incidenter.
• Viktiga intressenter: Avdelningschefer och personal på servicenivå måste också informeras om allvarliga incidenter och få regelbundna statusuppdateringar.
• Användare: Användare måste veta vilka tjänster som kan vara otillgängliga på grund av en allvarlig incident.

2. Inneslutning

Sammansättning av teamet för hantering av allvarliga incidenter:

Ett team för hantering av allvarliga incidenter, eller kortfattat MIT, består av tekniker, chefer på servicenivå och andra viktiga intressenter. Ibland inkluderas även högkvalificerad extern personal för att hantera en allvarlig incident. MIT samarbetar för att hitta en lösning på den allvarliga incidenten och återställa affärsverksamheten.

Skapa en konferensbro:

En konferensbro, mer känd som ett konferenssamtal, bidrar till effektiv felsökning och centraliserad kommunikation. Det fungerar som en tydlig och snabb kommunikationskanal mellan MIT-medlemmar.

Förbereda en dedikerad kontrollcentral:

En dedikerad kontrollcentral gör att alla medlemmar i MIT kan samla in och felsöka incidenten. Detta ökar samarbetsinsatserna, vilket hjälper MIT att komma fram till en lösning snabbare.

Skapa ett problemärende för att identifiera underliggande problem:

Ett problemärende kan skapas för att upptäcka och förstå grundorsaken till den allvarliga incidenten. Detta kan bidra till att förebygga liknande allvarliga incidenter i framtiden genom att ta itu med orsakerna till den allvarliga incidenten.

4. Underhåll

Utföra en granskning efter implementering:

Det är viktigt att utreda incidenten under en tid för att se till att den verkligen är åtgärdad. Om underliggande problem inte åtgärdas kan det leda till ytterligare en allvarlig incident.

Utarbeta tydlig dokumentation:

Dokumentering av hela processen för att åtgärda den allvarliga incidenten hjälper organisationen att förbereda sig för liknande incidenter i framtiden. Med korrekt dokumentation av tidigare incidenter kan organisationen implementera den beprövade lösningen omedelbart när man stöter på en annan liknande allvarlig incident, vilket minskar dess inverkan.

Mäta mätvärden:

Det är enklare att uppskatta effektiviteten hos servicedesk och MIM-processen om man mäter dess prestanda. Några viktiga mätvärden att mäta är MTTA (Mean Time to Acknowledge, genomsnittlig tid till erkännande), MTTR (Mean Time to Resolve, genomsnittlig tid till åtgärdande), totalt antal allvarliga incidenter och genomsnittlig driftstopp för allvarliga incidenter.

En allvarlig incident uppmanar en speciell grupp personal att ta itu med incidenten och åtgärda den. MIM-roller inkluderar:

Servicetekniker:

Servicetekniker är den första försvarslinjen mot allvarliga incidenter. De analyserar incidentärenden och eskalerar dem till den incidentansvarige. Servicetekniker är också involverade i implementeringen av lösningar.

Ansvarig för allvarliga incidenter:

Ansvarig av allvarliga incidenter är den som ansvarar för den allvarliga incidenten. Deras roll innefattar att förklara incidenten som en allvarlig incident och se till att MIM-processen följs och incidenten åtgärdas omgående. De fungerar som den primära kontaktpunkten för all information om den allvarliga incidenten och hanterar MIT.

MIT:

En MIT är ett specialiserat team som ansvarar för att analysera den allvarliga incidenten och formulera en handlingsplan för att hantera hotet. MIT består allra främst av servicetekniker, personal på servicenivå, teknisk personal, andra relevanta intressenter och externa konsulter om situationen kräver det.

Teknisk personal:

Den specialiserade personalen som ansvarar för underhållet av infrastruktur och drift, inklusive sysadmins, nätverksadministratörer och informationssäkerhetspersonal, som utgör en organisations tekniska personal. Den tekniska personalen arbetar med att felsöka den allvarliga incidenten och är huvudsakligen ansvarig för att implementera lösningen på den allvarliga incidenten.

Ändringsansvarig:

Ändringsansvarig är personen som ansvarar för den ändring som skapas för att implementera lösningen på den allvarliga incidenten. Den ändringsansvarige tar fullt ansvar för ändringsärendet.

Problemansvarig:

Det är problemansvarig som ansvarar för problemärendet om ett problemärende skapas som svar på den allvarliga incidenten. Problemansvarig försöker fastställa rotorsakerna till incidenten och se till att den inte inträffar igen, eller att organisationen åtminstone är beredd nästa gång incidenten inträffar.

Externa konsulter eller tredje parts leverantörer:

I vissa fall kan den allvarliga incidenten kräva högt specialiserad personal för att förstå och felsöka incidenten. Ansvarig för allvarliga incidenter identifierar den nödvändiga personalen och inkluderar dem i MIT för att minska effekterna av den allvarliga incidenten.

Här är 5 vanliga misstag som kan störa din MIM-process:

1. Manuell kommunikation och eskalering:

   Den absolut största utmaningen för MIM är kommunikation. Vid en allvarlig incident måste olika intressenter informeras om incidentens status, hur allvarligt den är och vilken felsökning som har gjorts för att åtgärda den. Att kommunicera allt detta manuellt är en besvärlig uppgift och kan leda till inkonsekvent kommunikation, vilket bara förvärrar saken. En automatiserad process meddelar viktiga intressenter under hela ärendets livscykel, och ansvarig för allvarliga incidenter kan fokusera hela sin uppmärksamhet på att lösa problemet.

2. Ineffektiva kanaler för rapportering av allvarliga incidenter:

   Varje serviceavdelning tar emot tiotals eller till och med hundratals ärenden om dagen, vilka handlar om allt från problem med bärbara datorer till serviceförfrågningar. Bland detta berg av ärenden kan det finnas några potentiella allvarliga incidenter. Om en separat kanal för att rapportera allvarliga incidenter inte skapas leder det till försenad identifieringen av allvarliga incidenter.

3. Dubbelarbete:

   Underlåtenhet att delegera uppgifter på ett organiserat sätt kan orsaka dubbelarbete inom MIT. Det är viktigt att tilldela uppgifter och hålla MIT informerad om vad varje medlem har i uppdrag.

4. Dålig dokumentation:

   Brist på korrekt dokumentation tvingar MIT att återuppfinna hjulet varje gång en liknande allvarlig incident inträffar, vilket leder till förseningar i att lösa allvarliga incidenter, vilket i sin tur orsakar onödigt driftsstopp.

5. Underlåtenhet att analysera grundorsaken:

   MIM kan i likhet med incidenthanteringen vara omedveten om sin omgivning eftersom dess primära fokus är att åtgärda problemet och återställa tjänster så snabbt som möjligt. Om problemhantering inte inkluderas för att identifiera underliggande problem, kommer den bakomliggande orsaken till en allvarlig incident fortsätta att göra organisationen sårbar för allvarliga incidenter.

Här är de bästa sätten att sköta MIM-processen.

1. Aktivera flera kanaler för rapportering av allvarliga incidenter:

   Tid är viktigt när det gäller hantering av allvarliga incidenter. Det är viktigt för organisationer att identifiera och klassificera allvarliga incidenter så snart de upptäcks. Om användare har flera sätt att rapportera incidenter gör det hela processen snabbare och mer tillgänglig. Du kan göra det möjligt att skapa ärenden via e-post eller en webbportal, eller till och med skapa en dedikerad hotline för att rapportera misstänkta större incidenter. Nätverksövervakningsprogramvara som upptäcker avvikelser kan hjälpa dig att proaktivt hantera allvarliga incidenter.

2. Automatisera servicedeskprocesser:

   Hastighet och effektivitet är viktigt för att kontrollera effekterna av en allvarlig incident och automatisering av olika serviceprocesser bidrar till att uppnå detta genom att frigöra dina tekniker från repetitiva uppgifter som att meddela intressenter. Automatisering av meddelandesystemet och skapande av arbetsflöden för allvarliga incidenter är bra sätt att automatisera servicedeskprocesser för att förbättra upplösningstiden och strukturisera din MIM-process.

3. Sträva efter snabb, relevant kommunikation:

   Det är viktigt att hålla din organisations ledning och viktiga intressenter informerade om varje allvarlig incident. Om ledningen hålls uppdaterar blir det enklare att få nödvändiga godkännanden och behörigheter som krävs för att åtgärda den allvarliga incidenten. Snabb kommunikation säkerställer att all personal som arbetar med allvarliga incidenter har samma mål och möjliggör ett smidigt och effektivt samarbete. Det ser dessutom till att slutanvändarna är informerade om eventuell driftstopp så att de kan förbereda sig för det.

4. Skapa tydlig dokumentation:

   Tydlig dokumentation hjälper ansvarig för allvarliga incidenter att registrera allt arbete som gjorts för att åtgärda den allvarliga incidenten, dess inverkan, de drabbade tjänsterna och annan viktig information om den allvarliga incidenten. Denna dokumentation är viktig för att visa ledningen fördelarna med att ha en MIM-process, inklusive dess ROI. Tydlig dokumentation kommer också att hjälpa till med alla liknande större händelser i framtiden.

5. Använd djupa integrationer med ITOM-programvaran:

   Starka integrationer med ITOM-programvaran gör det möjligt för IT-avdelningen att proaktivt hantera allvarliga incidenter. Reaktiv identifiering av allvarliga incidenter beror på en tillströmning av ärenden för att höja en röd flagga om att en allvarlig incident pågår. Å andra sidan har en proaktiv MIM-process som använder ITOM-integrationer system för att övervaka nätverk och tjänster och kan automatiskt flagga avvikelser som kan vara potentiella allvarliga incidenter.

Det är viktigt att komma ihåg att inte alla högprioriterade incidenter är allvarliga incidenter. Eftersom MIM-processen innebär ett betydande åtagande av resurser som att implementera en separat MIT, är det viktigt att noggrant klassificera allvarliga incidenter.

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

Cloudflare-avbrottet under 2019 är ett mycket bra exempel på vad som definierar en allvarlig incident. I det här fallet orsakade en standardiserad verksamhetsprocedur för uppdatering av en hanterad regel för webbapplikationens brandvägg (WAF) en ökning i användningen av CPU:er avsedda för att stöda HTTP/HTTPS-trafik till nästan 100 procent över servrarna i Cloudflares nätverk. Följande avbrott resulterade i en minskning med 80 procent av Cloudflares trafik och påverkade miljontals internetanvändare runt om i världen.

Inverkan: Stor

Avbrottet resulterade i att Cloudflare-kunder (och deras kunder) såg en 502-felsida när de besökte någon Cloudflare-domän. 502-felen genererades av Cloudflare-webbservrarna i klientdelen som fortfarande hade CPU-kärnor tillgängliga men som inte kunde nå processerna som stöder HTTP/HTTPS-trafik. Uppskattningsvis var åtminstone hälften av hela Internet otillgängliga under det 24 minuter långa driftstoppet.

Bråttom: Hög

Alla Cloudflare-webbplatser var otillgängliga, vilket orsakade servicestörningar för tusentals organisationer och miljoner användare. Avbrottet påverkade också den interna verksamheten i Cloudflare och förhindrade Cloudflare-anställda från att komma åt olika tjänster som företagets verktyg för ändringshantering och den interna kontrollpanelen. Avbrottet måste hanteras för att återuppta normal serviceverksamhet.

Tidslinje för händelser från detektering till upplösning:

Den WAF-hanterade regeln implementerades kl 13.42. Tre minuter senare började Cloudflares nätverksverktyg att flagga minskningen av trafiken, många andra heltäckande tester av Cloudflare-tjänster började sluta fungera, slutanvändare stötte på olika 502-fel och Cloudflare fick många rapporter om CPU-utmattning från sina anslutningspunkter i städer över hela världen.

Anläggningens tillförlitlighetsteam, Londons teknikerteam och andra relevanta team samlades för att felsöka och komma med en lösning. Klockan 14.00 identifierades WAF som orsaken till incidenten. Klockan 14.07 genomfördes ett globalt WAF-stopp för att återföra trafiknivåerna till det normala.

Klockan 14.52 var Cloudflare 100 procent övertygade att man förstod orsaken till avbrottet och hade en korrigering, så WAF aktiverades globalt igen.

Ändring:

Tillägg, ändring eller borttagning av allt som kan ha en direkt eller indirekt inverkan på tjänsterna.

Ändringshantering:

Processen att slutföra ändringar med minimalt med störningar och kollisioner.

Eskalering:

Handlingen att överföra ansvaret för ett ärende baserat på ett funktionellt eller hierarkiskt behov.

Händelse:

En händelse som har betydelse för hanteringen av en tjänst eller tillgång.

Fel:

En händelse där en tjänst eller tillgång inte fungerar enligt det överenskomna SLA.

Hierarkisk eskalering:

Handlingen att överföra ansvar vertikalt till en servicetekniker på högre nivå eller person med relevant auktoritet.

Inverkan:

Ett mått på en incidents allvarlighetsgrad.

Incident:

Ett oplanerat avbrott i en IT-tjänst eller en minskning av kvaliteten på en IT-tjänst. Fel hos ett konfigurationsobjekt, även om det ännu inte har påverkat en tjänst, är också en incident (t.ex. fel på en disk från en spegeluppsättning).

Incidenthantering:

Processen för att hantera livscykeln för alla incidenter för att återställa normal serviceverksamhet så snabbt som möjligt och minimera inverkan på affärsverksamheten.

Prioritering av incidenter:

Tilldela prioriteringar till incidenter och definiera vad som utgör en allvarlig incident.

Allvarlig incident:

En händelse som har stor inverkan och är mycket brådskande, som kräver en separat process från incidenthantering.

Ansvarig för allvarliga incidenter:

Personen som är ansvarig för MIT och implementeringen av MIM-processen.

MTTA (genomsnittlig tid till bekräftande):

Ett mått på hur snabbt en incident bekräftas av servicedesken.

MTTD (genomsnittlig tid till detektering):

Ett mått på hur snabbt ett potentiellt hot mot en tjänst eller konfigurationsobjekt upptäcks.

MTBF (genomsnittlig tid mellan fel):

Ett mått på hur ofta fel uppstår i tjänst eller tillgång.

MTTR (genomsnittlig tid till reparation/upplösning/återställning):

Ett mått på hur snabbt en tjänst återställs efter fel.

Normal serviceverksamhet:

En serviceverksamhet som följer servicenivåavtalet (SLA).

Problem:

En orsak eller potentiell orsak till en eller flera incidenter.

RACI-matris:

Den definierar roller och ansvar i tvärfunktionella projekt eller processer och avdelningar.

Servicedesk:

Kommunikationspunkten mellan tjänsteleverantörer och organisationens användare.

Ansvarig för servicedesk:

Den som övervakar servicedeskens dagliga aktiviteter och ansvarar för dess prestanda.

Mål på tjänstenivå (SLO):

Den definierar tjänsteleverantörernas mål och är ett sätt att mäta deras prestanda.

SLA:

Ett avtal mellan tjänsteleverantören och kunden om den förväntade servicenivån och den förväntade tiden då den levereras.

Bråttom:

Ett mått på hur snabbt en incident måste lösas.