The 7 stages of effective incident response

Erkenne den Vorfall.

Im Idealfall erkennen Überwachungs- und Benachrichtigungstools Vorfälle und melden diese deinem Team, bevor Kunden überhaupt etwas davon bemerken. Manchmal erfährst du jedoch zuerst über Twitter oder eingehende Kundensupporttickets von einem Vorfall.

Doch egal, wie der Vorfall erkannt wird – du solltest als Erstes in einem Tool für Vorgangsverfolgung festhalten, dass es einen neuen Vorfall gibt. Dies könnte ein speziell entwickeltes Tool wie Opsgenie Enterprise sein oder ein allgemeines Nachverfolgungstool wie Jira.

Richte Kommunikationskanäle für das Team ein.

Wenn Vorfallmanager online gehen, richten sie zunächst einmal Kommunikationskanäle für das Incident-Response-Team ein. An dieser Stelle soll für das Incident-Response-Team ein Kommunikationskanal in folgenden bekannten Bereichen eingerichtet und zusammengeführt werden:

• Chaträume in Slack oder einem anderen Nachrichtendienst
• Videochats in Videokonferenzanwendungen wie Zoom (wenn ihr euch alle am selben Ort aufhaltet, kannst du das Team auch in einem physischen Raum um dich versammeln)

Wir verwenden bei Vorfällen Videochat- und Textnachrichtentools, da beide auf unterschiedliche Anforderungen zugeschnitten sind. Videochats sind eine großartige Methode, um sich während einer Gruppendiskussion schnell ein Bild von dem Vorfall zu machen. Und Slack hilft dabei, den Vorfall inklusive Zeitstempeln und gesammelten Links zu Screenshots, URLs und Dashboards aufzuzeichnen.

Slack und die meisten anderen Chattools ermöglichen es Benutzern, für Räume ein bestimmtes Thema festzulegen. Der Vorfallmanager sollte dieses Feld nutzen, um Informationen über den Vorfall und nützliche Links anzugeben.

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.

Bewerte die Auswirkungen und gib einen Schweregrad an.

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 die 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?

Im nächsten Schritt wird normalerweise ein Schweregrad zugewiesen.

Schweregrade für die Incident Response

Schweregrad 1
Beschreibung: Ein kritischer Vorfall mit sehr großen Auswirkungen
Beispiele:

• Ein von Kunden genutzter Service ist für alle Kunden ausgefallen.
• Die Vertraulichkeit oder Datensicherheit wurde verletzt.
• Kundendaten sind verloren gegangen.

Schweregrad 2
Ein größerer Vorfall mit bedeutenden Auswirkungen
Beispiele:

• Ein von Kunden genutzter Service ist für bestimmte Kunden nicht verfügbar.
• Kernfunktionen sind erheblich beeinträchtigt.

Schweregrad 3
Ein kleinerer Vorfall mit geringen Auswirkungen
Beispiele:

• Eine kleinere Unannehmlichkeit für Kunden; ein Workaround ist vorhanden.
• Die nutzbare Leistung hat abgenommen.

Die Nummerierung von Schweregraden hilft dabei, Vorfälle schnell zu definieren und zu kommunizieren. Der Hinweis, dass vermutlich ein Vorfall mit Schweregrad 1 vorliegt, reicht dann völlig aus, um alle über den Ernst der Situation zu informieren, bevor weitere Informationen dazu eingehen.

Schweregrade können auch dazu beitragen, Richtlinien für Behebungsmaßnahmen zu erstellen.

In einigen Unternehmen können Vorfälle mit Schweregrad 3 beispielsweise im Laufe des Arbeitstages bearbeitet werden. Für die Schweregrade 1 und 2 werden dann Teammitglieder hinzugezogen, um diese umgehend zu beheben.

Die Definitionen von Vorfallschweregraden sollten dokumentiert und unternehmensweit konsistent verwendet werden.

Kommunikation mit Kunden

Sobald ein Team feststellt, dass ein echter Vorfall vorliegt, sollten interne und externe Stakeholder möglichst früh darüber informiert werden.

Das Ziel der internen Kommunikation ist es, die Incident Response 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 dich bereits darum kümmerst. Eine schnelle und präzise Kommunikation hilft dabei, Vertrauen bei den Kunden und dem Rest des Unternehmens aufzubauen.

Viele Teams nutzen Statuspage für die interne und externe Kommunikation von Vorfällen. Hier sind zwei einfache Vorlagen, die du zur Aktualisierung einer internen oder externen Statusseite verwenden kannst:

Interne Statusseite
- -

