Flowchart til klassificering af hændelsers alvorlighed

Hvad er flowchart til klassificering af hændelsers alvorlighed?

Klassificering af alvorlighed er det trin, der omsætter en anmeldelse til et niveau. Nogen læser beviserne, anvender et aftalt sæt tests og lander på P1, P2, P3 eller P4, og alt nedstrøms hænger på det svar. Det er værd at holde adskilt fra prioritet fra starten, for de to ord bruges i flæng og bliver derefter diskuteret midt i en hændelse. Alvorlighed beskriver konsekvensen og dermed den respons, I skylder: hvem der tilkaldes, om der åbnes en bro, og hvor ofte interessenter opdateres. Prioritet beskriver rækkefølgen: hvad teamet tager fat på næste gang. Alvorlighed vurderes ud fra beviser og flytter sig kun, når beviserne flytter sig; prioritet kan sættes om hver morgen, uden at nogen genåbner konsekvensvurderingen.

Denne side er et beslutningstræ, ikke et proceskort, og det er derfor, den findes for sig. Den besvarer ét spørgsmål: hvilket niveau får denne hændelse, og hvem har ret til at afgøre det. Det gør den ved at kæde syv tests sammen, indtil hver vej ender i et navngivet udfald. Den stopper bevidst i det øjeblik, niveauet er sat. Har I brug for hele forløbet derefter (hvordan sagen diagnosticeres, eskaleres, løses, bekræftes med brugeren og lukkes på tværs af servicedesk, hændelsesleder og supportniveauer), så brug i stedet skabelonen til hændelseshåndtering. Brug dette diagram til at afgøre niveauet; brug den anden til at køre arbejdet.

Banerne her navngiver beslutningsret frem for afdelinger, og det er netop den del, de fleste alvorlighedsmatricer lader være underforstået. Servicedesken svarer på det, der kan aflæses af anmeldelsen: er servicen utilgængelig eller forringet, og hvor mange brugere eller lokationer er berørt. Serviceejeren svarer på, om en kritisk forretningsfunktion eller en omsætningsstrøm reelt er blokeret. Hændelseslederen ejer workaround-testen, selve erklæringen og evalueringen. Jura og compliance ejer to spørgsmål og intet andet: er der en data- eller sikkerhedseksponering, og løber der en lovbestemt eller kontraktlig frist. Fire baner er nok til at afgøre hvem-bestemmer-diskussionen uden at tegne et organisationsdiagram.

Hvad dette flowchart dækker

I denne skabelon

• Fire baner med beslutningsret frem for et afdelingskort (Servicedesk, Serviceejer, Hændelsesleder samt Jura og compliance) fordelt på fem vurderingsfaser: Modtagelse, Omfang af påvirkning, Forretningsmæssig konsekvens, Alvorlighedsbeslutning samt Udfald og evaluering
• Den indledende test, 'Er servicen utilgængelig eller forringet?', med tre svar: 'Utilgængelig' og 'Forringet' fortsætter ned i træet, mens 'Ingen påvirkning' straks ender i 'Lukket som serviceanmodning', så en anmodning eller et spørgsmål aldrig får tildelt en alvorlighedsgrad
• Omfang vurderes før forretningsmæssig konsekvens: 'Hvor mange brugere eller lokationer er berørt?' deler sig i 'Flere lokationer', der går direkte til en P1-erklæring, 'Ét team', der sendes videre til serviceejeren, og 'Én bruger', der stadig tjekkes for eksponering
• To uafhængige veje til kritisk: 'Er en kritisk funktion eller omsætning blokeret?', der føder 'Findes der en brugbar workaround?', hvor 'Ingen workaround' erklærer P1 og 'Workaround' tildeler P2, og 'Data- eller sikkerhedseksponering?', hvor 'Eksponering' erklærer P1 uanset hvor få brugere der er berørt
• Den lave ende af matricen afgjort af ét spørgsmål, 'Løber en SLA- eller lovbestemt frist?', der adskiller 'P3 mellem, frist overvåges' fra 'P4 lav, planlagt arbejde' frem for at overlade det til et skøn, i alt fem forskellige slutpunkter sammen med 'P1 kritisk, bro åben', 'P2 høj, rettelse i gang' og udgangen til lukket serviceanmodning, plus en eksplicit vej til omklassificering, hvor 'Har påvirkningen ændret sig ved næste opdatering?' sender 'Påvirkning vokset' tilbage til P1-erklæringen
• Nedskrevne kriterier på de afgørende beslutninger: hvad utilgængelig betyder, hvor grænserne for brugere og lokationer ligger, hvad der tæller som en brugbar workaround, og hvorfor en eksponering behandles som kritisk uanset omfang

