So führst du einen Prozess für das Management eines größeren Vorfalls aus

Verwalten und Beheben von Vorfällen mit großen Auswirkungen

Das Management eines größeren Vorfalls (wird hier bei Atlassian einfach als Vorfallmanagement bezeichnet) ist der Prozess, der von DevOps- und IT-Operations-Teams verwendet wird, um auf ein ungeplantes Ereignis oder eine Serviceunterbrechung zu reagieren und den Service wieder in den Betriebszustand zu versetzen.

Was ist ein größerer Vorfall?

Was macht einen größeren Vorfall aus? Ein größerer Vorfall ist ein Ausfall oder eine Serviceunterbrechung von katastrophalem Ausmaß.

Was eine Katastrophe ausmacht, ist je nach Unternehmen unterschiedlich. Wir bei Atlassian haben drei Schweregrade und die beiden höchsten (Schweregrad 1 und 2) werden beide als größere Vorfälle betrachtet.

Wenn ein kundenorientierter Service für alle Atlassian-Kunden ausfällt, ist das ein Vorfall des Schweregrads 1. Wenn derselbe Service für eine Teilmenge von Kunden nicht verfügbar ist, ist dies Schweregrad 2. Beide zählen zur Kategorie der größeren Vorfälle und erfordern eine sofortige Reaktion unserer Vorfallmanagementteams.

Jeder Vorgang, der keine wesentlichen Aufgaben beeinträchtigt, wird als Schweregrad 3 eingestuft und nicht als größerer Vorfall betrachtet.

Definiere deinen Prozess für das Management größerer Vorfälle

Der Lebenszyklus eines Vorfalls (manchmal auch als Vorfallmanagementprozess bezeichnet) ist der Weg, den wir einschlagen, um wiederholte Vorfälle zu identifizieren, zu beheben, nachzuvollziehen und zu vermeiden.

Vorfallmanagementprozesse variieren von Unternehmen zu Unternehmen, entscheidend ist aber die klare Definition und Kommunikation von Schweregraden, Prioritäten, Rollen und Prozessen, schon bevor sich ein größerer Vorfall ereignet.

Damit Prioritäten, Rollen und Prozesse allseits verstanden werden, sollte jedes Team, das seinen Prozess für das Management von größeren Vorfällen überarbeitet, zuerst die folgenden Fragen klären:

• Was stellt für unser Unternehmen/Produkt einen größeren Vorfall dar?
• Wie definieren wir den Schweregrad und die Prioritätsstufen von Vorfällen? Wenn sich mehrere größere Vorfälle gleichzeitig ereignen, wie werden wir dann wissen, welchen wir zuerst bearbeiten müssen?
• Wer ist für die Abwicklung größerer Vorfälle verantwortlich? Welche Rollen haben Teammitglieder? Wie werden diese Rollen definiert und kommuniziert?
• Welchen Prozess werden Teams bei einem größeren Vorfall befolgen? Gibt es je nach Art des Vorfalls mehr als einen Prozess?
• Wie oft werden wir mit Stakeholdern (intern und extern) kommunizieren? Wie sieht unser Kommunikationsplan aus?
• Wie wird unser Bereitschaftsplan für größere Vorfälle aussehen? Wer ist für einen Vorfall verantwortlich, der sich um 2 Uhr morgens ereignet? Oder an einem Wochenende? Oder über die Feiertage?
• Wann und wie sollten wir unseren Vorfallmanager alarmieren, dabei eine schnelle Lösung für größere Vorfälle priorisieren und gleichzeitig Alarm-Fatigue vermeiden?

Der Atlassian-Prozess für das Management von größeren Vorfällen

Unser eigener Vorfallmanagementprozess umfasst Folgendes: Erkennen und Bekanntmachen eines neuen Vorfalls, Öffnen der Kommunikationskanäle, Bewertung, Senden von ersten Mitteilungen, Eskalation, Delegieren, Senden von Follow-up-Mitteilungen, Review und Behebung.

Erkennung

Zunächst wird ein Vorfall entweder durch unsere Technologie, durch Kundenberichte oder Mitarbeiter festgestellt. Wer den Vorfall erkennt (etwa ein Techniker, der den Vorfall bemerkt, oder ein Kundenservicemitarbeiter, der einen Anruf von einem frustrierten Kunden erhält) ist verantwortlich für die Protokollierung des Vorfalls in unserem System und die Angabe eines Schweregrads.

Bis ein Vorfall unsere Teams erreicht wurde ihm bereits ein Schweregrad 1, 2 oder 3 zugewiesen. Wir betrachten die Schweregrade 1 und 2 als größere Vorfälle, während Schweregrad 3 für einen Vorfall mit geringeren Auswirkungen steht.

Bekanntmachen eines neuen Vorfalls

