Incident-Response-Checkliste
Incident-Response-Checkliste für IT-Störungen: einstufen, Rollen verteilen, eindämmen, kommunizieren und nachbereiten. Startet direkt aus dem Alerting.
- Typischer Rhythmus pro Incident
- Die Checkliste 5 Abschnitte, 21 Punkte
- Variablen
{{incident_id}}{{service}} - Aus der CI starten
Diese Checkliste ist für den Moment, in dem ein Dienst ausfällt, langsam wird oder falsche Daten liefert. Sie gilt auch bei Verdacht auf einen Sicherheitsvorfall. Unter Stress vergessen selbst erfahrene Teams die einfachen Dinge: jemanden zum Koordinieren bestimmen, Kunden informieren, die Zeitachse festhalten. Die Liste nimmt diese Last ab, damit die Technik die volle Aufmerksamkeit bekommt.
Wer verantwortlich ist
Wer den Alarm zuerst annimmt, startet den Durchlauf und ist Incident Lead, bis die Rolle ausdrücklich übergeben wird. Der Incident Lead koordiniert und entscheidet, debuggt aber möglichst nicht selbst. Bei größeren Störungen übernimmt eine zweite Person die Kommunikation.
Typische Fehler
- Alle debuggen, niemand koordiniert. Zuerst den Incident Lead benennen, dann die Fehlersuche.
- Ursache suchen statt Schaden begrenzen. Erst eindämmen (Rollback, Feature-Flag, Failover), dann analysieren.
- Funkstille gegenüber Kunden. Ein kurzes "Wir wissen davon und arbeiten daran" hilft mehr als eine perfekte Meldung eine Stunde später. Feste Update-Intervalle zusagen und einhalten.
- Keine Zeitachse. Wer später rekonstruieren muss, wann was passiert ist, verliert Details. Wichtige Ereignisse sofort mit Uhrzeit notieren.
- Datenschutz zu spät einbeziehen. Wenn personenbezogene Daten betroffen sein könnten, laufen gesetzliche Meldefristen. Unter der DSGVO sind es in der Regel 72 Stunden ab Kenntnis.
Runbook kann den Durchlauf direkt aus dem Alerting starten, etwa per Webhook aus Prometheus Alertmanager, Grafana oder einem On-Call-Tool. Jeder abgehakte Schritt landet mit Zeitstempel im Protokoll. Das ist eine gute Grundlage für das Postmortem.
Die Checkliste: Incident {{incident_id}}: {{service}}
Erkennen und einstufen
-
Alarm bestätigt und Auswirkung auf
{{service}}beschriebenWas funktioniert nicht, für wen, seit wann? Ein bis zwei Sätze reichen.
-
Schweregrad festgelegt (z. B. SEV1 bis SEV3)
-
Incident Lead benannt und im Durchlauf zugewiesen
-
Incident-Channel oder Call eröffnet und Link geteilt
Eindämmen
-
Letzte Änderungen geprüft: Deployments, Konfiguration, Infrastruktur, Drittanbieter
-
Sofortmaßnahme entschieden und umgesetzt (Rollback, Feature-Flag aus, Failover, Skalieren)
Schaden begrenzen hat Vorrang vor der Ursachenanalyse.
-
Wirkung der Sofortmaßnahme in Metriken und Logs bestätigt
-
Bei Sicherheitsvorfall betroffene Zugänge gesperrt und Beweise gesichert optional
Logs und betroffene Systeme sichern, bevor sie neu aufgesetzt werden.
Kommunikation
-
Statusseite aktualisiert und erstes Update an Kunden veröffentlicht
-
Support-Team informiert, Textbaustein für Anfragen bereitgestellt
-
Nächstes Update-Intervall festgelegt und eingehalten (z. B. alle 30 Minuten)
-
Geschäftsleitung bei SEV1 informiert optional
-
Datenschutzverantwortliche eingebunden, falls personenbezogene Daten betroffen sein könnten optional
Sie prüft, ob eine Meldung an die Aufsichtsbehörde (EU) oder den EDÖB (Schweiz) nötig ist.
Beheben
-
Ursache eingegrenzt und dauerhafte Lösung umgesetzt oder als Ticket geplant
-
Dienst vollständig wiederhergestellt und überwacht
-
Rückstände aufgearbeitet (Queues, fehlgeschlagene Jobs, Daten-Korrekturen)
Abschluss und Nachbereitung
-
Entwarnung auf Statusseite und im Incident-Channel veröffentlicht
-
Zeitachse mit den wichtigsten Ereignissen und Uhrzeiten vervollständigt
-
Postmortem-Termin innerhalb weniger Tage angesetzt
-
Postmortem ohne Schuldzuweisung geschrieben und geteilt
-
Folgemaßnahmen als Tickets mit Verantwortlichen erfasst
Checkliste als Markdown
Diese Checkliste aus der Pipeline starten
Aus dem Alerting-Webhook POST /api/v1/runs mit der Vorlage "Incident {{incident_id}}: {{service}}" und der Alarm-ID als incident_id aufrufen.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Incident {{incident_id}}: {{service}}", "variables": {"incident_id": "…", "service": "…"}}'Häufige Fragen
Was sind die Phasen der Incident Response?
Die meisten Modelle teilen einen Incident in Erkennen, Einstufen, Eindämmen, Beheben und Nachbereiten. Die Kommunikation läuft parallel zu allen Phasen. Für Sicherheitsvorfälle beschreiben Frameworks wie NIST SP 800-61 ähnliche Phasen, mit stärkerem Fokus auf Beweissicherung.
Wann muss ein IT-Vorfall gemeldet werden?
Betrifft ein Vorfall personenbezogene Daten, verlangt die DSGVO in der Regel eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden. Das gilt nicht, wenn voraussichtlich kein Risiko für die Betroffenen besteht. In der Schweiz verlangt das revDSG eine möglichst rasche Meldung an den EDÖB bei hohem Risiko. Die Einschätzung gehört in die Hände der Datenschutzverantwortlichen. Diese Übersicht ersetzt keine Rechtsberatung.
Was gehört in ein Postmortem?
Eine Zusammenfassung der Auswirkung, die Zeitachse und die Ursache mit den beitragenden Faktoren. Dazu kommen eine ehrliche Liste dessen, was gut und was schlecht lief, und konkrete Folgemaßnahmen mit Verantwortlichen. Das Postmortem sucht nach Schwächen im System, nicht nach Schuldigen.
Aktualisiert