Reaktion auf einen Vorfall

Erkennen

Mitarbeiter deines Unternehmens können Vorfälle auf verschiedene Art bemerken. Möglicherweise werden sie im Rahmen der Überwachung benachrichtigt, erhalten einen Bericht von Kunden oder stellen den Vorfall selbst fest. Wie auch immer ein Vorfall auftritt – der erste Schritt des Teams ist stets die Erstellung eines Tickets zum Vorfall (in unserem Fall in Form eines Jira-Vorgangs).

Bekanntmachung eines neuen Vorfalls

Wenn ein Vorfalls-Issue erstellt, aber noch keinem Vorfallsmanager (Incident Manager, IM) zugewiesen wurde, hat der Vorfall den Status Neu. Dies ist der Anfangsstatus in unserem Jira-Workflow für Vorfälle.

Wir haben einen Service, der anhand von Jira-Webhooks eine Seitenwarnung auslöst, sobald ein neuer größerer Vorfall erstellt wird. Auf diese Weise wird je nach ausgewähltem Service der zuständige IM benachrichtigt. Wenn beispielsweise ein Vorfall bei Bitbucket vorliegt, wird ein Bitbucket-IM benachrichtigt. Zusätzlich pflegen wir einen globalen universellen Dienstplan der für größere Vorfälle zuständigen IMs. Diese werden bei uns als "Incident Manager on Call" (IMOC, zuständiger Vorfallsmanager) bezeichnet.

Die Seitenwarnung enthält den Issue-Schlüssel, den Schweregrad und eine Zusammenfassung des Vorfalls, damit der IM weiß, wo er mit dem Management des Vorfalls beginnen soll (Jira-Issue), worin das Problem besteht und wie schwerwiegend es ist.

Eröffnung der Kommunikation

Wenn der Vorfallmanager online geht, weist er sich zunächst den Vorfallvorgang selbst zu und ändert den Status in Behebung. Auch aus dem Jira-Vorgangsfeld für die zugewiesene Person geht hervor, wer der aktuelle Vorfallmanager ist. Bei einer Notfallreaktion ist es sehr wichtig, dass die Zuständigkeiten klar sind. Aus diesem Grund achten wir sehr darauf, dieses Feld richtig auszufüllen.

Als Nächstes richtet der IM die Kommunikationskanäle des für den Vorfall zuständigen Teams ein. Die gesamte Kommunikation des Teams sollte unter bekannten Anlaufstellen zugänglich und weitgehend zentralisiert sein. Normalerweise nutzen wir drei Methoden zur Kommunikation im Team, für die im Jira-Issue zum Vorfall jeweils ein Feld vorhanden ist:

• Chatraum in Slack oder einem anderen Messaging-Service. Hier kann das Team kommunizieren sowie Beobachtungen, Links und Screenshots teilen. Die Kommunikation wird mit Zeitstempeln versehen und gespeichert. Da der Name des Chatkanals dem Vorgangsschlüssel entspricht (z. B. "HOT-1234"), ist der Chatraum für neu zur Kommunikation hinzukommende Beteiligte leichter zu finden.
• Videochat in einer Konferenzlösung wie Skype oder BlueJeans. Wenn sich alle Beteiligten am selben Ort befinden, kannst du das Team auch zu einem persönlichen Treffen zusammenrufen. Diese persönliche Kommunikation beschleunigt und vereinfacht die Entscheidungsfindung im Team.
• Eine Confluence-Seite, auf der der Status des Vorfalls dokumentiert wird. Wenn mehrere Personen gleichzeitig dieselbe Seite bearbeiten, können sie in Echtzeit sehen, welche Informationen zusammengetragen werden. Dies ist eine gute Möglichkeit zum Verfolgen von Änderungen (beispielsweise in Form einer Tabelle, der zu entnehmen ist, wer wann was wie und warum geändert hat, wie die Änderung rückgängig gemacht werden kann etc.), mehreren Arbeitsabläufen oder einem längeren zeitlichen Ablauf. Ein solches Dokument zum Status des Vorfalls spielt bei komplexen oder langwierigen Vorfällen eine wichtige Rolle als zentrale Informationsquelle.

