Was wir aus drei Jahren Incident-Culture mitgenommen haben

Warum wir die Zahl 28 in dieser Klarheit teilen

Wir betreiben mehrere Plattformen für unsere Klienten 24/7. In den letzten drei Jahren hatten wir achtundzwanzig Incidents, die einen Sev-2 oder höher ausgelöst haben. Achtundzwanzig ist eine Zahl, die man nicht stolz nach außen trägt — aber sie ist ehrlich, und sie ist die Grundlage für alles, was wir über Incident-Kultur gelernt haben.

Wir teilen sie, weil die meisten Erfahrungsberichte zu Plattform-Betrieb eine Sterilität haben, die in echter Arbeit nicht existiert. Google selbst publiziert seine Erkenntnisse zur Postmortem-Kultur seit 2016 offen im SRE-Buch (Beyer et al., O'Reilly) ^[1]. Dieser Beitrag ist unser Versuch, im gleichen Geist Position zu beziehen.

Erkenntnis 1: Postmortems funktionieren nur ohne Schuldzuweisung

Wir schreiben jeden Sev-2-Incident und höher als Postmortem auf, mit einer festen Struktur: Zeitstrahl, Detection, Mitigation, Resolution, Beiträge, Gegenmaßnahmen. Das Wort „Beiträge" haben wir bewusst gewählt — nicht „Ursachen", nicht „Verschulden". Ein Incident hat in fast allen Fällen drei bis fünf Beiträge, die einzeln nicht zum Ausfall geführt hätten und die in Kombination das System gebrochen haben.

Das Konzept ist nicht unsere Erfindung — es geht auf Sidney Dekker („The Field Guide to Understanding Human Error", 2014) ^[2] und das blame-free Postmortem-Pattern aus dem Google-SRE-Buch zurück. Wer in einem Postmortem nach der einen Ursache sucht, optimiert auf das falsche Ziel und produziert Kultur, in der Engineers nicht mehr offen schreiben, was schiefgelaufen ist. Empirisch belegt ist der Zusammenhang zwischen Blame-Kultur und Reporting-Lücken in der Aviation-Safety-Forschung (Reason, „Human Error", Cambridge 1990) ^[3].

Erkenntnis 2: Rollen sind wichtiger als Skills

Rollen im Incident sind wichtiger als technische Skills. Wir haben drei Rollen formalisiert — angelehnt an das Incident-Command-System der US-Feuerwehr, das John Allspaw 2015 in seiner Lund-University-Master-Thesis auf SRE übertragen hat ^[4]. Der Incident Commander führt — er trifft Entscheidungen, eskaliert, kommuniziert mit dem Klienten. Er codiert nicht und debuggt nicht. Der Operations Lead arbeitet am System, testet Hypothesen und liefert Daten. Der Communications Lead schreibt Status-Updates an interne und externe Adressaten in einer festen Kadenz, typischerweise alle fünfzehn Minuten in der akuten Phase.

Diese Trennung klingt formal — bis man einen Incident erlebt, in dem alle drei Rollen von einer Person versucht werden. Dann passiert es, dass die wichtigste Hypothese zwanzig Minuten nicht verfolgt wird, weil der Engineer einen Slack-Thread mit dem Kunden moderiert.

Erkenntnis 3: Pattern-Bibliothek nach drei Wiederholungen

Nach zwölf Incidents fingen wir an zu sehen, dass viele Vorfälle in zwei oder drei Familien fielen. „Connection-Pool-Erschöpfung nach Deployment" war eine Familie. „Slow-Query unter Lastspitze" war eine andere. „Retry-Storm in einer Microservice-Kette" eine dritte. Wir schreiben für jede Familie ein Pattern auf: was sind die Symptome, was sind die ersten drei Diagnoseschritte, was ist die Mitigations-Strategie, was sind die strukturellen Gegenmaßnahmen.

Beim nächsten Incident der gleichen Familie sind wir nicht nur schneller, wir sind in der Detection schneller — wir erkennen das Muster früh. Das Vorgehen entspricht der Idee der „failure modes and effects analysis" (FMEA), die in der NASA-Software-Engineering-Praxis seit den 60ern dokumentiert ist ^[5], und wurde von Etsy 2014 als „Etsy Incident Library" in den DevOps-Kontext übertragen.

Erkenntnis 4: Klienten wollen Wahrheit, nicht Spin

Wir haben am Anfang gezögert, frühe Hypothesen mit Klienten zu teilen — aus Angst, wir würden Verwirrung stiften oder uns festlegen, bevor wir sicher sind. Inzwischen handhaben wir das anders. In jedem Status-Update sagen wir explizit, was wir wissen, was wir vermuten und was wir noch nicht wissen. Klienten — alle Klienten, ausnahmslos — reagieren darauf besser als auf glatte Aussagen, die den Eindruck erwecken, alles sei unter Kontrolle, obwohl es das nicht ist.

Vertrauen entsteht in Incidents nicht durch Souveränität, sondern durch Verlässlichkeit der Information. Die Forschung von Edmondson zu „psychological safety" zeigt den gleichen Mechanismus auf Team-Ebene (Edmondson, „Teaming", 2012) ^[6] — Vertrauen wächst dort, wo Unsicherheit benannt werden darf, ohne sanktioniert zu werden.

