Bei einem Ausfall ist das technische Problem selten der schwierige Teil. Die Koordination ist es. Dies ist die Reihenfolge, die ein kleines Team davon abhält, alles schlimmer zu machen.
Die meisten kleinen Teams bewältigen ihren ersten ernsten Ausfall schlecht — nicht aus Inkompetenz, sondern weil alle gleichzeitig debuggen, niemand mit Kunden spricht und zwei Leute widersprüchliche Fixes deployen. Das folgende Playbook existiert, um das zu verhindern.
Die ersten zehn Minuten
- Erklären Sie es. Sagen Sie das Wort «Incident» laut im Team-Channel. Unklarheit darüber, ob es ernst ist, kostet mehr Zeit als jeder technische Schritt.
- Benennen Sie einen Incident Lead. Eine Person, ausdrücklich. Sie debuggt nicht — sie koordiniert, entscheidet und führt die Zeitleiste.
- Bewerten Sie den Wirkungsradius: Wer ist betroffen, bewegt sich Geld falsch, sind Daten gefährdet. Das bestimmt alles Weitere.
- Blutung stoppen, bevor die Ursache gesucht wird. Rollback, Feature abschalten, Wartungsseite. Verstehen kann warten; Kundenauswirkung nicht.
- Setzen Sie eine Statusmeldung ab. Selbst «wir untersuchen» schlägt Schweigen — Schweigen macht aus einem Ausfall ein Vertrauensproblem.
Rollen, selbst in einem Viererteam
| Rolle | Tut | Tut NICHT |
|---|---|---|
| Incident Lead | Entscheidet, koordiniert, führt die Zeitleiste | Debuggen — sobald er das tut, endet die Koordination |
| Investigator | Findet und behebt die Ursache | Mit Kunden sprechen |
| Comms | Aktualisiert Statusseite, Kunden, internes Team | Öffentlich über die Ursache spekulieren |
In einem kleinen Team kann eine Person zwei Rollen halten — aber Incident Lead und Investigator dürfen bei einem ernsten Vorfall niemals dieselbe Person sein.
Was Sie Kunden sagen
- Schnell bestätigen, auch ohne Antworten — «wir wissen davon und untersuchen» innerhalb von Minuten
- Auswirkung in ihren Begriffen benennen: was sie gerade nicht tun können, nicht welcher Dienst degradiert ist
- Einen Zeitpunkt für das nächste Update nennen und ihn einhalten, auch wenn sich nichts geändert hat
- Niemals über eine unbestätigte Ursache spekulieren — Widerrufe kosten mehr Vertrauen als Schweigen gekostet hätte
- Klar sagen, wenn es behoben ist, und bei materieller Auswirkung eine schriftliche Erklärung nachreichen
Danach: der Teil, den alle überspringen
Ein Postmortem innerhalb von 48 Stunden, solange die Erinnerung genau ist. Blameless — nicht aus Höflichkeit, sondern weil Schuldzuweisung Menschen dazu bringt, Informationen zurückzuhalten, und der nächste Vorfall dadurch schwerer zu verhindern ist.
- Zeitleiste: was passierte, wann, wer tat was — nur Fakten
- Auswirkung: Dauer, betroffene Nutzer, Geld- oder Datenfolgen
- Beitragende Faktoren, Mehrzahl — eine einzige Ursache ist fast immer eine Vereinfachung
- Maßnahmen mit Verantwortlichen und Terminen; Punkte ohne beides sind Dekoration
- Was gut lief — die Erkennung oder Reaktion, die funktioniert hat, ist es wert, verstärkt zu werden
Sie steigen nicht auf das Niveau Ihres Incident-Response-Plans. Sie fallen auf das Niveau desjenigen, den Sie tatsächlich geübt haben.
Vorbereitung, bevor es passiert
- Alarmierung auf Symptome, die Kunden spüren (Checkout schlägt fehl), nicht nur auf Infrastrukturmetriken (CPU hoch)
- Ein Rollback, der ein Befehl ist und in ruhigen Zeiten geprobt wurde
- Eine Statusseite, die existiert, bevor Sie sie brauchen
- Schriftliche Eskalation: wer um 3 Uhr nachts angerufen wird und wer, wenn diese Person nicht abnimmt
- Ein Probelauf — brechen Sie absichtlich etwas in Staging und folgen Sie dem Playbook
Wiederherstellung am Nutzerablauf bestätigen
Weniger Fehlermeldungen können defekte Abläufe oder inkonsistente Daten verdecken. Vor dem Abschluss festlegen, was nachgewiesen werden muss.
- Auswirkungen, letzten funktionierenden Zustand und jüngste Änderungen erfassen.
- Eine umkehrbare Maßnahme mit Verantwortlichem und Abbruchkriterium wählen.
- Kernabläufe, verzögerte Aufgaben und Datenabgleich überprüfen.
Häufige Fragen
Was ist das Erste, wenn die Produktion ausfällt?
Einen Incident erklären und eine Person als Incident Lead benennen, dann mitigieren statt diagnostizieren — Rollback, kaputtes Feature abschalten oder Wartungsmodus aktivieren. Die Wiederherstellung des Dienstes kommt zuerst; die Ursache zu verstehen ist eine Aufgabe für danach, wenn Kunden wieder arbeiten können.
Sollen wir Kunden sofort informieren?
Ja. Bestätigen Sie innerhalb von Minuten, beschreiben Sie die Auswirkung in Begriffen dessen, was sie nicht tun können, und nennen Sie einen Zeitpunkt für das nächste Update. Schweigen während eines Ausfalls beschädigt Vertrauen stärker als der Ausfall selbst, und Spekulation, die Sie später widerrufen, ist schlimmer als beides.
Brauchen wir für jeden Vorfall ein Postmortem?
Für alles mit Kundenauswirkung ja — und es sollte innerhalb von 48 Stunden geschrieben werden, solange die Erinnerung stimmt. Halten Sie es blameless: Teams, die Schuld zuweisen, bekommen weniger ehrliche Informationen, was den nächsten Vorfall wahrscheinlicher macht, nicht seltener.
Sollte jedes verdächtige Deployment zurückgerollt werden?
Nein. Zuerst Datenbankänderungen und externe Folgen prüfen. Eine Rücknahme kann Datenänderungen möglicherweise nicht aufheben und die Störung verschärfen.
Gerade in einem Incident?
Wir leisten technische Notfallreaktion — Triage, Mitigation, Ursachenanalyse und das Postmortem danach.
Weiterführend
Postmortems, die tatsächlich gelesen werden: Best Practices
Die meisten Postmortems sind Archäologie: ein genaues Protokoll von etwas, das niemand ändern wird. Ein nützliches erzeugt eine kleine Zahl von Dingen, die tatsächlich erledigt werden.
Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen
Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.