Wir haben die Erfahrung gemacht, dass eine Kombination aus Videochat und Chatraum bei Vorfällen am besten funktioniert, da diese beiden Kommunikationskanäle für unterschiedliche Aspekte optimiert sind. Videochats lassen durch die Gruppendiskussion schnell ein geistiges Bild des Vorfalls entstehen, während sich ein Textchat gut zur Aufzeichnung des Vorfalls mit Zeitstempeln, geteilten Links zu Dashboards, Screenshots und anderen URLs eignet.

Mit diesen Methoden können Teams auch wichtige Beobachtungen, Änderungen und Entscheidungen aus nicht aufgezeichneten Unterhaltungen festhalten. Der Vorfallmanager oder ein anderes Mitglied des für den Vorfall zuständigen Teams muss dazu lediglich die in Echtzeit ablaufenden Beobachtungen, Änderungen und Entscheidungen im dedizierten Chatraum notieren. Es macht nichts, wenn es aussieht, als würde derjenige Selbstgespräche führen. Diese Notizen sind bei der Post-Mortem-Analyse sehr wertvoll, wenn die Teams den zeitlichen Ablauf des Vorfalls und seine Ursachen nachvollziehen müssen.

Bei den meisten Chatsystemen gibt es ein Feature für ein Raumthema. Der IM aktualisiert dieses Raumthema mit Informationen zum Vorfall und mit hilfreichen Links. Beispiele:

• Zusammenfassung und Schweregrad des Vorfalls
• Rollen und zugewiesene Personen (zuallererst der IM)
• Links zum Vorfalls-Issue, zum Videochatraum und zum Dokument mit dem Status des Vorfalls

So kann jeder, der über den Issue-Schlüssel des Vorfalls verfügt, dem Chat beitreten und sich schnell auf den neuesten Stand bringen. (Zur Erinnerung: Wir benennen den Chatkanal nach dem Issue-Schlüssel des Vorfalls, z. B. "HOT-1234".)

Am Schluss legt der Vorfallmanager den Vorgangsschlüssel des von ihm verwalteten Vorfalls als seinen persönlichen Chatstatus fest. So wissen seine Kollegen, dass er gerade mit der Handhabung des Vorfalls beschäftigt ist.

Bewertung

Wenn die Kommunikationskanäle des für den Vorfall zuständigen Teams fertig eingerichtet sind, wird es Zeit für die Bewertung des Vorfalls. So kann das Team entscheiden, welche Informationen zum Vorfall geteilt werden sollen und wer für die Problembehebung zuständig ist.

Bei uns stellen Vorfallmanager ihren Teams folgende Fragen:

• Welche Auswirkungen hat der Vorfall auf die (internen oder externen) Kunden?
• Was sehen die Kunden?
• Wie viele Kunden sind betroffen (nur einige oder alle)?
• Wann hat der Vorfall begonnen?
• Wie viele Supporttickets wurden von Kunden erstellt?
• Sind weitere Faktoren zu beachten, z. B. Twitter, Sicherheit oder Datenverluste?

An diesem Punkt bietet es sich an, mit dem Nachzeichnen des zeitlichen Ablaufs des Vorfalls zu beginnen. Halte die Beobachtungen des Teams fest, damit neu hinzukommende Personen schnell alles nachlesen können. Dieser Schritt ist auch für die spätere Nachbereitung wichtig. Notiere auch, ob der Beginn des Vorfalls mit einer Änderung (z. B. mit einem Bamboo-Deployment) zusammenfiel. In diesem Fall kann das Problem möglicherweise durch ein Rollback der Änderung gelöst werden.

Anhand der Auswirkungen des Vorfalls und des von unseren Teams geschätzten Arbeitsaufwands für die Erledigung weisen wir Vorgänge mit einem der folgenden Schweregrade zu:

Versenden der ersten Kommentare

Wenn du zu dem Schluss gekommen bist, dass höchstwahrscheinlich tatsächlich ein Vorfall vorliegt, solltest du alle internen und externen Beteiligten so schnell wie möglich informieren. Ziel der anfänglichen internen Kommunikation ist es, die Reaktion auf den Vorfall zu zentralisieren und für eine klare Informationslage zu sorgen. Bei der externen Kommunikation geht es darum, die Kunden wissen zu lassen, dass du über das Problem informiert bist und dass bereits mit Hochdruck daran gearbeitet wird. Eine schnelle und genaue Kommunikation über Vorfälle stärkt das Vertrauen von Mitarbeitern und Kunden.

