Ein Produktionsserver ist ausgefallen. Die Datenbank antwortet nicht. Ein kritisches Feature verhält sich unerwartet. Wie ernst ist das? Wie schnell muss reagiert werden? Wer wird benachrichtigt? Ohne klare Antworten auf diese Fragen verlieren Teams in den ersten Minuten eines Vorfalls wertvolle Zeit – und Vertrauen.
Warum Severity Levels unverzichtbar sind
Severity Levels – manchmal auch als Priority Levels oder Incident Severity Classifications bezeichnet – sind ein gemeinsames Vokabular für die Schwere eines Vorfalls. Sie beschreiben, wie stark ein Problem den Betrieb, die Nutzer oder das Geschäft beeinträchtigt.
Ohne diese Klassifikation entsteht ein kostspieles Problem: Jeder Vorfall wird ad hoc bewertet. Das führt dazu, dass unkritische Vorfälle zu viel Aufmerksamkeit bekommen, während echte Katastrophen zu spät eskaliert werden. Severity Levels schaffen Klarheit – für alle Beteiligten, sofort.
Die typische Struktur: Von SEV-1 bis SEV-5
Die meisten IT-Teams arbeiten mit vier bis fünf Stufen. Die genaue Benennung variiert (P0–P4, SEV-0–SEV-4, S1–S5), aber das Prinzip ist überall ähnlich:
- SEV-1 (kritisch): Totalausfall eines produktiven Services oder einer Kernfunktion. Alle Nutzer oder Kunden sind betroffen. Umsatz oder Sicherheit stehen auf dem Spiel. Sofortige Reaktion erforderlich, alle verfügbaren Ressourcen werden mobilisiert.
- SEV-2 (hoch): Erhebliche Beeinträchtigung einer wichtigen Funktion. Ein relevanter Teil der Nutzer ist betroffen, ein Workaround ist nicht verfügbar oder nur begrenzt möglich. Reaktion innerhalb von Minuten.
- SEV-3 (mittel): Eine Funktion ist beeinträchtigt, aber ein Workaround existiert. Der Betrieb läuft eingeschränkt weiter. Reaktion innerhalb von Stunden.
- SEV-4 (niedrig): Kleines Problem ohne unmittelbare Auswirkung auf den Betrieb. Kann regulär priorisiert und abgearbeitet werden.
- SEV-5 (informativ): Kein Handlungsbedarf jetzt. Beobachtung, Dokumentation, ggf. langfristige Maßnahme.
Diese Einteilung ist nicht in Stein gemeißelt. Entscheidend ist, dass das Team dieselben Definitionen teilt – und dass im Ernstfall kein Interpretationsspielraum entsteht.
Wie man Severity Levels richtig definiert
Der häufigste Fehler bei der Definition von Severity Levels: Die Stufen werden zu technisch formuliert. „CPU > 90 % für 5 Minuten" ist kein Severity Level, sondern ein Metrik-Schwellenwert. Severity beschreibt die Auswirkung, nicht den technischen Zustand.
Bessere Leitfragen für die Definition:
- Wie viele Nutzer sind betroffen? Alle, ein Segment, wenige?
- Welche Funktionen sind eingeschränkt oder ausgefallen?
- Gibt es einen Workaround? Ist er zumutbar?
- Gibt es Auswirkungen auf Sicherheit, Compliance oder Umsatz?
- Wie schnell verschlimmert sich das Problem ohne Eingriff?
Gut definierte Severity Levels sind ergebnisorientiert: Sie beschreiben, was für Nutzer und Betrieb passiert – nicht welcher technische Parameter überschritten wurde.
Eskalationsketten: Wer wird wann informiert?
Severity Levels allein reichen nicht aus. Sie müssen mit klaren Eskalationspfaden verknüpft sein: Wer reagiert bei SEV-1? Wer wird bei SEV-2 nach 15 Minuten ohne Reaktion informiert? Wann wird die Geschäftsleitung einbezogen?
Eine typische Eskalationskette für SEV-1 sieht so aus:
- Automatisierter Alarm wird ausgelöst, On-Call-Person wird sofort per Push, SMS oder Telefon informiert.
- Keine Reaktion nach 5 Minuten: nächste Person in der Rotation wird benachrichtigt.
- Keine Reaktion nach weiteren 10 Minuten: Teamlead oder Eskalationskontakt wird einbezogen.
- Parallel: Statusseite wird auf „Incident detected" gesetzt, Kommunikation beginnt.
Diese Kette funktioniert nur, wenn Notification-Handler korrekt konfiguriert sind und die Kontaktdaten aktuell gepflegt werden. Wer Severity Levels definiert, ohne die Benachrichtigungsinfrastruktur dahinter aufzubauen, hat nur halbe Arbeit geleistet.
KI bei der automatischen Severity-Klassifikation
Ein wachsendes Einsatzfeld für KI im Incident Management ist die automatische Klassifikation eingehender Alarme. Statt einen Operator zu zwingen, in der ersten Stresssekunde eines Vorfalls die Severity manuell einzuschätzen, übernimmt ein Modell eine erste Bewertung.
Solche Modelle analysieren:
- Den Monitor-Typ und die betroffene Ressource
- Historische Muster ähnlicher Vorfälle
- Kombinationen gleichzeitiger Alarme
- Zeitpunkt (Hauptgeschäftszeit vs. Randzeiten)
Das Modell macht einen Vorschlag – SEV-2, weil ähnliche Ausfälle in der Vergangenheit 20 Prozent der Nutzer betroffen haben. Der Mensch bestätigt oder korrigiert. So wird die Klassifikation schneller, ohne die Kontrolle des Teams zu umgehen.
KI beschleunigt die Klassifikation, aber sie ersetzt nicht das Urteil des Teams. Besonders bei unbekannten Vorfällen ist menschliche Einschätzung weiterhin unverzichtbar.
Severity Levels im Post-Mortem: Was sie über Prozessqualität verraten
Severity Levels sind nicht nur ein Werkzeug für den Moment des Vorfalls – sie liefern auch im Nachgang wertvolle Informationen. Wer regelmäßig auswertet, wie sich Vorfälle auf die verschiedenen Severity-Stufen verteilen, erkennt Muster: Häufen sich SEV-2-Vorfälle in einem bestimmten Dienst? Werden Vorfälle regelmäßig zu hoch oder zu niedrig eingestuft?
Post-Mortems, die Severity systematisch erfassen, erlauben über die Zeit eine fundierte Aussage darüber, wo technische Schulden, fehlende Redundanz oder Prozessschwächen liegen. Ein Dienst, der wiederholt SEV-1-Vorfälle produziert, braucht keine bessere Eskalationskette – er braucht technische Arbeit an der Ursache.
Die Klassifikation wird so zur Messgrundlage für Systemzuverlässigkeit: nicht nur rückblickend, sondern auch als Signal für die Priorisierung künftiger Investitionen in Infrastruktur und Monitoring.
Severity Levels und Monitoring: Zusammen denken
Ein effektives Severity-System beginnt nicht beim Incident – es beginnt beim Monitoring. Wer seine Monitore sinnvoll kategorisiert und mit unterschiedlichen Notification-Handlern ausstattet, kann Severity Levels bereits im Monitoring abbilden: Kritische Dienste mit sofortigen Push-Benachrichtigungen, weniger kritische mit verzögertem Alarm oder E-Mail-Benachrichtigung.
Heartbeat-Monitoring für Hintergrundprozesse, SSL-Zertifikatsüberprüfung für Domains, Server-Metriken für Infrastruktur – jeder dieser Check-Typen kann mit einem Severity-Level verknüpft werden, das beschreibt, wie ernst ein Ausfall wäre. So ist die Grundlage für schnelles Incident Management bereits vor dem ersten Alarm gelegt.
Fazit
Severity Levels sind kein bürokratisches Mittel, sondern ein handlungsorientiertes Werkzeug. Sie verkürzen die Zeit von der Erkennung bis zur ersten koordinierten Reaktion. Sie sorgen dafür, dass die richtigen Personen zur richtigen Zeit informiert werden. Und sie schaffen ein gemeinsames Verständnis dafür, was ernst ist – und was warten kann.
Wer Severity Levels klar definiert, mit Eskalationspfaden verknüpft und durch konsequentes Monitoring unterlegt, legt die Grundlage für ein Incident-Management, das auch unter Druck funktioniert.
Quellen und weiterführende Informationen: PagerDuty, „Incident Response Best Practices"; Google SRE Book, „Incident Management at Google"; Atlassian, „Incident Severity Levels Guide", 2024.
