Severity Levels
Kategorisiert Auswirkungen und Dringlichkeit von Vorfällen, um Prioritäten, Eskalationen und Reaktionszeiten im Betrieb zu steuern.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlklassifikation führt zu falscher Priorisierung
- Übernutzung hoher Severity-Stufen reduziert deren Wirkung
- Unklare Kriterien erzeugen Konflikte zwischen Teams
- Klare, messbare Kriterien statt vager Beschreibungen
- Automatische Ersteinstufung mit manueller Prüfung bei Zweifeln
- Regelmäßige Schulungen und Übungen für On-Call-Teams
I/O & Ressourcen
- Monitoring- und Alert-Daten
- SLA- und Vertragsinformationen
- Service-Topologie und Abhängigkeiten
- Zugeteilte Severity-Stufe
- Eskalations- und Kommunikationsplan
- Post-Incident-Report mit Learnings
Beschreibung
Severity Levels klassifizieren Auswirkungen und Dringlichkeit von Vorfällen, Störungen oder Fehlern nach definierten Kriterien. Sie schaffen klare Eskalationspfade, Priorisierungen und Reaktionszeiten über Teams und Systeme hinweg. Dadurch wird koordiniertes Incident-Management, effiziente Ressourcenzuweisung und nachvollziehbare Kommunikation im Betrieb erleichtert. Sie dienen als Entscheidungsgrundlage für SLAs und Prioritäten.
✔Vorteile
- Beschleunigte Entscheidungsfindung bei Vorfällen
- Konsistente Eskalationsprozesse und klarere Verantwortungen
- Bessere SLA-Einhaltung und Priorisierung von Ressourcen
✖Limitationen
- Schwerfälligkeit bei zu starren oder zu vielen Stufen
- Subjektive Einstufungen ohne klare Kriterien
- Pflegeaufwand bei veränderten Betriebsbedingungen
Trade-offs
Metriken
- MTTR (Mean Time to Repair)
Durchschnittszeit von Vorfallserkennung bis Wiederherstellung.
- Anzahl Vorfälle pro Severity-Stufe
Verteilung der Vorfälle über die definierten Severity-Levels.
- SLA-Erfüllungsquote
Prozentsatz der Vorfälle, die innerhalb der SLA-Zeiten gelöst wurden.
Beispiele & Implementierungen
SLA-gesteuerte Priorisierung bei Zahlungsanbietern
Ein Zahlungsdienst nutzt Severity-Levels, um Eskalation und SLA-Reporting zu standardisieren.
On-Call-Routing anhand von Severity
Severity-Stufen bestimmen, welcher On-Call-Rolle ein Vorfall zugewiesen wird.
Priorisierung im Release-Plan
Bugs werden nach Severity klassifiziert, um Fix-Prioritäten in Releases zu setzen.
Implementierungsschritte
Bestandsaufnahme: Services, SLAs und Monitoring-Deckung erfassen.
Definition: Klare Kriterien und Eskalationspfade für jede Stufe festlegen.
Integration: Alerts, On-Call-Routing und Ticketing anpassen.
Review: Regelmäßige Überprüfung und Anpassung anhand von Post-Incident-Analysen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unzureichende Observability erschwert korrekte Einstufung
- Veraltete SLA-Dokumentation
- Fehlende Integrationen zwischen Alerting und Ticketing
Bekannte Engpässe
Beispiele für Missbrauch
- Marketing-Bugs als hohe Severity einstufen, obwohl kein Produktionsimpact
- Severity zur Umgehung von Change-Prozessen verwenden
- Severity-Level nicht dokumentieren und inkonsistent anwenden
Typische Fallen
- Verwechseln von Auswirkung und Häufigkeit beim Rating
- Zu starke Automatisierung ohne Escalation-Checks
- Mangelnde Anpassung an veränderte Geschäftsprioritäten
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Technische Einschränkungen im Monitoring
- • Organisatorische Eskalationsgrenzen
- • Vertragliche SLA-Vorgaben