Wir nutzen Statuspage für die interne und externe Kommunikation über Vorfälle. Für interne Mitarbeiter und externe Kunden pflegen wir separate Statusseiten. Später gehen wir näher auf die Verwendung der beiden Seiten ein. Jetzt müssen die Kommunikationskanäle erst einmal so schnell wie möglich eingerichtet werden. Dafür nutzen wir diese Vorlagen:

Eskalation

Du hast das Management des Vorfalls übernommen, die Teamkommunikation eingerichtet, die Situation bewertet und deine Mitarbeiter und Kunden über den Vorfall informiert. Was kommt als Nächstes?

Vielleicht hast du mit deiner ersten Anfrage schon alle Personen erreicht, die zur Erledigung des Vorfalls benötigt werden. In den meisten Fällen musst du jedoch weitere Teams hinzuziehen und sie dazu direkt benachrichtigen. Dies bezeichnen wir als Eskalation.

Das wichtigste System für diesen Schritt ist ein Tool für Dienstpläne und Benachrichtigungen wie OpsGenie. Mit OpsGenie und ähnlichen Systemen kannst du Dienstpläne mit den jeweiligen Zuständigkeiten erstellen, sodass im Notfall in jedem Team ein zuständiger Mitarbeiter erreichbar ist. Diese Methode ist besser, als wenn immer nur bestimmte Mitarbeiter kontaktiert werden ("Ruf doch noch mal Bob an!") – schließlich können diese Kollegen nicht ständig zur Stelle sein (Urlaub, Jobwechsel, Überlastung durch zu viele Anrufe). Sie ist auch besser, als spontan den gerade am besten geeigneten Kollegen auszuwählen, weil die Zuständigkeiten klar definiert sind.

Wenn du eine Benachrichtigung zum Vorfall versendest, gib immer auch den Jira-Issue-Schlüssel des Vorfalls an. Mit diesem Schlüssel kann der Empfänger der Benachrichtigung den Chatraum zum Vorfall betreten.

Delegierung

Nachdem die Eskalation erfolgt ist und der kontaktierte Mitarbeiter sich dem Team angeschlossen hat, muss der IM dem Mitarbeiter eine Rolle delegieren. Wenn der Mitarbeiter weiß, was von seiner Rolle erwartet wird, kann er als Mitglied des für den Vorfall zuständigen Teams schnell und effektiv arbeiten.

Bei Atlassian nutzen wir folgende Rollen:

• Vorfallmanager, siehe Beschreibung auf der Übersichtsseite.
• Technischer Leiter – ein für die Reaktion zuständiger erfahrener technischer Mitarbeiter. Er ist dafür zuständig, Theorien über das Problem und seine Ursache zu entwickeln, über Änderungen zu entscheiden und das technische Team zu leiten. Er arbeitet eng mit dem IM zusammen.
• Kommunikationsmanager – ein Mitarbeiter, der sich mit der öffentlichen Kommunikation auskennt, beispielsweise ein Vertreter des Kundensupportteams oder der PR-Abteilung. Er ist dafür zuständig, interne und externe Mitteilungen über den Vorfall zu verfassen und zu versenden.

Wir notieren im Thema des Chatraums, wer gerade welche Rolle bekleidet, und aktualisieren diese Zuordnung bei Rollenwechseln während eines Vorfalls.

Der IM kann je nach Anforderungen des Vorfalls auch Rollen neu erstellen und delegieren. So können beispielsweise mehrere technische Leiter erforderlich sein, wenn es mehrere parallele Arbeitsabläufe gibt. Auch eine Aufteilung der Rolle des Kommunikationsmanagers in einen internen und einen externen Vertreter ist möglich.

