Incident-Schweregrad einstufen: Entscheidungsbaum P1 bis P4

Was ist incident-schweregrad einstufen: entscheidungsbaum p1 bis p4?

Die Einstufung des Schweregrads ist der Schritt, der aus einer Meldung eine Stufe macht. Jemand liest die Nachweise, wendet vereinbarte Prüfungen an und landet bei P1, P2, P3 oder P4, und alles Nachgelagerte hängt an dieser Antwort. Es lohnt sich, Schweregrad und Priorität von Anfang an zu trennen, weil beide Begriffe synonym benutzt und dann mitten im Vorfall gegeneinander ausgespielt werden. Der Schweregrad beschreibt die Auswirkung und damit die Reaktion, die Sie schulden: Wer wird alarmiert, wird eine Bridge eröffnet, wie oft werden Stakeholder informiert. Die Priorität beschreibt die Reihenfolge: Was nimmt sich das Team als Nächstes vor. Der Schweregrad wird aus Nachweisen abgeleitet und bewegt sich nur, wenn sich die Nachweise bewegen; die Priorität lässt sich jeden Morgen neu setzen, ohne dass jemand die Auswirkungsbewertung wieder aufmacht.

Diese Seite ist ein Entscheidungsbaum und keine Prozesslandkarte, und genau deshalb steht sie für sich. Sie beantwortet eine einzige Frage (welche Stufe bekommt dieser Vorfall, und wer darf das entscheiden), indem sie sieben Prüfungen verkettet, bis jeder Pfad an einem benannten Ergebnis ankommt. Sie endet bewusst in dem Moment, in dem die Stufe gesetzt ist. Wenn Sie den durchgängigen Ablauf danach brauchen (wie das Ticket über Service Desk, Incident Manager und Support-Stufen diagnostiziert, eskaliert, gelöst, mit dem Nutzer bestätigt und geschlossen wird), nehmen Sie die Vorlage für den Incident-Management-Prozess. Nutzen Sie dieses Diagramm, um die Stufe zu bestimmen; nutzen Sie jenes, um die Arbeit zu führen.

Die Swimlanes benennen hier Entscheidungsbefugnisse statt Abteilungen: genau der Teil, den die meisten Schweregradmatrizen offenlässt. Der Service Desk beantwortet, was sich aus der Meldung beobachten lässt: Ist der Service nicht verfügbar oder nur eingeschränkt, und wie viele Nutzer oder Standorte sind betroffen. Der Service Owner beantwortet, ob eine kritische Geschäftsfunktion oder ein Umsatzpfad tatsächlich blockiert ist. Der Incident Manager verantwortet die Workaround-Prüfung, das Ausrufen der Stufe selbst und die spätere Überprüfung. Recht und Compliance verantworten zwei Fragen und sonst nichts: Liegt eine Daten- oder Sicherheitsgefährdung vor, und läuft eine regulatorische oder vertragliche Frist. Vier Bahnen genügen, um die Wer-entscheidet-Frage zu klären, ohne ein Organigramm zu zeichnen.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Vier Bahnen nach Entscheidungsbefugnis statt nach Abteilungen (Service Desk, Service Owner, Incident Manager sowie Recht und Compliance) über fünf Bewertungsstufen: Aufnahme, Umfang der Auswirkung, Geschäftliche Auswirkung, Schweregrad-Entscheidung sowie Ergebnis und Überprüfung.
• Die Eingangsprüfung „Service nicht verfügbar oder eingeschränkt?“ mit drei Antworten: Nicht verfügbar und Eingeschränkt laufen weiter in den Baum, Keine Auswirkung endet sofort bei „Als Service-Anfrage geschlossen“: Eine Anfrage bekommt so nie einen Schweregrad.
• Der Umfang wird vor der geschäftlichen Auswirkung geprüft: „Wie viele Nutzer oder Standorte betroffen?“ teilt sich in Mehrere Standorte, was direkt zum Ausrufen von P1 führt, Ein Team, was an den Service Owner übergeben wird, und Einzelner Nutzer, der trotzdem noch auf Gefährdung geprüft wird.
• Zwei voneinander unabhängige Wege nach kritisch: „Kritische Funktion oder Umsatz blockiert?“ speist die Prüfung „Tragfähiger Workaround vorhanden?“, wo Kein Workaround P1 auslöst und Workaround P2 vergibt; und „Daten- oder Sicherheitsgefährdung?“, wo der Zweig Gefährdung P1 auslöst, unabhängig davon, wie wenige Nutzer betroffen sind.
• Das untere Ende der Matrix wird durch eine einzige Frage entschieden: „SLA- oder Meldefrist angelaufen?“ trennt „P3 mittel, Frist überwacht“ von „P4 niedrig, geplante Arbeit“, statt es dem Ermessen zu überlassen. Zusammen mit „P1 kritisch, Bridge aktiv“, „P2 hoch, Behebung läuft“ und dem Ausgang als Service-Anfrage ergibt das fünf klar getrennte Endpunkte, ergänzt um einen ausdrücklichen Weg zur Neueinstufung: „Auswirkung beim nächsten Update verändert?“ schickt den Zweig Auswirkung gewachsen zurück in das Ausrufen von P1.
• Schriftliche Kriterien an den entscheidenden Verzweigungen: was nicht verfügbar bedeutet, wo die Schwellen für Nutzer und Standorte liegen, was als tragfähiger Workaround zählt und warum eine Gefährdung unabhängig vom Umfang als kritisch behandelt wird.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben die Schweregraddefinitionen auf, über die Ihr Team heute streitet, damit zwei Personen, die nachts um drei denselben Vorfall triagieren, ohne Verhandlung bei derselben Stufe landen.
• Sie konfigurieren ein ITSM- oder Rufbereitschaftswerkzeug, in dem der Schweregrad ein Pflichtfeld ist, und brauchen die Prüfungen hinter jeder Stufe statt eines Auswahlfelds mit vier Optionen ohne Anleitung.
• Sie klären Entscheidungsbefugnisse vor einem Ausfall statt währenddessen: Wer darf ein P1 ausrufen, wer bestätigt eine Daten- oder Sicherheitsgefährdung, und wer darf neu einstufen.
• Sie werten einen zurückliegenden Vorfall aus und prüfen, ob die vergebene Stufe zu den damals verfügbaren Nachweisen passte, was eine andere Frage ist als die, ob die Reaktion gut war.
• Sie arbeiten Rufbereitschaftskräfte und neue Service-Desk-Mitarbeitende ein, die eine Seite brauchen, auf der die Fragen, die Schwellen und die Endpunkte jeder Antwort stehen.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Entscheidungsbefugnissen

   Ersetzen Sie Service Desk, Service Owner, Incident Manager sowie Recht und Compliance durch die Rollen, die jede dieser Entscheidungen bei Ihnen tatsächlich halten. Wenn außerhalb der Geschäftszeiten niemand die Frage nach der Daten- oder Sicherheitsgefährdung verantwortet, ist das eine Lücke im Bereitschaftsplan, die Sie schließen sollten, bevor Sie die Bahn umzeichnen.

