Vorlage für einen Incident-Response-Plan

Ein Incident-Response-Plan ist das feststehende Dokument, dem Ihr Team folgt, wenn die Produktion beeinträchtigt oder ausgefallen ist. Er wird in Ruhe geschrieben und unter Druck gelesen — deshalb muss er kurz, konkret und eindeutig sein.

Er ist kein Runbook. Ein Runbook beschreibt, wie ein bestimmtes System repariert wird. Der Plan beschreibt, wie sich das Team um jeden beliebigen Vorfall herum organisiert, egal welches System betroffen ist.

Er ist auch kein Security-Incident-Response-Plan im Compliance-Sinn, auch wenn sich beide überschneiden. Diese Vorlage für den IT-Incident-Response-Plan deckt betriebliche Vorfälle ab: Ausfälle, Beeinträchtigungen, fehlgeschlagene Deployments, Verzögerungen in Datenpipelines und Ähnliches. Sicherheitsspezifische Vorfälle eskalieren in der Regel in einen eigenen Prozess, und der Plan sollte sagen, wo diese Übergabe stattfindet.

In einem Punkt sind sich diese Handbücher vor allem einig: Senken Sie die Hürde für das Ausrufen. GitLabs Handbuch definiert Vorfälle als „anomale Zustände, die zu einer Beeinträchtigung oder einem Ausfall des Dienstes führen — oder führen können“. PostHogs Handbuch sagt: „Im Zweifel sollten Sie immer einen Vorfall ausrufen.“ Der Leitfaden von Login.gov formuliert es so: „Wenn es nach einem Vorfall riecht, rufen Sie einen Vorfall aus.“

Das funktioniert nur, wenn das Ausrufen wenig kostet und die nächsten Schritte offensichtlich sind. Ein schriftlicher Plan ist das, was einen Fehlalarm fünf Minuten kosten lässt statt eine Diskussion.

Ein Plan gibt Ihnen außerdem einen Maßstab. Ohne ihn endet jedes Postmortem mit der Feststellung, dass „die Kommunikation besser hätte sein können“. Mit ihm können Sie sagen, dass das erste Update auf der Statusseite nach 22 Minuten rausging, bei einem Ziel von 15 Minuten — und die konkrete Ursache der Verzögerung beheben.

Definition und Geltungsbereich

Sagen Sie, was ein Vorfall ist und, ebenso nützlich, was keiner ist. PostHogs Handbuch listet beides auf: Vollständige Nichtverfügbarkeit, unbenutzbare Kernfunktionen und kritische Alarme sind Vorfälle. Falsche Daten in einem Report, Events mit ein paar Minuten Verzögerung und geplante Wartung sind es nicht. Die Negativliste verhindert, dass kleine Bugs durch den vollen Prozess laufen.

Schweregrade

Jedes Handbuch nutzt eine kleine Zahl von Stufen, jede verknüpft mit Auswirkungen und einer Erwartung an die Reaktion. GitLab arbeitet mit S1 bis S4. PostHog nutzt Minor, Major und Critical. Sourcegraph teilt Severity 1 in Critical und Major und leitet Severity 2 über die normalen Support-Kanäle.

Die Bezeichnungen sind weniger wichtig als zwei Dinge. Erstens braucht jede Stufe Auswirkungskriterien, die ein Responder in Sekunden anwenden kann. Zweitens muss jede Stufe etwas an der Reaktion ändern: wer alarmiert wird, ob die Statusseite aktualisiert wird, ob die Führung informiert wird, ob außerhalb der Geschäftszeiten daran gearbeitet wird. GitLabs Regel, dass am Wochenende nur S1 und S2 aktiv bearbeitet werden, ist ein gutes Beispiel dafür, wie der Schweregrad echte Arbeit leistet.

Rollen

