Flowchart til klassificering af hændelsers alvorlighed

Flowchart til klassificering af hændelsers alvorlighed: et beslutningstræ, der fører tests af tilgængelighed, omfang, forretningskonsekvens og eksponering frem til P1, P2, P3 eller P4.

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.

Brug denne skabelon

Mere i IT-skabeloner til procesdiagrammer

Mere i Skabeloner til procesdiagrammer

Browse all IT-skabeloner til procesdiagrammer