Wir untersuchen derzeit einen Vorfall, der , und betrifft. In Kürze veröffentlichen wir aktuelle Informationen per E-Mail und Statuspage.

Externe Statusseite
Untersuchung von Problemen bei

Wir untersuchen derzeit Probleme bei und werden in Kürze aktuelle Informationen zur Verfügung stellen.

Eskaliere das Problem an die richtigen Vorfallbearbeiter.

Manchmal können diejenigen, die einen Vorfall als erste bearbeiten, den Vorfall selbst beheben. In den meisten Fällen müssen sie aber andere Teams hinzuziehen, indem sie sie über ein Benachrichtigungstool wie Opsgenie kontaktieren.

Mithilfe von Benachrichtigungstools können Teams Bereitschaftsdienstpläne und einen Turnus festlegen, zu dem bestimmte Mitarbeiter bei Auftreten eines Vorfalls erreichbar sein müssen. Das ist besser, als sich bei jedem Vorfall auf eine bestimmte Person verlassen zu müssen. Schließlich wird diese eine Person nicht immer verfügbar sein (weil sie Urlaub nimmt, den Job wechselt oder einen Burnout erleidet, weil sie zu oft kontaktiert wird).

Delegiere Rollen für die Incident Response.

Nachdem ein neuer Vorfallbearbeiter kontaktiert wurde und online gegangen ist, wird der Vorfallmanager eine Rolle an ihn delegieren. Dieser Bearbeiter muss wissen, was von der Rolle verlangt wird und wie er schnell und effektiv seinen Beitrag für das Incident-Response-Team leisten kann.

Ein weiterer Vorteil von definierten Rollen besteht darin, dass man eine höhere Anpassbarkeit und Flexibilität damit erreicht. So können alle Mitarbeiter, die mit einer bestimmten Rolle vertraut sind, diese für jeden beliebigen Vorfall übernehmen.

Die wichtigsten Rollen für die Incident Response

Vorfallmanager

Jeder Vorfall wird von einem Vorfallmanager verwaltet, der die erforderliche Zuständigkeit und Befehlsgewalt dafür aufweist.

Der Vorfallmanager hat die Befugnis, jede erdenkliche Maßnahme zu ergreifen, um einen Vorfall zu beheben. Er könnte beispielsweise einen Kollegen in seinem Unternehmen hinzuziehen und Mitarbeiter, die an der Behebung eines Vorfalls arbeiten, dazu veranlassen, einen Service möglichst schnell wiederherzustellen.

Technischer Leiter

Dabei handelt es sich um einen technisch versierten Vorfallbearbeiter. Der technische Leiter stellt Theorien auf, was beschädigt wurde und warum. Er entscheidet über Änderungen und leitet das technische Team. Diese Person arbeitet eng mit dem Vorfallmanager zusammen.

Kommunikationsmanager

Diese Person kennt sich mit der öffentlichen Kommunikation aus und gehört möglicherweise dem Kundensupportteam oder der PR-Abteilung an. Sie ist dafür zuständig, interne und externe Mitteilungen über den Vorfall zu verfassen und zu versenden.

Behebe den Vorfall.

Es gibt keinen universell gültigen Prozess für die Behebung sämtlicher Vorfälle. Wenn es so wäre, könnten wir ihn einfach automatisieren und der Fall hätte sich erledigt. Weil dem aber nicht so ist, solltest du dich von der wissenschaftlichen Methode inspirieren lassen. Wiederhole den folgenden Prozess, um dich schnell auf diverse Incident-Response-Szenarien einzustellen:

• Beobachte, was gerade geschieht. Teile deine Beobachtungen mit, und lasse sie dir bestätigen.
• Entwickle Theorien über mögliche Ursachen.
• Entwickle Experimente und führe diese durch, um deine Theorien zu belegen oder zu widerlegen.
• Wiederhole diese Schritte, bis der Vorfall behoben wurde.

Ein Vorfall gilt als behoben, wenn die aktuellen oder drohenden geschäftlichen Auswirkungen beseitigt sind. An diesem Punkt endet der Prozess für Notfallmaßnahmen. Das Team kann nun mögliche Bereinigungsaufgaben durchführen und sich der Post-Mortem-Analyse widmen.

Wir versenden abschließende interne und externe Mitteilungen, wenn der Vorfall behoben wurde. Die internen Mitteilungen 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 behoben wurde und es keine weiteren Mitteilungen dazu geben wird. Die externen Mitteilungen sind in der Regel kurzgehalten. Kunden werden darüber informiert, dass der Service wiederhergestellt wurde und dass wir eine Post-Mortem-Analyse durchführen werden.