Jeder Plan benennt eine einzelne verantwortliche Person. GitLab nennt sie Incident Lead und stellt ausdrücklich klar, dass es „nur einen benannten Incident Lead pro Vorfall“ gibt und nur diese Person den Vorfall für behoben erklären kann. Sourcegraph nennt sie ebenfalls Incident Lead — die direkt verantwortliche Person, „die den Vorfall zur Lösung treibt und die anderen informiert hält“.

PostHog ergänzt die Klarstellung, die die meisten Teams übersehen: „Die Rolle des Incident Lead ist nicht dafür verantwortlich, den Vorfall zu beheben, sondern dafür, ihn zu managen.“ Wenn dieselbe Person beides tut und es zu viel wird, übergibt sie die Lead-Rolle an jemand anderen.

Neben dem Lead sind die üblichen Rollen ein technischer Responder, eine für die Kommunikation verantwortliche Person und, in größeren oder regulierten Teams, ein Scribe. Der Leitfaden von Login.gov benennt alle vier: Situation Lead, Technical Lead, Messenger und Scribe. Sourcegraph besetzt die Rolle des Messengers nur bei kundenseitigen Auswirkungen und verlangt, dass die Person aus dem Support kommt, damit die Formulierungen konsistent bleiben. Kleine Teams können Rollen auf eine oder zwei Personen zusammenlegen. Wichtig ist, dass der Plan sagt, welche Hüte es gibt und wer sie aufsetzt.

Einen Vorfall ausrufen

Sagen Sie, wer ausrufen darf, wie und wo es angekündigt wird. In jedem dieser Handbücher darf jeder ausrufen, und ein Slack-Befehl öffnet einen eigenen Kanal und postet in einen gemeinsamen Incidents-Kanal. Fleet ist die Ausnahme im Mechanismus, nicht im Prinzip: Vorfälle werden ausgerufen, indem aus einer Vorlage ein Issue eröffnet wird, was die Alarmierung auslöst.

Hierher gehört auch eine kurze Checkliste der ersten Schritte. Lead bestätigen, vorläufigen Schweregrad festlegen, die benötigten Personen alarmieren, ein erstes Update auf der Statusseite veröffentlichen, die Zeitleiste beginnen. GitLabs Ablauf auf der Statusseite — „Wird untersucht“, „Identifiziert“, „Wird überwacht“ und „Behoben“ — ist ein sinnvoller Standard für die öffentliche Seite.

Eskalation

Schreiben Sie Auslöser und Ziele auf. Fleets Handbuch ist präzise: Bleibt eine Benachrichtigung nach fünf Minuten unbestätigt, eskaliert sie automatisch — vom Infrastruktur-On-Call zum Incident-On-Call zu den Engineering Managern bis zum CTO. GitLab alarmiert die Infrastrukturleitung bei jedem S1, wenn der diensthabende Incident Manager 15 Minuten lang nicht reagiert und wenn mehrere Vorfälle mit hohem Schweregrad gleichzeitig offen sind.

Nehmen Sie eine eigene Zeile für vermutete Sicherheits- oder Datenvorfälle auf. Jedes Handbuch leitet diese in einen eigenen Prozess, und der Plan sollte sagen, wen man anruft, statt anzunehmen, dass die Beteiligten es wissen.

Kommunikationsplan

Entscheiden Sie, wer was erfährt, über welchen Kanal, von wem und wie oft. Interne Kanäle tragen Details, Theorien und Namen. Die Statusseite trägt bestätigte Auswirkungen und das, was Kunden erwarten können. PostHogs Handbuch zieht die Grenze für Kundenkommunikation über die Statusseite hinaus bei Vorfällen, die einen teilweisen oder vollständigen Ausfall verursachen, oder bei Ingestion-Verzögerungen über 30 Minuten.

Legen Sie einen Update-Rhythmus fest und halten Sie ihn ein. Eine Statusseite, die zwei Stunden lang „Wird untersucht“ anzeigt, ohne weiteres Update, ist schlechter als eine, die jede halbe Stunde „Untersuchung läuft weiter, nächstes Update in 30 Minuten“ sagt.