2. Schreiben Sie Ihre Umfangsschwellen an das Diagramm

   Öffnen Sie „Wie viele Nutzer oder Standorte betroffen?“ und ersetzen Sie den Kommentar durch Ihre eigenen Definitionen von mehreren Standorten, einem Team und einem einzelnen Nutzer: eine Region, eine Kundenklasse, ein Prozentsatz der aktiven Nutzer, eine namentliche Kundenliste. Schwellen, die nicht aufgeschrieben sind, werden bei jedem Vorfall neu verhandelt.

3. Definieren Sie nicht verfügbar gegenüber eingeschränkt für Ihre Services

   Legen Sie Service für Service fest, was Nicht verfügbar bedeutet, einschließlich der Fälle teilweiser Verfügbarkeit: Nur-Lese-Betrieb, eine ausgefallene Region oder eine Warteschlange, die zwar noch annimmt, aber nichts mehr verarbeitet. Unschärfe an dieser Stelle verschiebt den gesamten Baum um eine Stufe.

4. Legen Sie die Workaround-Prüfung ehrlich an

   Entscheiden Sie, was einen Workaround tragfähig macht: dokumentiert, zulässig, innerhalb der vorhandenen Kapazität und für die betroffenen Nutzer heute nutzbar. Ein manueller Ersatzweg, der Schulung, zusätzliches Personal oder eine Ausnahme von einer Richtlinie braucht, ist kein Workaround: Ihn als solchen zu behandeln, ist der häufigste Weg, auf dem ein P1 als P2 erfasst wird.

5. Hängen Sie an jedes Ergebnis eine eigene Reaktionszusage

   „P1 kritisch, Bridge aktiv“, „P2 hoch, Behebung läuft“, „P3 mittel, Frist überwacht“ und „P4 niedrig, geplante Arbeit“ sollten je eigene Alarmierungsregeln, Update-Takte und Zielzeiten tragen. Führen zwei Stufen zu identischem Verhalten, führen Sie sie zusammen, statt eine Stufe zu behalten, die niemand unterscheiden kann.

6. Legen Sie fest, wer neu einstufen darf, und dokumentieren Sie den Grund

   Die Entscheidung „Auswirkung beim nächsten Update verändert?“ ist der einzige zugelassene Weg, eine Stufe zu ändern. Benennen Sie, wer ihn gehen darf, verlangen Sie, dass die Prüfungen erneut durchlaufen und nicht die Stufe neu verhandelt wird, und halten Sie die neuen Nachweise samt Uhrzeit fest, damit die Nachbereitung erkennt, wann sich das Bild geändert hat.

7. Lassen Sie das Diagramm freigeben und versionieren Sie es

   Schweregradkriterien nützen nur, wenn sie die abgestimmten sind. Geben Sie das Diagramm an das Service Management, die Service Owner und die Rechtsabteilung zur Freigabe und bewahren Sie die freigegebene Fassung auf, damit die Definitionen, die Sie üben, auch die sind, die Sie veröffentlichen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Schweregrad und Priorität eines Incidents?