Hvornår du skal bruge skabelonen

• I skal skrive de alvorlighedsdefinitioner ned, som teamet i dag diskuterer, så to personer, der triagerer den samme hændelse klokken tre om natten, når frem til samme niveau uden at forhandle
• I konfigurerer et ITSM- eller vagtværktøj, hvor alvorlighed er et obligatorisk felt, og I har brug for testene bag hvert niveau i stedet for en dropdown med fire valg og ingen vejledning
• I skal aftale beslutningsret før en nedbrudssituation frem for under den: hvem må erklære en P1, hvem bekræfter en data- eller sikkerhedseksponering, og hvem må omklassificere
• I evaluerer en tidligere hændelse for at se, om det tildelte niveau passede til de beviser, der forelå på tidspunktet, hvilket er et andet spørgsmål end, om responsen var god
• I onboarder vagthavende ingeniører og nye servicedesk-medarbejdere, der har brug for én side med spørgsmålene, grænseværdierne og hvor hvert svar lander

Sådan fungerer det

1. Omdøb banerne til jeres faktiske beslutningsret

   Erstat servicedesk, serviceejer, hændelsesleder samt jura og compliance med de roller, der reelt holder hver beslutning hos jer. Er der ingen, der ejer data- og sikkerhedsspørgsmålet uden for arbejdstid, er det et hul i vagtplanen, I skal lukke, før I tegner banen om.

2. Skriv jeres grænseværdier for omfang ind i diagrammet

   Åbn 'Hvor mange brugere eller lokationer er berørt?' og erstat kommentaren med jeres egne definitioner af flere lokationer, ét team og én bruger: en region, et kundesegment, en procentdel af aktive brugere eller en navngiven kundeliste. Grænser, der ikke er skrevet ned, bliver genforhandlet ved hver eneste hændelse.

3. Definér utilgængelig over for forringet for jeres services

   Bliv enige om, hvad 'Utilgængelig' betyder service for service, også for de delvise tilfælde som read-only-tilstand, en fejlet region eller en kø, der stadig tager imod arbejde, men ikke afvikler det. Tvetydighed her flytter hele træet et niveau.

4. Sæt workaround-testen ærligt

   Beslut, hvad der gør en workaround brugbar: dokumenteret, tilladt, inden for kapacitet og anvendelig for de berørte brugere i dag. En manuel nødløsning, der kræver oplæring, ekstra bemanding eller en dispensation, er ikke en workaround, og at behandle den som en er den mest almindelige måde, en P1 bliver registreret som en P2.

5. Knyt en tydelig responsforpligtelse til hvert udfald

   Hvert af udfaldene 'P1 kritisk, bro åben', 'P2 høj, rettelse i gang', 'P3 mellem, frist overvåges' og 'P4 lav, planlagt arbejde' skal have sin egen tilkaldelsesregel, opdateringsfrekvens og måltider. Giver to niveauer nøjagtig samme adfærd, så slå dem sammen frem for at beholde et niveau, ingen kan skelne.

6. Aftal hvem der må omklassificere, og notér begrundelsen

   Beslutningen 'Har påvirkningen ændret sig ved næste opdatering?' er den eneste godkendte vej til at ændre et niveau. Navngiv, hvem der må tage den, kræv at testene køres igen frem for at niveauet genforhandles, og notér de nye beviser og tidspunktet, så evalueringen bagefter kan se, hvornår billedet ændrede sig.

7. Send diagrammet til godkendelse, og gem versionen

   Alvorlighedskriterier er kun nyttige, hvis de er de aftalte. Del diagrammet med service management, serviceejerne og jura til underskrift, og gem derefter den godkendte version, så de definitioner, I øver på, er de definitioner, I har udgivet.

Ofte stillede spørgsmål

Hvad er forskellen på en hændelses alvorlighed og dens prioritet?