Behebung und Nachbereitung

Legen Sie fest, was „behoben“ bedeutet. PostHogs Kriterien sind konkret: Grundursache identifiziert, Korrektur umgesetzt, kundenseitige Dienste nachweislich normal, Statusseite als behoben markiert. Sagen Sie dann, welche Vorfälle einen schriftlichen Vorfallsbericht bekommen, welche ein Postmortem und bis wann. GitLab verlangt eine Auswertung für jeden S1 und S2, macht sie für S3 und S4 optional und hält jede Korrekturmaßnahme als gelabeltes Issue nach, das auf den Vorfall zurückverweist. Fleet verlangt ein Postmortem für jeden Ausfall und jeden kritischen Bug.

Tools

Verlinken Sie das Alarmierungstool, den On-Call-Plan, den Incident-Chat, die Statusseite, Runbooks, Dashboards sowie die Vorlagen für Bericht und Postmortem. Die Beteiligten sollten um 3 Uhr morgens nie nach einem Link suchen müssen.

Das folgende gekürzte Beispiel zeigt, wie ein kleines SaaS-Team die Vorlage ausfüllen könnte.

Angaben zum Plan

Geltungsbereich: Die kundenseitige Web-App, die öffentliche API und die Pipeline für die Dateningestion Verantwortlich: Platform Engineering Überprüfungsrhythmus: Vierteljährlich und nach jedem S1

Was als Vorfall zählt

Jedes ungeplante Ereignis, das Web-App, API oder Ingestion für Kunden beeinträchtigt oder unterbricht oder Kundendaten offenlegt. Vermutete Vorfälle werden ausgerufen und bei Bedarf später herabgestuft. Geplante Wartung und Bugs einzelner Konten mit Workaround sind keine Vorfälle.

Schweregrade

Rollen

Ausrufen

Jeder kann einen Vorfall ausrufen, indem er /incident in Slack ausführt. Das öffnet einen eigenen Kanal, postet in #incidents und alarmiert den On-Call-Engineer. Wer ausruft, ist Incident Lead, bis er die Rolle übergibt.

Eskalation

Außerhalb der Geschäftszeiten werden nur S1 und S2 bearbeitet. S3 und S4 warten bis zum nächsten Arbeitstag.

Kommunikation

Behebung und Nachbereitung

Behoben, wenn die Auswirkungen für Kunden beendet sind, die Gegenmaßnahme nachweislich stabil ist und die Statusseite als behoben markiert ist. Jeder Vorfall erhält einen Vorfallsbericht. S1 und S2 erhalten innerhalb von fünf Arbeitstagen ein Postmortem, mit Korrekturmaßnahmen, die als mit dem Vorfall verknüpfte Issues nachgehalten werden.

Diese drei Dokumente entstehen zu unterschiedlichen Zeiten und beantworten unterschiedliche Fragen.

Der Plan verweist auf Runbooks und bringt Vorfallsberichte hervor. Er ersetzt keines von beiden. Sehen Sie sich unsere Vorlage für den IT-Vorfallsbericht und die Vorlage für die Ursachenanalyse für das an, was folgt, sobald der Plan angewendet wurde.

