Incident Response: Ein praktisches Playbook

Incidents sind keine Ausnahmeereignisse; sie sind ein normales Nebenprodukt laufender Systeme. Was Teams unterscheidet, ist nicht, ob etwas kaputtgeht, sondern wie vorhersehbar sie reagieren, wenn es passiert. Ein funktionierender Incident-Prozess passt auf eine Seite: klare Severity-Level, benannte Rollen, Runbooks, denen man unter Stress folgen kann, Alerts, die an das gekoppelt sind, was Nutzer erleben, und eine Postmortem-Gewohnheit, die jeden Incident in eine Systemverbesserung verwandelt. Dieses Playbook behandelt jedes Element.

Severity-Klassifizierung

Severity existiert, um eine Frage schnell zu beantworten: Wie stark mobilisieren wir? Drei Stufen reichen für die meisten Organisationen. SEV1: Nutzer können das Produkt nicht verwenden, Daten sind gefährdet oder ein Sicherheitsvorfall läuft — alle Mann an Deck, Vorstandsbenachrichtigung, öffentliche Statusseite. SEV2: erhebliche Beeinträchtigung mit Workaround oder ein großes Feature ausgefallen — dediziertes Responder-Team, Stakeholder-Updates in festem Takt. SEV3: geringe Auswirkung oder erhöhtes Risiko — das zuständige Team übernimmt während der Arbeitszeit.

Zwei Regeln machen das Schema funktionsfähig. Jeder darf einen Incident ausrufen — wenn das Ausrufen den Segen eines Managers braucht, haben Sie Latenz genau dort eingebaut, wo sie am meisten schadet. Und im Zweifel hoch klassifizieren und später herabstufen; das umgekehrte Muster — einen Incident nach einer Stunde hochzustufen — ist der Weg, auf dem kleine Ausfälle zu langen werden.

Rollen: Der Incident Commander debuggt nicht

Die wertvollste strukturelle Änderung für die meisten Teams ist die Trennung von Koordination und Untersuchung. Der Incident Commander (IC) besitzt die Response: verfolgt den Stand, verteilt Arbeit, entscheidet über Mitigationen und verhindert, dass der Incident-Kanal zu vierzig Leuten wird, die „irgendein Update?" fragen. Der IC fasst kein Terminal an. Der Communications Lead besitzt den Fluss nach außen — Statusseiten-Updates, Stakeholder-Nachrichten, das Versprechen des nächsten Updates und dessen Einhaltung. Der Operations Lead treibt die technische Untersuchung mit wem auch immer nötig ist.

In einem kleinen Team kann bei einem SEV3 eine Person alle drei Hüte tragen — das ist in Ordnung, solange die Hüte existieren und ein SEV1 sie trennt. Der Fehlermodus, gegen den man designen muss: Der beste Engineer debuggt, koordiniert und beantwortet Vorstandsfragen gleichzeitig — und macht alle drei Dinge schlecht.

Runbooks, die um 3 Uhr nachts funktionieren

Ein Runbook wird unter den schlechtesten Bedingungen beurteilt: ein gepagter Engineer, halb wach, der diesen Alert zum ersten Mal sieht. Das setzt die Qualitätslatte. Jeder Page-Level-Alert verlinkt direkt auf sein Runbook. Der erste Abschnitt ist diagnostisch — drei Befehle, die klären, was tatsächlich passiert — vor jeder Remediation. Befehle sind copy-pastefähig, nicht in Prosa beschrieben. Der Eskalationspfad nennt ein Team und einen Kanal, nicht eine Person, die letztes Jahr gegangen ist. Und Runbooks werden geübt: Ein Game Day, der die On-Call-Rotation durch die Top-5-Runbooks führt, findet die veralteten, bevor ein Ausfall es tut.

SLO-getriebenes Alerting

Auf Ursachen zu pagen — CPU hoch, Disk bei 80 %, ein Pod startet neu — erzeugt Rauschen, und Rauschen erzeugt ignorierte Pages. Pagen Sie stattdessen auf Symptome: Das Service Level Objective verbrennt. Wer 99,9 % Verfügbarkeit verspricht, hat ein Fehlerbudget von 0,1 % der Requests; ein Page sollte feuern, wenn dieses Budget schnell genug verbraucht wird, um zu zählen. In Prometheus-Begriffen sieht eine Fast-Burn-Regel für ein 99,9-%-SLO so aus:

- alert: HighErrorBudgetBurn
  expr: (
      sum(rate(http_requests_total{code=~"5.."}[5m]))
    /
      sum(rate(http_requests_total[5m]))
  ) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: page
  annotations:
    summary: "Fast burn: Fehlerrate ist 14,4x das Budget eines 99,9%-SLO"

Paaren Sie die Fast-Burn-Regel (kurzes Fenster, hoher Multiplikator, pagt) mit einer Slow-Burn-Regel (langes Fenster, niedriger Multiplikator, öffnet ein Ticket). Ursachenbasierte Signale existieren weiter — als Dashboards und Tickets, nicht als Pages. Der praktische Effekt: Jeder Page bedeutet, dass Nutzer betroffen sind, also wird jeder Page ernst genommen. Sicherheitsrelevante Ereignisse verdienen dieselbe Disziplin; unser Überblick über SIEM-Systeme zeigt, wie Detection und Alerting auf dieser Seite zusammenlaufen.

Blameless Postmortems

Das Postmortem ist der Ort, an dem ein Incident zur Investition wird. Blameless heißt nicht konsequenzfrei; es heißt, die Analyse nimmt an, dass Menschen mit den Informationen, die sie hatten, vernünftig gehandelt haben — und fragt, warum das System die falsche Aktion leicht oder die richtige schwer gemacht hat. Ein brauchbares Postmortem enthält eine präzise Timeline, die vollständige Menge der beitragenden Faktoren — widerstehen Sie der Fiktion einer einzigen Root Cause — und Action Items, die jeweils Owner und Fälligkeitsdatum haben. Ein Action Item ohne Owner ist ein Wunsch. Offene Punkte in einem stehenden Forum reviewen und Postmortems breit teilen: Ein Ausfall, aus dem die ganze Organisation lernt, war nicht ganz umsonst.

Nichts davon erfordert neues Tooling — es erfordert, den Prozess in ruhigen Zeiten zu entscheiden, statt ihn während eines Ausfalls zu erfinden. Wenn Sie Hilfe beim Aufbau von Severity-Schemata, On-Call-Struktur und SLO-basiertem Alerting wollen — oder einen Incident-Prozess, der auch Security-Ereignisse abdeckt — macht unser SecOps-Team genau diese Arbeit, und unsere Managed Services tragen die On-Call-Last mit Ihnen.

Gegen Ihre Accounts geprüft? Unser AWS Security Assessment deckt 98 Punkte ab, gemappt auf ISO 27001, SOC 2, NIS2 und DORA — Festpreis, Evidenz inklusive.