Sobald ein Vorfallticket erstellt wurde, wird eine Benachrichtigung an den für diesen Service verantwortlichen Bereitschaftsmitarbeiter gesendet.

Die Benachrichtigungen, die wir bei Atlassian versenden, enthalten Informationen über den Schweregrad und die Priorität des Vorfalls sowie eine Zusammenfassung. So ist auf einen Blick zu sehen, ob der Vorfall mit oberster Priorität zu handhaben ist oder warten kann, bis ein anderer Vorfall behoben ist.

Öffnen der Kommunikationskanäle

Sobald der Vorfallmanager alarmiert wird, muss dieser als Erstes kommunizieren, dass die Behebung des Vorfalls bereits läuft. Er ändert den Status des Vorfalls zu "Wird behoben" und richtet die Kommunikationskanäle des Teams ein.

Flexible Kommunikationskanäle für den gesamten Incident-Response-Prozess sind unerlässlich, damit Teams auf ihre bevorzugte Weise in Kontakt bleiben können. In Jira Service Management sind zahlreiche Kommunikationskanäle integriert, um Ausfälle zu minimieren. Dazu zählen ein einbettbares Status-Widget, eine dedizierte Statusseite, E-Mails, Chat-Tools, Social Media und SMS.

Bewertung

Der Vorfallmanager wurde alarmiert und die Kommunikationskanäle sind offen. Nächster Schritt: Bewertung des Vorfalls.

Für unsere Teams beginnt dieser Prozess mit einer Reihe von Fragen, die das Team beantworten muss:

• Wie wirkt sich der Vorfall auf die Kunden und Mitarbeiter von Atlassian aus?
• Was sehen die Kunden?
• Wie viele Kunden sind betroffen? (Einige? Alle?)
• Wann hat der Vorfall begonnen?
• Wie viele Supporttickets wurden zu diesem Vorfall erstellt?
• Gibt es andere Faktoren, die sich auf den Schweregrad oder die Priorität auswirken oder die Art und Weise ändern, wie wir den Vorfall angehen (z. B. Sicherheitsbedenken, PR-Krisen in sozialen Medien usw.)?

Sobald wir diese Fragen beantwortet haben, können wir getrost mit Diagnosen und vorgeschlagenen Fehlerbehebungsmaßnahmen weitermachen oder gegebenenfalls den Schweregrad und die Prioritätsstufe eines Vorfalls ändern.

Senden von ersten Mitteilungen

Sobald wir die Echtheit des Vorfalls bestätigt haben, hat die Kommunikation mit unseren Kunden und Mitarbeitern oberste Priorität. In unserem Handbuch ist hierzu Folgendes zu lesen:

"Das Ziel der ersten internen Kommunikation besteht darin, die Incident Response auf einen Ort zu konzentrieren und Irritation zu reduzieren. Das Ziel der externen Kommunikation besteht darin, Kunden mitzuteilen, dass du über den Vorfall Bescheid weißt und die Angelegenheit sofort untersuchen wirst."

Eine schnelle und präzise Kommunikation trägt dazu bei, das Vertrauen der Kunden aufzubauen und zu erhalten.

Wir haben einen strategischen Kommunikationsplan für Vorfälle und stellen regelmäßige Statusaktualisierungen zur Verfügung, die einem einfachen Schema folgen. Wir senden auch eine E-Mail an bestimmte Stakeholder, zu denen technische Führungskräfte, Major Incident Manager und andere wichtige interne Mitarbeiter gehören. Wie bereits erwähnt, sind alle diese Kommunikationsmethoden innerhalb von Jira Service Management anpassbar und können auf den Incident-Response-Plan der Organisation zugeschnitten werden.

Eskalation

Manchmal wird ein Vorfall vom Bereitschaftsteam schnell behoben. Wenn dies nicht möglich ist, wird der Vorfall als Nächstes an einen anderen Experten oder ein anderes Team eskaliert, das besser geeignet ist, diesen spezifischen Vorfall zu beheben.

In Jira Service Management können die Bearbeiter zusammenhängende Tickets gruppieren und Mitarbeiter zu einem Vorgang hinzufügen, um Warnmeldungen zu koordinieren. Die Bearbeiter können alle Maßnahmen in einer detaillierten Zeitleiste automatisch erfassen und Automatisierung sowie Wissensdatenbankartikel nutzen, um Vorfälle schnell zu untersuchen und zu beheben.

Delegierung

Sobald der Vorgang an eine andere Person eskaliert wurde, delegiert der Vorfallmanager eine Rolle an diese. Bei Atlassian sind diese Rollen vorab festgelegt, sodass Teammitglieder schnell wissen, was von ihnen erwartet wird.

