false
11. Juni 2024
 | 
9 Minuten Lesedauer

Incident Severity Levels: Schweregrade von Vorfällen richtig einordnen

Die Frage ist nicht, ob ein Vorfall eintreten wird, sondern wann. Systeme werden abstürzen. Software wird versagen. Dienstleister werden selbst Ausfälle erleiden. Die Vorbereitung auf solche Probleme gehört zu euren Aufgaben – Schweregrade zählen dabei zu den notwendigen Werkzeugen.

Vorfälle wirken sich unterschiedlich stark auf Unternehmen und Kunden aus. Mit Schweregraden klassifiziert ihr die Auswirkungen und steuert eure Reaktion. Bei korrekter Nutzung von Schweregraden …

  • reagieren Teams schneller.
  • verkürzt sich die durchschnittliche Reparaturzeit (MTTR) in eurer Firma.
  • verstehen Stakeholder besser, wie sich Probleme auf Kunden auswirken.

Dieser Artikel erläutert die Schweregrade von Vorfällen, deren Anwendung und den Unterschied zu Prioritätsstufen.


Splunk ITSI ist ein Branchenführer im Bereich AIOps

Splunk IT Service Intelligence (ITSI) ist eine AIOps-, Analyse- und IT-Management-Lösung, die Teams dabei unterstützt, Vorfälle vorherzusagen, bevor sie sich auf Kunden auswirken.

Unter Einsatz von KI und maschinellem Lernen korreliert ITSI Daten aus Überwachungsquellen und liefert eine einheitliche Echtzeitansicht relevanter IT- und Geschäftsdienste, reduziert die Alarmmenge und verhindert proaktiv Ausfälle.

Erfahre mehr über Splunk ITSI ›

Was sind Schweregrade?

Schweregrade zählen zu den zentralen Bestandteilen des Vorfallmanagements und messen die akuten Auswirkungen eines Ereignisses auf das Unternehmen. Ob interne Probleme wie Geräte- oder Software-Ausfälle oder externe wie Sicherheitsverletzungen oder Lieferantenausfälle: Jeder Zwischenfall beeinträchtigt die Fähigkeit, Kunden zu bedienen. Der Schweregrad spiegelt diese Auswirkung wider.

(Mit diesen SIEM-Funktionen lassen sich Sicherheitsvorfälle besser handhaben.)

Je nach Organisation bestehen die Schweregrade normalerweise aus drei, vier oder fünf Abstufungen. Dabei markiert eins bzw. SEV 1 den höchsten und die höchste Zahl (3, 4 oder 5) den niedrigsten Schweregrad.

Eine allgemeingültige Definition für Schweregrade gibt es nicht. Die Definition richtet sich nach den Prioritäten der Organisation und ihrer Nutzer. Manchen Firmen reichen drei Stufen völlig aus. Für andere eignen sich hingegen fünf Abstufungen besser. Es folgen die Definitionen für fünf Stufen:

Beschreibung der Schweregrade

SEV 1

Ein kritischer Vorfall, der viele Nutzer in der Produktion betrifft.

SEV 2

Ein erhebliches Problem, das eine begrenzte Nutzeranzahl im Produktivbetrieb betrifft.

SEV 3

Ein Vorfall, der Fehler, kleinere Nutzerprobleme oder eine hohe Systemlast verursacht.

SEV 4

Ein kleineres Problem, das den Dienst beeinträchtigt, aber keinen ernsthaften Einfluss auf die User hat.

SEV 5

Ein geringfügiger Mangel, der kleine Probleme verursacht.

Warum Schweregrade für Vorfälle nutzen?

Beim Auftreten eines Zwischenfalls müssen Teams wissen:

  • Wer ist für die Problemlösung verantwortlich?
  • Wie kommunizieren die Teammitglieder miteinander?
  • Wie ernst ist das Problem?
  • Welche Schritte darf das Team zur Behebung unternehmen?
  • Wie erfolgen Berichterstattung und Nachverfolgung?

Bei einem Ausfall, der alle User betrifft, lautet eine typische Reaktion: „Alle Mann an Deck!“ Doch wenn sich alle auf ein einzelnes Problem konzentrieren, ist das unproduktiv. Dies ist meistens kontraproduktiv und führt zu doppelter Arbeit, Verwirrung und sogar zu widersprüchlichen Maßnahmen. Die Definition eines Schweregrads mit den zugehörigen Prozessen ermöglicht eine bessere Reaktion. (Noch besser: Benennt einen „Einsatzleiter“, damit von Anfang an klar ist, wer die Entscheidungen trifft.)