• Halten Sie ihn kurz genug, um ihn während eines Vorfalls zu lesen. Wenn der Plan dreißig Seiten hat, arbeiten die Beteiligten stattdessen aus dem Gedächtnis. Details gehören in verlinkte Runbooks.
• Machen Sie das Ausrufen billig. Ein Befehl, ein Kanal, keine Freigabe. Fehlalarme sind ein Zeichen, dass die Schwelle richtig ist, nicht falsch.
• Trennen Sie Managen von Beheben. Der Incident Lead koordiniert. Wenn er zugleich tief im Code steckt, koordiniert niemand.
• Verknüpfen Sie jeden Schweregrad mit einer konkreten Reaktion. Eine Stufe, die nichts daran ändert, wer alarmiert oder was kommuniziert wird, ist nur ein Etikett.
• Bevorzugen Sie unter Druck den Rollback gegenüber der Grundursache. Sourcegraphs Handbuch sagt das ausdrücklich. Erst den Dienst wiederherstellen, dann untersuchen.
• Legen Sie Update-Rhythmen fest und halten Sie sie ein, auch wenn es nichts Neues gibt. Schweigen wirkt wie Abwesenheit.
• Schreiben Sie die Übergabe an die Security auf. Die Beteiligten sollten bei einem vermuteten Sicherheitsvorfall wissen, wen sie anrufen, ohne nachschlagen zu müssen.
• Überprüfen Sie den Plan nach jedem S1 und in einem festen Rhythmus. Ein Plan, der sich seit zwei Jahren nicht geändert hat, beschreibt ein Team, das es nicht mehr gibt.
• Üben Sie ihn. Login.gov macht die Teilnahme an Übungen verpflichtend. Ein kurzer Game Day ein- oder zweimal im Jahr findet Lücken, die keine Überprüfung je finden wird.

Wie detailliert sollte ein Incident-Response-Plan sein?

Detailliert genug, dass ein neuer On-Call-Engineer ihm um 3 Uhr morgens allein folgen könnte, und kurz genug, dass er es auch tut. Zielen Sie auf wenige Seiten. Alles Systemspezifische gehört in Runbooks, auf die der Plan verlinkt.

Wer sollte den Plan verantworten?

In der Regel das Team, das den On-Call für die Produktion stellt: Platform, Infrastruktur oder SRE. Die verantwortliche Stelle hält ihn aktuell und führt die Überprüfung nach jedem größeren Vorfall durch. Der Plan selbst sollte für jeden im Unternehmen lesbar sein, der einen Vorfall ausrufen könnte.

Brauchen wir alle vier Rollen?

Nein. In einem kleinen Team kann eine Person Incident Lead und Technical Lead zugleich sein, während der Support die Kommunikation übernimmt. Der Plan sollte sagen, welche Rollen es gibt, und klarstellen, dass eine Person mehrere übernehmen kann. Die einzige Regel, die nicht verhandelbar ist: ein einziger Incident Lead pro Vorfall.

Was unterscheidet ihn von einem Security-Incident-Response-Plan?

Sicherheitspläne konzentrieren sich auf Vertraulichkeit und Integrität, beziehen rechtliche und regulatorische Meldepflichten ein und folgen oft einem Rahmenwerk wie NIST. Diese Vorlage deckt betriebliche Verfügbarkeitsvorfälle ab. Beide überschneiden sich und sollten aufeinander verweisen, und dieser Plan sollte sagen, wann ein Vorfall an den Security-Prozess übergeben wird.

Wie oft sollten wir ihn überprüfen?

Nach jedem S1 und mindestens ein- oder zweimal im Jahr. Prüfen Sie, ob benannte Rollen, On-Call-Pläne, Tool-Links und Eskalationskontakte noch stimmen, und arbeiten Sie ein, was die letzten Postmortems nahegelegt haben.

Keines dieser Teams hat seinen Plan während eines Ausfalls geschrieben. Sie haben ihn in Ruhe geschrieben, das Ausrufen einfach gemacht, eine einzelne verantwortliche Person pro Vorfall benannt und den Plan überprüft, wann immer ein Vorfall gezeigt hat, dass er falsch lag.

Füllen Sie die Vorlage oben aus, verlinken Sie sie dort, wo Ihre On-Call-Rotation lebt, und behandeln Sie sie als lebendes Dokument. Die Aufgabe des Plans ist es, die ersten zehn Minuten des nächsten Vorfalls langweilig zu machen.

Vorlage und Leitfaden stützen sich auf diese öffentlich zugänglichen Incident-Response-Prozesse. Jeder nimmt zu den Fragen, die ein Plan beantworten muss, eine andere Position ein — deshalb lässt die Vorlage sie offen.