Vorfallmanagement für High-Velocity-Teams
Grundlegendes zum Schweregrad von Vorfällen
Vorfälle zur schnelleren Lösung identifizieren und priorisieren
Beim Vorfallmanagement gibt es 3 grundsätzliche Wahrheiten.
Die erste ist, dass Vorfälle unvermeidbar sind – insbesondere in Unternehmen, die fortlaufend wachsen und Innovationen schaffen.
Die zweite ist, dass solide Verfahren für das Vorfallmanagement für ein gesundes Unternehmen unerlässlich sind (und unzureichende Verfahren schwere Folgen für das Unternehmen haben, sowohl mit Blick auf die Arbeitszeit und Zufriedenheit der Mitarbeiter als auch auf die Umsätze).
Die dritte ist, dass nicht alle Vorfälle gleich zu werten sind. Der Verlust von Daten aus einer Datenbank ist nicht das Gleiche wie der Verlust von Daten aus all deinen Datenbanken. Das Beheben eines Ausfalls, der 20 % deiner Benutzer betrifft, ist nicht vergleichbar mit dem Beheben eines Ausfalls, der 90 oder 100 % der Benutzer in Mitleidenschaft zieht. Das Beheben eines Systemausfalls während der Hauptgeschäftszeiten ist bedeutend aufreibender als das Beheben eines Ausfalls, wenn die meisten Kunden schlafen. Selbst zwei Vorfälle, die auf dem Papier identisch aussehen, haben auf den zweiten Blick ihre ganz eigenen Besonderheiten.
Vorfallmanagement für High-Velocity-Teams
Beschleunige mit Jira Service Management den Informationsfluss zwischen den Operations- und Entwicklerteams, damit diese schneller reagieren und Systeme nach Vorfällen wiederherstellen können.
Aus diesem Grund verfügen Unternehmen mit soliden Programmen für das Vorfallmanagement über klar definierte Schweregrade für Vorfälle und eindeutige Best Practices zum Priorisieren von Vorfällen bei deren Auftreten.
Was sind Schweregrade?
Mit den Schweregraden von Vorfällen wird bestimmt, wie gravierend sich ein Vorfall auf das Unternehmen auswirkt. In der Regel gilt: Je kleiner die Zahl des Schweregrads, umso schwerwiegender ist der Vorfall.
Beispiel: Bei Atlassian definieren wir einen Vorfall mit Schweregrad 1 (SEV 1) als "kritischen Vorfall mit sehr gravierenden Auswirkungen". Vorfälle dieser Art umfassen beispielsweise den Verlust von Kundendaten, eine Sicherheitsverletzung oder den Ausfall eines kundenorientierten Service für alle Kunden.
Ein Vorfall mit Schweregrad 2 ist ein "bedeutender Vorfall mit gravierenden Auswirkungen" und beschreibt beispielsweise Situationen, in denen ein kundenorientierter Service für einen Teil der Kunden ausgefallen ist oder eine wichtige Funktion in einem System nicht funktioniert.
Ein Vorfall mit Schweregrad 3 ist ein "unwesentlicher Vorfall mit geringfügigen Auswirkungen", beispielsweise eine Systemstörung, die leichte Unannehmlichkeiten für Kunden verursacht.
Bei Atlassian können Vorfälle mit Schweregrad 3 tagsüber/während den regulären Arbeitszeiten behoben werden. Bei Vorfällen mit Schweregrad 1 und 2 wird eine Warnmeldung für Mitarbeiter im Bereitschaftsdienst generiert, damit sie unabhängig von der Uhrzeit unmittelbar behoben werden.
| Schweregrad | Beschreibung | Beispiele |
|---|---|---|
| 1 | Ein kritischer Vorfall mit sehr großen Auswirkungen |
|
| 2 | Ein größerer Vorfall mit bedeutenden Auswirkungen |
|
| 3 | Ein kleinerer Vorfall mit geringen Auswirkungen |
|
Schweregrade sind nützlich, um sich schnell die Auswirkungen bewusst zu machen und Prioritäten für die IT- und DevOps-Teams festzulegen.
Je sorgfältiger deine Schweregrade definiert sind, umso wahrscheinlicher ist es, dass dein Team sich einig ist und schnell angemessen auf Vorfälle reagieren kann. Ohne sorgfältig definierte Schweregrade wird womöglich wichtige Zeit für das Definieren und Erläutern der Dringlichkeit eines Vorfalls verschwendet, statt den Vorfall zu beheben.
Wann und wo sind Schweregrade nützlich?
Der größte Nutzen von Schweregraden ist, dass Teams durch sie Zeit sparen. Ein Team mit Schweregraden und einer klaren Roadmap für die einzelnen Schweregrade kann sich direkt mit der Korrektur befassen. Ein Team ohne Schweregrade wird wahrscheinlich die ersten Minuten nach einem bedeutenden Vorfall damit verbringen, zu ermitteln, wie gravierend der Vorfall ist, wer sich darum kümmern sollte und was zu tun ist.
Je ernster der Vorfall, umso wichtiger ist es, möglichst viel Zeit zu sparen. Das ist durch eine gute Planung im Voraus möglich – und zwar nicht nur mit Blick auf die Behebung des Vorfalls und Kommunikationspläne, sondern auch mit klaren Schweregraden und Prioritäten.
Was ist der Unterschied zwischen Schweregrad und Priorität?
Zunächst scheint der Schweregrad eines Vorfalls das Gleiche zu sein wie die Priorität eines Vorfalls. Schließlich sollte ein ernster Vorfall mit schlimmen Folgen vor einem weniger schwerwiegenden Vorfall behandelt werden, oder?
In Unternehmen ist dies aber meist etwas komplizierter.
Der Schweregrad ist ein Maß für die Auswirkungen. Wie groß sind die Auswirkungen eines Vorfalls auf die Benutzer? Wird ihr gesamtes System lahmgelegt? Können sie wichtige Aufgaben nicht mehr erledigen? Oder ist die Situation einfach nur irritierend und erschwert die Aufgaben?
Die Priorität hingegen ist ein Maß für die Dringlichkeit. Wie schnell muss dieses Problem behoben werden? Welches Problem muss zuerst behoben werden?
Manchmal stimmen Schweregrad und Priorität perfekt überein. Ein Vorfall mit hohem Schweregrad, der das gesamte Unternehmen lahmlegt, hat für DevOps- und IT-Teams wahrscheinlich auch die höchste Priorität.
Doch manchmal stimmen Priorität und Schweregrad nicht überein. Nehmen wir beispielsweise an, auf der Homepage deiner Website gibt es einen Tippfehler in der Überschrift. Das ist kein Problem mit hohem Schweregrad, da es die Funktion der Website nicht beeinträchtigt. Die Benutzer können nach wie vor alles Beliebige tun. Auch die Mitarbeiter werden dadurch bei ihren Aufgaben nicht beeinträchtigt.
Doch für das Unternehmen kann die Korrektur von hoher Priorität sein, sei es aufgrund der Markenstandards, weil der Fehler Verwirrung stiftet oder einfach weil ein Tippfehler in der Überschrift einen schlechten Eindruck hinterlässt. Dieser Vorfall könnte also einen geringen Schweregrad, aber eine hohe Priorität haben.
Hier eine andere Situation: Angenommen, es gibt einen Vorfall, der deine App zum Abstürzen bringt. Der Vorfall hat einen hohen Schweregrad, weil die Benutzer nicht mehr das tun können, was sie tun möchten. Allerdings betrifft der Vorfall nur 0,05 % der Benutzer. Wenn es andere Vorfälle gibt, die sich auf mehr Personen auswirken, hat ein Problem wie dieses vielleicht nicht oberste Priorität, obwohl die Worte "System stürzt ab" normalerweise alle auf den Plan rufen würden.
Beim Vorfallmanagement sind sowohl der Schweregrad als auch die Priorität von Bedeutung, doch es ist wichtig, zu erkennen, wann sie übereinstimmen und wann nicht. Ein hoher Schweregrad bringt eine Angelegenheit nicht automatisch ganz oben auf die Liste der Prioritäten und eine hohe Priorität bedeutet nicht immer, dass ein System ausgefallen ist.
Da das Handeln basierend auf der Priorität leichter ist als basierend auf dem Schweregrad, nutzen wir die Priorität als primäres Maß. Und da der Schweregrad oft ein Schlüsselfaktor der Priorität ist, haben wir in unserem Handbuch für Vorfälle klare Definitionen für unsere eigenen Verfahren im Vorfallmanagement festgelegt.
Definition von Schweregraden für Vorfälle in deinem Unternehmen
Nicht alle Vorfälle sind gleich und nicht alle Unternehmen gehen auf die gleiche Weise damit um. Beim Festlegen von Schweregraden und der damit verbundenen Prozesse und Erwartungen sind neben den Auswirkungen eines Vorfalls noch andere Aspekte zu berücksichtigen:
- Die Größe des Technikteams
- Bereitschaftspläne
- Zeiten mit besonders hohem oder wenig Traffic für deinen Service
- Die Häufigkeit von Vorfällen
Warum? Weil sich all dies darauf auswirken kann, wie du Schweregrade definierst.
Eine für lokale Märkte in einer einzigen Zeitzone vorgesehene App wird beispielsweise zwischen 2 Uhr und 7 Uhr morgens vermutlich deutlich weniger genutzt. Angenommen, dein gesamtes System fällt um 3 Uhr morgens aus: Hat dies dann den gleichen Schweregrad wie ein Systemausfall während der Hauptnutzungszeiten?
Oder wie sieht es bei einem Start-up mit einem kleinen Team und vielen Vorfällen aus, die bei uns unter Schweregrad 3 fallen würden? Sollte die Einstufung als Schweregrad 3 beibehalten werden und das Team bestimmt, welcher Vorfall Priorität hat, wenn drei Vorfälle gleichzeitig auftreten? Oder wäre eine weitere Aufteilung in Schweregrad 3, 4 oder sogar 5 angebracht, um zwischen einem teilweisen Funktionsverlust in einem von Kunden genutzten System, Leistungsproblemen und einem noch geringfügigeren Problem wie einem Fehler ohne Auswirkungen auf die Nutzbarkeit des Systems, der aber irgendwann behoben werden muss, zu unterscheiden?
Entscheidend ist hier, dass du dir ein klares Bild von deinem Unternehmen, deinem Team und den hierfür geeigneten Schweregraden und Prioritäten machst.
| 3 Stufen von Atlassian | 4 Stufen | 5 Stufen | |
|---|---|---|---|
| Schweregrad 1 | Ein kritischer Vorfall mit sehr großen Auswirkungen. | ||
| Schweregrad 2 | Ein größerer Vorfall mit bedeutenden Auswirkungen. | ||
| Schweregrad 3 | Ein kleinerer Vorfall mit geringen Auswirkungen. Beispiel: Ein Systemfehler bereitet Kunden geringfügige Unannehmlichkeiten. | Ein Vorfall, der sich möglicherweise zu einem größeren Problem entwickeln kann, wenn er nicht schnell bearbeitet wird. | |
| Schweregrad 4 | Eine Supportanfrage, die einen Kunden irritiert, aber keine Auswirkungen auf die Systemfunktion insgesamt hat. | Ein kleinerer Vorfall, der sich auf die Benutzerfreundlichkeit des Produkts auswirkt, es aber nicht unbrauchbar macht. | |
| Schweregrad 5 | Fehler oder Supportprobleme, die sich nicht auf die Benutzerfreundlichkeit von Produkten auswirken. | ||
Eine Lösung für das Vorfallmanagement zur Eskalation von Vorfällen ist ausschlaggebend dafür, dass die richtigen Teams sofort an einer Lösung arbeiten können.
Erfahre, wie die Vorfallmanagementfunktionen von Jira Service Management, einschließlich Warnmeldungen und Bereitschaftsplanung, kollaborative Kommunikation und robuste Berichts- und Analysefunktionen, Teams in die Lage versetzen, auf Vorfälle zu reagieren, sie zu lösen und daraus zu lernen.
Informationen zur Kommunikation bei Vorfällen mit Statuspage
In diesem Tutorial zeigen wir dir, wie du mithilfe von Vorfallvorlagen bei Ausfällen effektiv kommunizierst. Sie sind an viele Arten von Serviceunterbrechungen anpassbar.
Dieses Tutorial ansehenVorlagen und Beispiele für die Vorfallkommunikation
Wenn du Vorfälle bearbeitest, können sich Vorlagen für die Kommunikation als äußerst nützlich erweisen. Lade die Vorlagen herunter, die unsere Teams verwenden, und lerne weitere Beispiele für typische Vorfälle kennen.
Diesen Artikel lesen