Die Definition von Schweregraden gehört auf jeden Fall in euren Incident-Management-Plan. Diese Fragen lassen sich meist im Vorfeld klären und sparen dem Team Zeit, da bei der Einstufung eines Vorfalls sofort jeder weiß, was zu tun ist.

(Die Best Practices bei der Untersuchung von Vorfällen findet ihr hier.)

Beispiele für Schweregrade von Vorfällen

Mithilfe unserer obigen Fragen sehen wir uns nun die möglichen Antworten für einen SEV-1-Vorfall an:

  • Wer ist für die Problemlösung verantwortlich? Die Abteilungsleitung oder ein bestimmtes Mitglied des Managements trägt die Verantwortung.
  • Wie kommunizieren die Teammitglieder miteinander? Es wird eine offene Telefonkonferenz eingerichtet.
  • Wie schwerwiegend ist das Problem? SEV 1 bedeutet, dass die Mehrheit der Kunden betroffen ist.
  • Welche Maßnahmen darf das Team zur Problemlösung unternehmen?Bei einem SEV-1-Vorfall sind alle Maßnahmen zulässig, einschließlich des Neustarts von Produktionsprozessen.
  • Wie wird der Vorfall dokumentiert und nachverfolgt? Die Verantwortlichen berichten dem Management stündlich.

Bei einem SEV-5-Vorfall fallen die Antworten ganz anders aus:

  • Ein Techniker oder Entwickler ist für die Problembehebung zuständig.
  • Die Kommunikation erfolgt über das Incident-Tracking-System.
  • SEV 5 bezeichnet eine geringfügige Schwierigkeit ohne Dringlichkeit.
  • Maßnahmen zur Behebung eines SEV-5-Problems in der Produktion sind nur während eines Wartungsfensters zulässig.
  • Der Techniker verfolgt das Problem im Vorfall- oder Software-Tracking-System.

Schweregrade sind eine gemeinsame Referenz für alle, die an der Reaktion auf Vorfälle beteiligt sind. Mit einer zugewiesenen Stufe und klar definierten Verfahren können die zuständigen Teams mit der Problemlösung beginnen. Ohne diese Vorgaben geht Zeit für die Klärung der Vorgehensweise verloren – oder es entstehen neue Probleme.


(Erfahrt, wie Splunk-Lösungen die gesamte Incident-Management-Praxis unterstützen.)

Schweregrad vs. Priorität eines Vorfalls: Handelt es sich um dasselbe?

Auf den ersten Blick scheinen Schweregrad und Priorität identisch zu sein. Bei einem SEV-1-Vorfall liegt es nahe, dass dieser vor einem SEV-2-Problem behoben wird. Worin liegt also der Unterschied zwischen Schweregrad und Priorität?

  • Der Schweregrad misst die Auswirkungen. Die obige Tabelle beschreibt die Stufen anhand ihrer Auswirkungen auf die User Community oder die Dienste.
  • Die Priorität gibt die Dringlichkeit vor. Sie verrät euch, wie schnell ihr ein Problem beheben müsst und welches Problem ihr zuerst lösen solltet.

Priorität und Schweregrad stimmen oft perfekt überein. Ein Ausfall, der alle User an der Nutzung eines Dienstes hindert, hat sowohl hohe Priorität als auch SEV 1. Dieses Beispiel zeigt die Übereinstimmung technischer Probleme mit geschäftlichen Prioritäten.Manchmal stimmen diese Prioritäten jedoch nicht überein:

  • Die Einführung einer neuen Funktion könnte hohe Priorität genießen, aber der Dienst funktioniert einwandfrei. Es liegt kein Vorfall vor, sodass kein Schweregrad gilt.
  • Ein peinlicher Tippfehler in einer mobilen Anwendung erfordert möglicherweise eine sofortige Korrektur. Das Technikteam stuft dies als SEV-5-Vorfall ein, dennoch genießt das Ganze eine hohe Priorität.

Auch wenn diese unterschiedlichen Einstufungen im Widerspruch stehen können, sind beide wichtige Kommunikationsmittel. Der Schweregrad zeigt den Beteiligten, wie ernsthaft ein Problem ist. Die Priorität weist dem Technikteam die nächste Aufgabe zu.

(Verfolgt weitere Incident-Respone-Metriken.)

Definition der Schweregrade von Vorfällen: bewährte Praktiken

Die Schweregrade von Vorfällen sind ein einfaches Konzept. Einfach bedeutet jedoch leider nicht leicht umzusetzen. Ihr könnt sie nicht aus einem Blogbeitrag oder einem Whitepaper kopieren und sofort anwenden. Ihr müsst sie an eure Organisation anpassen und dabei mehrere Faktoren berücksichtigen, zum Beispiel:

  • Eure Anwender Community
  • Eure Software- und Hardware-Systeme
  • Eure geschäftlichen Anforderungen