Alvorlighed er et udsagn om konsekvens: hvor meget af servicen er i stykker, for hvor mange, og hvad blokerer det. Prioritet er et udsagn om rækkefølge: hvad teamet tager fat på næste gang. ITIL bruger faktisk ikke 'alvorlighed' som formel term; her udledes prioritet af konsekvens og hastende karakter. Mange udviklings- og SRE-teams bruger alvorlighed som en kortform for konsekvensdelen, og det er sådan, diagrammet bruger ordet. Den praktiske regel er, at alvorlighed styrer den respons, I skylder (tilkald, bro, opdateringsfrekvens) og kun ændrer sig, når beviserne ændrer sig, mens prioritet styrer køen og kan sættes om dagligt. Ét felt til hver forhindrer, at folk genforhandler konsekvensvurderingen for at få hurtigere service.

Hvordan adskiller dette sig fra et flowchart for hændelseshåndtering?

De besvarer forskellige spørgsmål om det samme emne. Dette diagram er et beslutningstræ: hvilket alvorlighedsniveau får denne hændelse, og hvem har ret til at afgøre det. Det er en kæde af tests, der ender i navngivne udfald, og det stopper, så snart niveauet er sat. Et flowchart for hændelseshåndtering er et tværfunktionelt proceskort: hvad sker der derefter, og hvem gør det: fra registrering over diagnose, eskalering og løsning til lukning. De fleste teams har brug for begge, og de mødes præcis ét sted: i det trin, hvor et niveau tildeles.

Hvor mange alvorlighedsniveauer bør vi have?

Fire er standardvalget og det, dette diagram bruger, og enkelte organisationer lægger en P0 eller SEV0 oven over til eksistentielle hændelser. Antallet betyder mindre end, om hvert niveau bærer en tydelig, nedskrevet respons. Fører P3 og P4 til samme tilkaldelsesregel, samme måltider og samme opdateringsfrekvens, har I tre niveauer og en ubrugt etiket. Færre niveauer anvendt konsekvent slår flere niveauer anvendt løseligt, for værdien af klassificeringen er, at alle nedstrøms kan handle på den uden at spørge.

Hvem må erklære en P1?

Navngiv rollen på forhånd, og hold listen kort. I dette diagram ligger erklæringen i hændelsesleder-banen, og tre selvstændige grene fører ind i den: et nedbrud på tværs af flere lokationer, en blokeret kritisk funktion uden brugbar workaround, og en bekræftet data- eller sikkerhedseksponering. Den struktur er bevidst, for en P1 bør kunne nås af beviser fra mere end én retning, men erklæres af en rolle, der også kan forpligte responsen. Alle bør kunne anmode om en P1; en navngiven rolle bekræfter den.

Gør en data- eller sikkerhedseksponering automatisk hændelsen til en P1?

I dette diagram ja, og eksponeringsgrenen springer helt uden om testen af antal brugere. Grunden er, at en eksponering starter en frist, der løber fra kendskab og ikke fra løsning, så en lille hændelse kan bære en stor forpligtelse. Efter GDPR skal et brud på persondatasikkerheden anmeldes til tilsynsmyndigheden uden unødig forsinkelse og om muligt inden 72 timer efter, at man er blevet bekendt med det, mens underretning af de berørte personer er en selvstændig vurdering knyttet til høj risiko. Andre regelsæt og kontrakter har deres egne frister, og kunders varslingsfrister er ofte kortere end de lovbestemte, så skriv dem, der gælder jer, ind i beslutningsboksen. Mange organisationer sender desuden eksponeringer helt ud af dette træ og over i en proces for håndtering af sikkerhedshændelser.

Hvornår bør et alvorlighedsniveau ændres, efter det er sat?

Når beviserne ændrer sig, ikke når presset gør. Diagrammet giver det én rute, beslutningen 'Har påvirkningen ændret sig ved næste opdatering?', hvis gren 'Påvirkning vokset' sender en P2 tilbage til P1-erklæringen. Kør testene igen frem for at genåbne diskussionen, og notér hvilke nye beviser der kom, og hvornår. Nedjusteringer følger samme regel og er værd at håndtere eksplicit, for en hændelse, der bliver på P1, efter konsekvensen er aftaget, lærer stille og roligt folk at ignorere niveauet.