Bei komplexen oder großen Vorfällen ist es ratsam, einen weiteren qualifizierten IM zur Entlastung und Absicherung des eigentlichen IM hinzuzuziehen. Dieser zweite IM kann bestimmte Aufgaben übernehmen, um den IM zu unterstützen. Beispielsweise kann er die Aufzeichnungen zum zeitlichen Ablauf des Vorfalls pflegen.

Versenden der Nachbereitungskommentare

Nachdem du die anfänglichen Mitteilungen versendet hast und das für den Vorfall zuständige Team seine Arbeit aufgenommen hat, musst du Mitarbeiter und Kunden weiterhin über den Vorfall auf dem Laufenden halten.

Aktualisierte Informationen sind für die Mitarbeiter wichtig, weil so jeder auf demselben Wissensstand ist, was den Vorfall betrifft. Bei neu auftretenden Problemen sind vor allem in den Anfangsphasen nur wenige Informationen verfügbar. Wenn du keine zuverlässige Anlaufstelle für Informationen über den Vorfall und die Reaktion darauf einrichtest, ziehen Betroffene schnell ihre eigenen Schlüsse.

Bei der internen Kommunikation halten wir uns an folgendes Muster:

• Wir kommunizieren über unsere interne Statusseite und per E-Mail (wie oben in Bezug auf die anfängliche Kommunikation beschrieben).
• Wir nutzen dieselbe Benennungskonvention für die Bezeichnung des Vorfalls und die Formatierung des E-Mail-Betreffs ( – – ).
• An den Anfang stellen wir eine Zusammenfassung des aktuellen Status und der Auswirkungen (ein bis zwei Sätze).
• Es folgt ein Abschnitt zum aktuellen Status mit zwei bis vier Stichpunkten.
• Darauf folgt ein Abschnitt zu den nächsten Schritten mit zwei bis vier Stichpunkten.
• Wir kündigen an, wann und wie die nächsten Mitteilungen veröffentlicht werden.

Anhand folgender Checkliste prüfen wir unsere Mitteilungen auf Vollständigkeit:

• Welche Auswirkungen hat der Vorfall auf die Kunden?
• Wie viele interne und externe Kunden sind betroffen?
• Welche grundlegende Ursache hat der Vorfall (sofern bekannt)?
• Wann wird die Wiederherstellung voraussichtlich abgeschlossen sein?
• Wann und wie werden die nächsten Mitteilungen veröffentlicht?

Wir ermutigen unsere IMs, es bei der internen Kommunikation ehrlich zuzugeben, wenn etwas noch nicht bekannt ist. Dies verringert Unsicherheiten. Wenn beispielsweise die grundlegende Ursache des Vorfalls unbekannt ist, sollen sie dies offen kommunizieren, statt das Thema einfach zu verschweigen.

Auch Mitteilungen an externe Kunden sind wichtig, weil sie das Vertrauen fördern. Betroffene Kunden können sich anderen Dingen widmen, wenn sie wissen, dass du sie auf dem Laufenden hältst.

Für die externe Kommunikation aktualisieren wir einfach die zuvor erstellte externe Statusseite zum Vorfall und ändern den Status bei Bedarf. Wir versuchen, Aktualisierungen möglichst kurz zu halten, weil sich externe Kunden nicht für die technischen Details des Vorfalls interessieren. Sie möchten nur wissen, ob das Problem behoben wurde bzw. wann mit der Behebung zu rechnen ist. In der Regel sind ein bis zwei Sätze völlig ausreichend.

Die Kommunikation bei Vorfällen ist eine Kunst. Je mehr du übst, umso besser wirst du darin. In unserem Training für IMs führen wir ein Rollenspiel zu einem hypothetischen Vorfall durch, entwerfen dazu passende Mitteilungen und lesen sie den anderen Kursteilnehmern vor. Auf diese Weise können angehende IMs diesen Ablauf üben, bevor sie ihn in der Praxis umsetzen müssen. Es kann auch nie schaden, Mitteilungen noch einmal von einer anderen Person lesen zu lassen (Zweitmeinung), bevor du sie versendest.

Überprüfen

Es gibt keinen universell gültigen Prozess zur Lösung aller Vorfälle. Wenn es so wäre, könnten wir ihn einfach automatisieren und hätten unsere Ruhe. Stattdessen iterieren wir den folgenden Prozess, um ihn schnell an verschiedene Szenarien der Incident Response anzupassen:

• Beobachte, was gerade geschieht. Teile deine Beobachtungen mit, und lasse sie dir bestätigen.
• Entwickle Theorien über die mögliche Ursache des Geschehens.
• Entwickle Experimente, um diese Theorien zu belegen oder zu widerlegen. Führe sie durch.
• Wiederhole die oben genannten Schritte.

Beispiel: Du beobachtest eine hohe Fehlerquote bei einem Service, die gleichzeitig mit einem von deinem regionalen Infrastrukturanbieter auf seiner Statusseite veröffentlichten Fehler auftritt. Du entwickelst die Theorie, dass dieser Fehler regional begrenzt ist, entscheidest dich für ein Failover auf eine andere Region und beobachtest die Ergebnisse.

Die größte Herausforderung für den IM besteht an diesem Punkt darin, die Disziplin des Teams aufrechtzuerhalten:

• Kommuniziert das Team effektiv?
• Welche Beobachtungen, Theorien und Arbeitsabläufe stehen derzeit im Raum?
• Werden Entscheidungen effektiv getroffen?
• Geht das Team bei Änderungen gezielt und umsichtig vor? Ist bekannt, welche Änderungen vorgenommen werden?
• Sind die Rollen klar verteilt? Kommen die Teammitglieder ihren Aufgaben nach? Müssen wir an weitere Teams eskalieren?

In jedem Fall gilt: Nur keine Panik! Sie blockiert dich nur. Bleibe ruhig und sei dem Rest des Teams damit ein gutes Beispiel.

Der IM muss auf Ermüdungserscheinungen des Teams achten. Treten diese auf, muss er eine Teamübergabe planen. Ein dediziertes Team läuft beim Behandeln komplexer Vorfälle Gefahr, auszubrennen. IMs sollten daher darauf achten, wie lange die Teammitglieder schon wach sind und seit wann sie an dem Vorfall arbeiten. Bei Bedarf müssen sie entscheiden, wer die jeweilige Rolle als Nächstes übernimmt.

Erledigen

Ein Vorfall gilt als erledigt, wenn die aktuellen oder drohenden geschäftlichen Auswirkungen beseitigt sind. An diesem Punkt endet die Notfallreaktion. Das Team kann nun mögliche Bereinigungsaufgaben durchführen und sich der Nachbereitung widmen.

Bereinigungsaufgaben können leicht als vom Jira-Issue des Vorfalls ausgehende Issue-Verlinkungen verfolgt werden.

Wir bei Atlassian verfolgen mit benutzerdefinierten Jira-Feldern, wann die Auswirkungen eines Vorfalls begonnen haben, wann sie erkannt wurden und wann sie beseitigt wurden. Anhand dieser Felder berechnen wir die Wiederherstellungszeit (Time to Recovery, TTR), d. h. den Zeitraum zwischen Anfang und Ende, und die Erkennungszeit (Time to Detect, TTD), d. h. den Zeitraum zwischen Anfang und Erkennung. Die Verteilung von TTD und TTR bei Vorfällen ist oft eine wichtige Geschäftsmetrik.

Wir versenden abschließende interne und externe Mitteilungen, wenn der Vorfall erledigt wurde. Die internen Informationen enthalten einen Überblick über die Auswirkungen und die Dauer des Vorfalls, Angaben zur Anzahl der erstellten Supporttickets und weitere wichtige Zahlen zum Vorfall. Außerdem wird darin klar festgehalten, dass der Vorfall erledigt ist und es keine weiteren Mitteilungen dazu geben wird. Die externen Informationen sind in der Regel kurz gehalten. Den Kunden wird mitgeteilt, dass der Service wiederhergestellt wurde und dass wir uns nun um die Nachbereitung kümmern.

Wenn du erfahren möchtest, wie Jira Service Management Teams bei jedem Schritt im Incident-Response-Prozess unterstützt – von der zentralen Benachrichtigung und Organisation der Vorfallkommunikation bis hin zur Koordinierung von Teams und Durchführung einer Post-Mortem-Analyse zur Ermittlung der Vorfallursache –, dann klicke auf die Schaltfläche unten.