Diese Best Practices helfen Organisationen dennoch bei der Definition und Einhaltung von Schweregradstufen für Vorfälle.

Einheitlichkeit als entscheidender Schlüssel

Best Practice: Führt unternehmensweit einheitliche Stufen und Beschreibungen ein.

Die Verwendung verschiedener Schweregradstufen für unterschiedliche Anwendungen oder Software-Stacks erscheint besonders in großen Organisationen sinnvoll. Dies erschwert jedoch einen der größten Vorteile der Schweregradstufen: die klare Kommunikation bei Zwischenfällen. Unterschiedliche Stufen oder Definitionen erschweren den Beteiligten das Verständnis eines Vorfalls. Dies kann sogar Ingenieure und Entwickler verwirren, die an verschiedenen Anwendungen arbeiten.

Haltet es einfach

Best Practice: Verwendet so wenige Schweregradstufen wie möglich. Nicht mehr und nicht weniger.

Zu viele Stufen führen schnell zu Verwirrung. Schweregradstufen existieren unter anderem, damit bei einem Vorfall sofort eine Einstufung erfolgen und die Arbeit beginnen kann. Zu viele Stufen verlangsamen diesen Prozess. Zu wenige Stufen führen zur Vermischung unterschiedlicher Vorfälle. Feine (oder auch deutlichere) Unterschiede zwischen Vorfällen verschwinden, wenn sie in die gleiche Schublade gezwängt werden.

Wie findet ihr die richtige Balance? Setzt euch zusammen und entwickelt mit allen Beteiligten einen Plan. Geht vergangene Vorfälle durch und prüft, ob und wie sie in den vorgeschlagenen Rahmen passen Analysiert die bisherige Ursachenforschung. Probiert es aus und schreckt nicht vor Anpassungen zurück.

Erstellt klare Richtlinien für die Zuweisung von Schweregradstufen

Best Practice: Vereinfacht die Zuweisung von Schweregradstufen

Ohne schnelle Zuweisung der korrekten Schweregradstufe entgehen eurer Firma die Vorteile des Systems. Die Regeln für die Zuweisung müssen nicht nur einfach, sondern selbsterklärend sein. Diskussionen über den Schweregrad eines Vorfalls kosten wertvolle Zeit.

Nach der erfolgten Einstufung beginnt die Arbeit.Erstellt also Regeln, die auf messbaren Auswirkungen basieren, etwa:

  • Prozentsatz betroffener Kunden
  • Feature-Kategorien
  • Systemauswirkungen

Verwendung von Schweregradstufen

Nach dieser Einführung versteht ihr die Schweregradstufen und deren Anwendung. Bei diesen Schweregraden handelt es sich um Kommunikationsmittel, mit denen ihr die Auswirkungen eines Problems mitteilen und schnell die richtigen Teams mit der Lösung des Problems beauftragen könnt. Schweregrad und Priorität von Vorfällen hängen zwar zusammen, unterscheiden sich aber grundlegend.

(Aktuelle Sicherheitsthemen findet ihr auf Cybersecurity- und InfoSec-Konferenzen.)

 

Ihr habt einen Fehler entdeckt oder eine Anregung? Bitte lasst es uns wissen und schreibt eine E-Mail an ssg-blogs@splunk.com.

 

Dieser Beitrag spiegelt nicht zwingend die Position, Strategie oder Meinung von Splunk wider.

 

Chrissy Kidd Picture

Chrissy Kidd is a technology writer, editor, and speaker based in Baltimore. The managing editor for Splunk Learn, Chrissy has covered a variety of tech topics, including ITSM & ITOps, software development, sustainable technology, and cybersecurity. Previous work includes BMC Software, Johns Hopkins Bloomberg School of Public Health, and several start-ups. She's particularly interested in how tech intersects with our daily lives. 

Ähnliche Artikel

Über Splunk

Weltweit führende Unternehmen verlassen sich auf Splunk, ein Cisco-Unternehmen, um mit unserer Plattform für einheitliche Sicherheit und Observability, die auf branchenführender KI basiert, kontinuierlich ihre digitale Resilienz zu stärken.

 

Unsere Kunden vertrauen auf die preisgekrönten Security- und Observability-Lösungen von Splunk, um ihre komplexen digitalen Umgebungen ungeachtet ihrer Größenordnung zuverlässig zu sichern und verbessern.

Erfahrt hier mehr über Splunk