Manchmal erfordern größere Vorfälle einen einzelnen Vorfallmanager und ein kleines Team. In anderen Fällen kann eine Situation mehrere technische Leiter oder sogar mehrere Vorfallmanager erfordern. Der ursprüngliche Vorfallmanager hat die Aufgabe, diese Situationen zu beurteilen und gegebenenfalls die entsprechenden Personen einzubeziehen.

Senden von Follow-up-Mitteilungen

Während der Vorfall weiter bearbeitet wird, soll eine weitere Kommunikationsrunde außerhalb des Technologieteams dazu beitragen, Kunden und Mitarbeiter zu beruhigen, ihr Vertrauen aufzubauen und sie auf dem Laufenden zu halten. Am einfachsten geht das, wenn die Mitarbeiter über mehrere Kommunikationskanäle über den Fortschritt der Incident Response auf dem Laufenden gehalten werden.

Überprüfen

Bei der Behebung von Vorfällen gibt es leider keine Universallösung. Deshalb machen wir in dieser Phase des Prozesses Folgendes:

• Ereignisse beobachten, Teams darüber informieren und Beobachtungen bestätigen
• Theorien entwickeln, warum der Vorfall passiert (und wie wir ihn beheben können)
• Experimente entwickeln und durchführen, die unsere Theorien beweisen oder widerlegen
• Schritte wiederholen

Während dieses Prozesses behält der Vorfallmanager das Geschehen genau im Auge. Sind bestimmte Teammitglieder überarbeitet? Braucht jemand eine Pause? Müssen neue Leute hinzugezogen werden? Bei Bedarf wird häufiger delegiert.

eine schnelle Lösungsfindung

Unser Handbuch für Vorfälle definiert die Behebung als "[Moment], wenn die aktuellen oder drohenden geschäftlichen Auswirkungen beseitigt sind".

Zu diesem Zeitpunkt ist der Notfall vorüber und das Team macht sich an Bereinigungsarbeiten und Post-Mortem-Analysen.

Postmortem-Analysen

Der Lebenszyklus eines Vorfalls endet, wenn der Vorfall behoben wurde. Das ist aber nicht das Ende unseres Prozesses bei Atlassian. Wir möchten alles in unserer Macht Stehende tun, um sicherzustellen, dass sich ein Vorfall nicht wiederholt. Darum ist der nächste Schritt eine Post-Mortem-Analyse ohne Schuldzuweisung, mit der die Ursache eines Vorfalls identifiziert und Risiken in Zukunft gemindert werden sollen.

Mithilfe von Post-Mortem-Vorlagen in Jira Service Management kannst du ohne großen Aufwand Post-Mortem-Berichte, einschließlich des zeitlichen Ablaufs des Vorfalls, erstellen und exportieren. Bearbeiter können mit den funktionsübergreifenden Teams Follow-up-Aktionen vereinbaren und verfolgen, um ähnliche Vorfälle in Zukunft zu vermeiden.

Rollen und Zuständigkeiten

Rollen und Zuständigkeiten hängen von der jeweiligen Unternehmenskultur, der Teamgröße, Bereitschaftsplänen und vielem mehr ab. Zu den typischen Rollen für die Bearbeitung größerer Vorfälle zählen:

Vorfallmanager: Diese Person ist dafür zuständig, die Behebung eines Vorfalls zu beaufsichtigen.

Technischer Leiter: Dieser erfahrene technische Mitarbeiter soll herausfinden, was defekt ist und warum. Er oder sie legt außerdem die beste Vorgehensweise fest und leitet das Technologieteam.

Kommunikationsmanager: Dieser Kommunikationsprofi (häufig von den PR- oder Kundensupportteams) ist für die Kommunikation mit internen und externen Kunden verantwortlich, die von dem Vorfall betroffen sind.

Leiterin des Kundensupports: Diese Person ist dafür verantwortlich, dass auf eingehende Tickets, Telefonanrufe und Tweets über den Vorfall zeitnah und angemessen reagiert wird.

Social-Media-Leiter: Dieser Social-Media-Profi ist für die Kommunikation über den Vorfall auf sozialen Kanälen verantwortlich.

Andere typische Rollen sind:

Ursachenanalyst oder Problemmanager: Diese Person ist nicht nur für die Behebung des Vorfalls verantwortlich, sondern auch für die Identifizierung der Hauptursache und aller Änderungen, die zur Vermeidung zukünftiger Vorfälle vorgenommen werden müssen.

Untersuchungsausschuss für größere Vorfälle: Diese Gruppe ist für Untersuchungen und das Änderungsmanagement verantwortlich.

Eine Vorfallmanagementlösung wie Jira Service Management unterstützt dich bei jedem Schritt im Incident-Response-Prozess– von der Organisation der Bereitschaftsplanung, über Warnmeldungen und der Koordinierung von Teams für eine bessere Zusammenarbeit bis hin zur Durchführung von Post-Mortem-Analysen von Vorfällen.