Incident-Schweregrade (SEV-Level) sind eine gemeinsame Skala, meist SEV1 bis SEV4 oder P1 bis P4, die einen Incident nach seiner Auswirkung auf Nutzer und Geschäft einstuft. Jede Stufe definiert objektive Kriterien und die erwartete Reaktion, etwa wer wie schnell alarmiert wird, wie oft Stakeholder informiert werden und ob ein Postmortem nötig ist.
Was sind Incident-Schweregrade (SEV-Level)?
Incident-Schweregrade (SEV-Level) sind ein Klassifizierungsschema, das allen Beteiligten zeigt, wie ernst ein Incident ist und welche Reaktion er erfordert. Die meisten Organisationen nutzen drei bis fünf Stufen, benannt als SEV1 bis SEV4 oder SEV0 bis SEV3, wobei die niedrigste Zahl die schwerste Stufe ist. Manche ITIL-orientierte Organisationen verwenden stattdessen Prioritäten wie P1 bis P4, die häufig aus einer Kombination von Auswirkung und Dringlichkeit abgeleitet werden.
Ein Schweregrad ist eine Abkürzung für Entscheidungen. Ist ein Incident als SEV1 erklärt, muss niemand diskutieren, ob das Datenbankteam geweckt, eine Telefonkonferenz eröffnet oder die Statusseite aktualisiert wird. Die Antwort steht bereits fest. Deshalb sind klare Kriterien wichtiger als die genaue Anzahl der Stufen.
Beispiel einer Schweregrad-Matrix
Die folgende Matrix ist ein illustrativer Ausgangspunkt. Passen Sie Kriterien und Zeiten an Ihre Services und Verträge an.
| Stufe | Typische Kriterien | Erwartete Reaktion |
|---|---|---|
| SEV1 (kritisch) | Kernservice ausgefallen, Datenverlust oder Sicherheitsvorfall, viele oder alle Nutzer betroffen, SLA gefährdet | Sofortige Alarmierung, Incident Commander benannt, Statusseite aktualisiert, Stakeholder-Updates alle 30 Minuten, Postmortem verpflichtend |
| SEV2 (schwer) | Wichtige Funktion defekt oder stark eingeschränkt für einen erheblichen Teil der Nutzer, Workaround schwierig oder nicht vorhanden | Alarmierung der Rufbereitschaft, eigener Kanal, regelmäßige Updates, Postmortem verpflichtend |
| SEV3 (mittel) | Begrenzte Einschränkung, kleine Nutzergruppe oder interne Tools betroffen, Workaround vorhanden | Bearbeitung während der Geschäftszeiten, Ticket mit Verantwortlichem, Postmortem optional |
| SEV4 (gering) | Kosmetisches Problem oder minimale Auswirkung, keine Dringlichkeit | Eintrag im Backlog |
Gute Kriterien sind beobachtbar. Statt „viele Nutzer betroffen“ definieren Sie Schwellen, die das Monitoring messen kann, etwa „Checkout-SLI unter 95 Prozent für 10 Minuten“ oder „Burn Rate des Error Budgets über 14,4“. So können Alerts automatisch einen Schweregrad vorschlagen, und die Einstufung bleibt teamübergreifend konsistent.
Schweregrad vs. Priorität
Der Schweregrad beschreibt die Auswirkung: Wie schlimm ist es für Nutzer und Geschäft? Die Priorität beschreibt die Reihenfolge der Arbeit: Was beheben wir zuerst? Während eines aktiven Incidents stimmen beide meist überein, sie können aber auseinanderfallen. Ein kleiner Fehler im Export für die Gehaltsabrechnung kann einen geringen Schweregrad, am Tag vor dem Abrechnungslauf aber hohe Priorität haben. Wer beide Begriffe trennt, verhindert, dass Schweregrade nur aufgebläht werden, um Aufmerksamkeit zu bekommen.
So definieren Sie Schweregrade
- Gehen Sie von Auswirkungsdimensionen aus: Anzahl betroffener Nutzer, betroffene Funktionen, Datenintegrität, Sicherheit, finanzielle oder vertragliche Risiken.
- Formulieren Sie pro Stufe einzeilige Kriterien mit konkreten Beispielen aus Ihren eigenen Systemen.
- Verknüpfen Sie Reaktionsregeln: Wer wird über die Rufbereitschaft alarmiert, welche Bestätigungszeit gilt, wie oft wird kommuniziert, welche Rollen wie Incident Commander und Kommunikationsverantwortliche sind nötig?
- Ermöglichen Sie schnelles Hoch- und Herabstufen. Der Schweregrad spiegelt den aktuellen Kenntnisstand wider. Änderungen sollten einfach sein und protokolliert werden.
- Im Zweifel höher einstufen. Einen SEV2 auf SEV3 herabzustufen kostet wenig. Einen echten SEV1 als SEV3 zu behandeln kostet viel.
- Verknüpfen Sie jede Stufe mit Runbooks und Kommunikationsvorlagen, damit Einsatzkräfte ohne Suchen handeln können.
Schweregrad, Rollen und Kommunikation
Der Schweregrad bestimmt nicht nur, wer das Problem behebt, sondern auch, wer informiert werden muss. Bei SEV1- und SEV2-Incidents trennen viele Teams drei Rollen: Der Incident Commander koordiniert und trifft Entscheidungen, technische Einsatzkräfte analysieren und mildern das Problem, und eine kommunikationsverantwortliche Person hält Stakeholder und Kunden auf dem Laufenden. Bei niedrigeren Stufen übernimmt meist eine Person alle drei Rollen.
Kommunikationsregeln sollten ebenso konkret sein wie technische. Legen Sie pro Stufe fest, welche internen Kanäle benachrichtigt werden, ob der Kundensupport ein Briefing erhält, ab wann ein öffentlicher Eintrag auf der Statusseite nötig ist und wie oft Updates erscheinen, auch wenn es nichts Neues gibt. Regelmäßige, vorhersehbare Updates entlasten die Einsatzkräfte, weil Stakeholder nicht ständig nachfragen. Nach dem Incident wird der endgültige Schweregrad festgehalten und in Auswertungen zur Gruppierung genutzt, damit sich Trends bei MTTD und MTTR pro Stufe vergleichen lassen.
Häufige Fehler
- Vage Kriterien wie „wichtige Kunden betroffen“, die zu unterschiedlichen Einstufungen derselben Situation führen.
- Zu viele Stufen, die die Ausrufung verzögern, während über den Unterschied zwischen SEV3 und SEV4 diskutiert wird.
- Alarmierung für SEV3 und SEV4 außerhalb der Geschäftszeiten, was Alert Fatigue und Überlastung fördert.
- Schweregrade zur Leistungsbewertung von Teams zu nutzen. Das erzeugt Druck, Incidents herabzustufen.
- Das Postmortem für schwere Incidents auszulassen, sobald der Druck nachlässt.
- Die MTTR über alle Schweregrade hinweg als einen Wert auszuweisen und damit sehr unterschiedliche Incidents zu vermischen.
Wie Obseria hilft
Im Incident Management von Obseria können Alert-Regeln einen initialen Schweregrad anhand der SLO-Burn-Rate und der betroffenen Services setzen. Einsatzkräfte ändern ihn mit protokollierter Zeitleiste. Der Schweregrad steuert Routing, Eskalation und ob ein Update der Statusseite vorgeschlagen wird. Obseria Intelligence ergänzt die wahrscheinliche Ursache mit Belegen, und Incidents lassen sich mit ITSM-Werkzeugen wie ServiceNow synchronisieren.