Das teuerste Wort in einem Incident ist «recovered». In einem realen Incident — dem Verlust von Netzwerk-Aliassen in Docker Swarm — wurde Recovery zweimal verkündet: Nach der ersten Verkündung kam der Regress binnen einer Stunde zurück, nach der zweiten häuften sich stille Schäden weitere vier Tage an, weil die Control Plane zuversichtlich «everything is up» meldete. Eine verfrühte Verkündung kostet mehr als der Ausfall selbst: Sie holt das Team aus dem Kriegsmodus und verbrennt das Vertrauen in jedes folgende «jetzt läuft es».
Das Gerüst, das einen Incident vor dem Chaos bewahrt, besteht aus drei Teilen: der Severity-Klassifikation, den Rollen des Incident Command System und einer formalen Definition of Recovered.
Severity wird in einer Minute vergeben — und sie entscheidet alles
SEV1 — vollständiger Prod-Ausfall, Datenverlust oder ein Security Breach: Page binnen fünf Minuten, All-hands, Status-Page, Leitung im Bilde. SEV2 — schwere Degradation eines Schlüssel-Features: Page binnen 15 Minuten, On-Call plus Manager. SEV3 — Degradation mit Workaround: Ticket binnen einer Stunde, Team-Kanal. SEV4 — kosmetisch, next business day, Backlog.
Der Sinn dieser Tabelle liegt nicht in der Klassifikation selbst, sondern darin, dass sie die erste Entscheidung von einem müden Menschen um drei Uhr nachts nimmt: Severity bestimmt, wer geweckt wird, welcher Kanal aufgeht und wie viel Zeit für die Reaktion bleibt. Der Streit «ist das wirklich ein SEV1?» wird auf den Postmortem vertagt — einen Incident nachträglich herabzustufen ist billig, eine Eskalation zu verschlafen ist teuer.
ICS: Der Commander fasst die Tastatur nicht an
Bei SEV1/SEV2 greift das Incident Command System — ein Satz von Rollen aus der Welt der Feuerwehren. Der Incident Commander trifft Entscheidungen und koordiniert — und arbeitet nicht hands-on. Der Operations Lead führt die technische Diagnose und Mitigation. Der Communications Lead aktualisiert die Status-Page und hält Kunden und Leitung auf dem Laufenden. Der Scribe führt die Chronologie im Kanal #incident-NNN. SMEs werden nach Domäne hinzugezogen — Datenbank, Netzwerk, ein konkreter Service.
Eine Regel über allem: Der IC kann nicht gleichzeitig graben und koordinieren. Ein überlasteter Commander verliert das Gesamtbild, das Team verliert die Synchronisation — und eine Stunde später stellt sich heraus, dass zwei Engineers parallel inkompatible Mitigations ausgerollt haben.
Mitigate ≠ Fix
Der Incident-Lebenszyklus: Detect → Triage → Mitigate → Resolve → Learn. Mitigate heißt, die Blutung zu stoppen: Rollback, Scale-up, ein abgeschaltetes Feature Flag. Fix heißt, die Root Cause in ruhiger Umgebung zu beheben, danach. Der klassische Fehler ist, die Root Cause auf dem Höhepunkt des Incidents zu debuggen, während ein Rollback den Service in zwei Minuten zurückgebracht hätte: 90% der Incidents hängen an einer kürzlichen Änderung, deshalb wird «was in den letzten zwei Stunden ausgerollt wurde» vor dem ersten Stack Trace geprüft.
Die drei Gates vor dem Wort «recovered»
Diese Lehre formalisiert sich in drei Prüfungen, ohne die der Incident nicht geschlossen wird.
Das erste Gate ist stable-for-N-minutes unter Prod-Traffic. N skaliert mit der Severity: SEV1 — ab 30 Minuten, SEV2 — ab 15. Ein einzelner grüner Punkt im Graphen ist kein Trend.
Das zweite ist downstream-artefact verification. Für jeden kritischen Output der betroffenen Services — Sitemap, RSS, Public API, geplante Exporte — werden Frische und Korrektheit geprüft, nicht nur die Health des Service selbst. Die Kombination «Service up, Artefakt stale» ist ein klassischer Schlag gegen die Glaubwürdigkeit.
Das dritte ist der post-recovery discovery audit, und er verdient einen eigenen Abschnitt.
Solange nicht alle drei Gates bestanden sind, lautet der Incident-Status «stabilised, verification ongoing». Nicht «closed».
Die Control Plane lügt: declared vs actual
Der heimtückischste Failure Mode ist jedem Orchestrator mit internem DNS gemein: Die Control Plane meldet «everything is up», während die tatsächlichen Registrierungen teilweise fehlen oder veraltet sind. In Kubernetes kann ein Pod Running sein, aber nie in die Endpoints gelangen — Readiness, ein Node-Taint. In Docker Swarm fallen Overlay-Aliasse weg, und ein In-Place-Reconnect des Netzwerks stellt das Bookkeeping nicht wieder her. In Consul — Agent-Split-Brain oder eine abgelaufene Registrierungs-TTL. Downstream-Consumer bekommen derweil stillschweigend 504 oder NXDOMAIN.
Die Antwort ist ein wiederkehrender «declared vs actual»-Audit: Was deklariert ist (der Service-Selector, die Aliasse aus dem Compose-Stack, die Service Definition) wird gegen das verglichen, was tatsächlich registriert ist (EndpointSlice, Overlay-DNS, consul catalog). Das Ergebnis wird an einen externen Receiver gepusht — einen Uptime-Kuma-Push-Monitor oder healthchecks.io: Ein abgestürzter Cluster bricht auch sein eigenes Alerting, deshalb taugt ein lokaler Cron mit Alert hier nicht.
Von derselben Stelle kommt eine praktische Beobachtung zum Reset: Für einen Orchestrator mit opakem internem State ist Scale-to-zero und zurück stärker als ein In-Place-Restart, weil es das Bookkeeping des Schedulers freigibt. Wenn «restart den Pod» nicht geholfen hat, ist der State tiefer korrumpiert, als es von der Oberfläche aussieht.
«Recovered» ist ein Vertrag
Die Definition of Recovered ist der Vertrag des Teams mit seinen Nutzern: nicht «die Metrik ist grün geworden», sondern «stabil für N Minuten unter Traffic, Downstream-Artefakte frisch, declared deckt sich mit actual». Sie zu formalisieren kostet eine halbe Stunde auf einem Runbook. Sie nicht zu haben kostet vier Tage stiller Schäden nach der zweiten verfrühten Verkündung.