Erkenntnis 5: Stille Sensoren für die unsichtbaren Incidents

Die teuerste Kategorie sind die Incidents, die niemand bemerkt. Wir hatten Vorfälle, die kein Monitoring ausgelöst haben, die keine Klagen produziert haben, und die wir erst Tage später durch eine zufällige Code-Review entdeckt haben. Diese Incidents sind die gefährlichen: sie laufen unbemerkt, sie verursachen latente Datenkorruption, und sie kommen oft nur durch glückliche Zufälle ans Licht.

Als Reaktion haben wir in jeder Plattform eine Schicht „Stille Sensoren" eingebaut — Konsistenz-Prüfungen, die nichts mit unmittelbarer Verfügbarkeit zu tun haben, sondern mit Datenintegrität. Sie laufen täglich, sie warnen bei Abweichungen, und sie sind die wichtigste Detection-Schicht für die nicht-offensichtlichen Vorfälle. Das Konzept ist im SRE-Buch als „freshness/correctness SLI" (Kapitel 4) dokumentiert.

Was Incident-Kultur am Ende ist

Wenn wir all das zusammennehmen, ist Incident-Kultur weniger eine Frage von Tools und mehr eine Frage von Disziplin. Postmortems schreiben — schreiben, nicht nur diskutieren. Rollen einhalten — einhalten, auch wenn drei Personen verfügbar sind und alle drei mitdiskutieren wollen. Muster erkennen — anschreiben, sobald das Muster zum dritten Mal auftritt. Wahrhaftig kommunizieren — auch wenn die Antwort „wir wissen es noch nicht" ist.

Diese Disziplin ist nicht glamourös. Aber sie ist der Unterschied zwischen einer Plattform, die nach drei Jahren betreibbar bleibt, und einer, die langsam in eine Burn-Out-Spirale gerät.

1. [1]
   Site Reliability Engineering: How Google Runs Production Systems (Kap. 15: Postmortem Culture)

   Beyer, B., Jones, C., Petoff, J., Murphy, N.R. (Hrsg.) (2016) · book
2. [2]
   The Field Guide to Understanding "Human Error"

   Sidney Dekker (2014) · book
3. [3]
   Human Error (Cambridge University Press)

   James Reason (1990) · book
4. [4]
   Trade-offs Under Pressure: Heuristics and Observations Of Teams Resolving Internet Service Outages (M.Sc. Thesis, Lund University)

   John Allspaw (2015) · paper
5. [5]
   NASA Software Failure Modes and Effects Analysis (FMEA)

   NASA Goddard Space Flight Center (2008) · standard
6. [6]
   Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy

   Amy C. Edmondson (2012) · book
7. [7]
   PagerDuty Incident Response Documentation — Severity Levels

   PagerDuty Inc. (2024) · docs