Der Schweregrad ist eine Aussage über die Auswirkung: Wie viel des Service ist gestört, für wie viele Menschen, und was blockiert das. Die Priorität ist eine Aussage über die Reihenfolge: Was nimmt sich das Team als Nächstes vor. ITIL kennt „Severity“ gar nicht als formalen Begriff, sondern leitet die Priorität aus Auswirkung und Dringlichkeit ab. Viele Entwicklungs- und SRE-Teams verwenden den Schweregrad als Kurzform für die Auswirkungshälfte, und so nutzt ihn auch dieses Diagramm. Die praktische Regel lautet: Der Schweregrad steuert die Reaktion, die Sie schulden (Alarmierung, Bridge, Update-Takt) und ändert sich nur, wenn sich die Nachweise ändern; die Priorität steuert die Warteschlange und darf täglich neu gesetzt werden. Je ein eigenes Feld dafür zu führen verhindert, dass jemand die Auswirkungsbewertung neu verhandelt, um schneller bedient zu werden.

Worin unterscheidet sich das von einem Flussdiagramm zum Incident-Management-Prozess?

Beide beantworten unterschiedliche Fragen zum selben Gegenstand. Dieses Diagramm ist ein Entscheidungsbaum: Welchen Schweregrad bekommt dieser Vorfall, und wer darf das entscheiden. Es ist eine Kette von Prüfungen, die in benannten Ergebnissen endet, und es hört auf, sobald die Stufe gesetzt ist. Ein Flussdiagramm zum Incident-Management-Prozess ist eine bereichsübergreifende Prozesslandkarte: Was passiert als Nächstes und wer tut es: von der Erfassung über Diagnose, Eskalation und Behebung bis zum Abschluss. Die meisten Teams brauchen beides, und sie berühren sich an genau einem Punkt: dem Schritt, in dem eine Stufe vergeben wird.

Wie viele Schweregradstufen sollten wir haben?

Vier ist der verbreitete Standard und die Wahl dieses Diagramms; manche Organisationen setzen darüber noch ein P0 oder SEV0 für existenzbedrohende Ereignisse. Wichtiger als die Anzahl ist, ob jede Stufe eine eigene, schriftlich festgelegte Reaktion trägt. Führen P3 und P4 zur selben Alarmierungsregel, zu denselben Zielzeiten und zum selben Update-Takt, dann haben Sie drei Stufen und ein ungenutztes Etikett. Weniger Stufen, konsequent angewendet, schlagen mehr Stufen, lax angewendet, denn der Wert der Einstufung liegt darin, dass alle Nachgelagerten ohne Rückfrage handeln können.

Wer darf ein P1 ausrufen?

Benennen Sie die Rolle vorab und halten Sie die Liste kurz. In diesem Diagramm liegt das Ausrufen in der Bahn des Incident Managers, und drei getrennte Zweige münden dort ein: ein standortübergreifender Ausfall, eine blockierte kritische Funktion ohne tragfähigen Workaround und eine bestätigte Daten- oder Sicherheitsgefährdung. Diese Struktur ist Absicht: Ein P1 sollte aus mehreren Richtungen durch Nachweise erreichbar sein, aber von einer Rolle ausgerufen werden, die zugleich die Reaktion zusagen kann. Anfordern darf ein P1 jeder; bestätigen darf es eine benannte Rolle.

Macht eine Daten- oder Sicherheitsgefährdung einen Vorfall automatisch zu einem P1?

In diesem Diagramm ja, und der Gefährdungszweig umgeht die Prüfung der Nutzerzahl vollständig. Der Grund ist, dass eine Gefährdung eine Frist auslöst, die ab Kenntnis und nicht ab Behebung läuft: Ein kleiner Vorfall kann also eine große Pflicht tragen. Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Kenntniserlangung zu melden; die Benachrichtigung der betroffenen Personen nach Art. 34 ist eine eigene Prüfung und an ein voraussichtlich hohes Risiko geknüpft. Andere Regelungen wie NIS2 und vertragliche Zusagen setzen eigene Fristen, und Kundenmeldefristen sind oft kürzer als die gesetzlichen. Tragen Sie deshalb die für Sie geltenden Fristen an der Entscheidung ein. Viele Organisationen leiten Gefährdungen zusätzlich vollständig aus diesem Baum heraus in einen Incident-Response-Prozess.

Wann sollte ein einmal gesetzter Schweregrad geändert werden?

Wenn sich die Nachweise ändern, nicht wenn sich der Druck ändert. Dieses Diagramm gibt dafür genau einen Weg: die Entscheidung „Auswirkung beim nächsten Update verändert?“, deren Zweig Auswirkung gewachsen ein P2 zurück in das Ausrufen von P1 schickt. Durchlaufen Sie die Prüfungen erneut, statt die Diskussion wieder aufzumachen, und halten Sie fest, welche neuen Nachweise wann eingegangen sind. Für Herabstufungen gilt dasselbe, und sie sollten ausdrücklich behandelt werden, denn ein Vorfall, der auf P1 bleibt, nachdem die Auswirkung zurückgegangen ist, erzieht die Beteiligten leise dazu, die Stufe zu ignorieren.