Die 7 Phasen einer effektiven 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.

No matter how the incident is detected, your first step should be to record that a new incident is open in a tool for tracking incidents. In an incident management solution such as Jira Service Management, alerting and communication is integrated with your tracking tool.

Richte Kommunikationskanäle für das Team ein.

One of the first things the incident manager (IM) does when they come online is set up the incident team's communication channels. The goal at this point is to establish and focus all incident team communications in well-known places, such as:

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

The next step typically is to assign a severity level.

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.

Sometimes the initial responders are the ones who resolve the incident. More often than not, those responders need to bring other teams into the incident by paging them using an alerting tool. With Jira Service Management, responders can take their pick as to what alerting method they use, or even use them all in one central location.

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.

After a new incident responder is paged and comes online, the incident manager delegates a role to them. As It’s important they understand what's required of their role, and how to contribute to the incident team quickly and effectively.

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.

Conclusion

There are many moving parts to the incident response process. Keeping track of each step with seamless communication is easy with an incident management tool like Jira Service Management. Centralize alerts and unify teams with flexibility to resolve incidents quickly.