FORSCHUNGSAKTE
Die Wissenschaft von Engineering-Incidents und Identität
"Wer hat Prod kaputt gemacht?"
DIE ÜBUNG ANSEHEN
Mach aus einem Gedanken, den diese Forschung erklärt, einen klaren Schritt.
DER GEDANKE
“Ich habe dieses Chaos geerbt und jetzt denken alle, es ist meine Schuld”
DEINE AUFGENOMMENE ANTWORT
“Dieser Bug hat ein Geburtsdatum, und es liegt vor meinem ersten Commit hier.”
EIN PRIVATER SCHRITT
Wähle ein offenes Ticket zu vererbtem Code und schreib eine Zweizeiler-Notiz: Was der Bug ist, und ungefähr wann der Code eingeführt wurde. Versende es noch nicht.
klingt nach der richtigen Frage nach einem Ausfall. Die Systemforschung gibt eine weniger befriedigende, aber weitaus nützlichere Antwort: Komplexe Systeme scheitern durch das Zusammentreffen vieler kleiner Bedingungen, nicht durch einen einzigen leichtfertigen Akteur (Reason 1990; Google SRE 2016). Unterdessen werden die Personen, die am meisten dafür verantwortlich sind, dass diese Systeme am Laufen bleiben — diejenigen, die Infrastrukturarbeit, Bereitschaftsdienste und Klebstoffarbeit leisten —, systematisch zu wenig anerkannt (Champion et al. 2024). Und jetzt kommt eine neue Identitätsbedrohung hinzu: KI-Tools, die versprechen, Ingenieure zu ersetzen, werden von einer schrumpfenden Minderheit der Entwickler vertraut (Stack Overflow 2025). Das alte Skript — 'hier ist jemand der Schuldige' — ist fast immer die falsche Lesart.
Wie sich die Wissenschaft verändert hat
- 1983
Arlie Hochschilds The Managed Heart prägt das Konzept der Gefühlsarbeit — Arbeit, die das Management der eigenen Gefühle als Teil der Tätigkeit erfordert, aber in keiner formalen Buchhaltung erfasst wird. Das Konzept verankert später die Forschung zu unsichtbarer Klebstoffarbeit in Software-Teams. ↗
- 1990
James Reason veröffentlicht Human Error und stellt das Schweizer-Käse-Modell der Unfallverursachung vor: Fehler entstehen, wenn Lücken in mehreren Abwehrschichten zusammentreffen, nicht weil eine Person einen einzigen Fehler gemacht hat. Das Modell wird grundlegend für die Luftfahrt, Medizin und später für die Software-Zuverlässigkeit. ↗
- 2006
Sidney Dekkers The Field Guide to Understanding Human Error rahmt 'menschliches Versagen' als Symptom, nicht als Ursache — der Ingenieur, der den falschen Knopf gedrückt hat, tat dies innerhalb eines Systems, das diese Aktion zuließ oder begünstigte. Schuldzuweisung, so Dekker, stoppt Untersuchungen auf der falschen Ebene. ↗
- 2012
John Allspaw und Jesse Robbins popularisieren schuldfreie Post-Mortems bei Etsy mit dem Argument, dass Ingenieure, die Bestrafung fürchten, Informationen verbergen — und versteckte Informationen töten die Zuverlässigkeit. Ihr Ansatz beeinflusst später Googles Site Reliability Engineering-Praxis. ↗
- 2016
Google veröffentlicht sein SRE-Buch und widmet ein vollständiges Kapitel der Postmortem-Kultur. Das Kapitel kodifiziert Schuldfreiheit als Organisationspolitik: 'Die Hauptziele des Schreibens eines Postmortems sind sicherzustellen, dass der Vorfall dokumentiert ist, alle beitragenden Grundursachen verstanden sind und effektive vorbeugende Maßnahmen ergriffen werden.' ↗
- 2018
Forsgren, Humble und Kim veröffentlichen Accelerate und korrelieren organisatorische Praktiken mit der Softwarelieferleistung über Tausende von Teams. Ihre Daten zeigen: Hochleistende Teams zeichnen sich nicht durch schuldfreie Helden aus, sondern durch psychologische Sicherheit, schnelle Feedbackschleifen und verteilte Verantwortung für Zuverlässigkeit. ↗
- 2024
Champion et al. veröffentlichen eine groß angelegte empirische Studie zu unsichtbarer Arbeit in Open-Source-Software-Ökosystemen: Infrastrukturwartung, Dokumentation, Code-Review und Community-Management werden systematisch weniger anerkannt als Feature-Commits — und die Lücke benachteiligt Ingenieure, die sich auf Zuverlässigkeit statt auf Neues spezialisieren. ↗
Was Menschen glauben vs. was die Daten zeigen
Der Glaube“Wenn ein Produktionsvorfall passiert, gibt es immer eine Grundursache und eine Person, die dafür verantwortlich ist.”
Die DatenReasons Schweizer-Käse-Modell und Dekkers Feldleitfaden zeigen beide, dass komplexe Systemausfälle erfordern, dass sich mehrere Lücken in mehreren Verteidigungsschichten gleichzeitig ausrichten. Googles SRE-Buch lehnt explizit Einzel-Grundursachen-Denken ab: Vorfälle sind das Produkt latenter Bedingungen, nicht individueller Schuldiger. ↗
Der Glaube“Wenn man nach einem Vorfall Rechenschaft will, muss jemand beschuldigt und bestraft werden.”
Die DatenAllspaw und Robbins dokumentierten das Gegenteil: Angst vor Bestrafung veranlasst Ingenieure, Informationen zurückzuhalten, was künftige Vorfälle wahrscheinlicher macht. Googles schuldfrei-Postmortem-Rahmen zeigt, dass echte Rechenschaft — dokumentierte Ursachen, Systemkorrekturen, präventive Maßnahmen — tatsächlich unvereinbar mit individueller Schuld ist. ↗
Der Glaube“Ingenieure, die an Infrastruktur, Bereitschaftsdiensten und Dokumentation arbeiten, leisten weniger wertvolle Arbeit als jene, die sichtbare Features liefern.”
Die DatenChampions empirische Studie aus dem Jahr 2024 über Open-Source-Ökosysteme fand heraus, dass Infrastrukturwartung, Dokumentation und Code-Review systematisch zu wenig anerkannt werden, obwohl sie das Fundament sind, auf dem sichtbare Features laufen. Forsgrens Accelerate-Daten zeigen, dass Zuverlässigkeitsarbeit — nicht nur Feature-Geschwindigkeit — hohe organisatorische Leistung vorhersagt. ↗
Der Glaube“Die richtige Reaktion auf einen Vorfall ist, die Person zu finden, die Bereitschaftsdienst hatte, und sie verantwortlich zu machen.”
Die DatenGoogles SRE-Postmortem-Rahmen trennt explizit die antwortende Person von den Bedingungen, die den Fehler ermöglichen. Der Bereitschaftsingenieur ist oft derjenige, der das Problem ans Licht gebracht hat, nicht derjenige, der die Bedingungen geschaffen hat. Ihn als Ursache zu behandeln schreckt künftige Einsatzkräfte davon ab, ehrlich zu handeln. ↗
Der Glaube“KI-Coding-Tools sind jetzt vertrauenswürdig genug, dass Ingenieure, die Angst vor KI-Ersatz haben, irrational handeln.”
Die DatenDie Stack Overflow Developer Survey 2025 ergab, dass das Vertrauen der Entwickler in KI-Ausgaben auf einem Allzeittief ist — die Mehrheit der Entwickler vertraut KI-generiertem Code nicht vollständig. Die Angst vor KI-Tools ist eine fundierte professionelle Reaktion auf eine unreife Technologie, die als reif vermarktet wird. ↗
TESTE_DICH · Wie gut kennst du diese Forschung?
01 Was sagt James Reasons Schweizer-Käse-Modell darüber, wie komplexe Systeme versagen?
Reasons Modell zeigt: Komplexe Systemausfälle sind mehrkausal — eine Reihe von Lücken in ansonsten robusten Verteidigungsschichten muss sich ausrichten, damit ein Unfall bis zum Ergebnis vordringt. Keine einzelne Person schafft alle Lücken. Quelle ↗
02 Was ist laut dem Kapitel zur Postmortem-Kultur im SRE-Buch von Google der Hauptzweck eines schuldfreien Postmortems?
Googles SRE-Buch besagt, dass die Hauptziele eines Postmortems darin bestehen, sicherzustellen, dass der Vorfall dokumentiert ist, alle beitragenden Grundursachen verstanden werden und effektive Präventivmaßnahmen ergriffen werden — nicht Einzelpersonen die Schuld zuzuweisen. Quelle ↗
03 Was fand die Studie von Champion et al. 2024 über Infrastruktur- und Klebstoffarbeit in Open-Source-Software-Ökosystemen?
Champion et al. fanden heraus, dass Infrastrukturwartung, Dokumentation, Code-Review und Community-Management in den meisten Anerkennungssystemen strukturell unsichtbar sind — trotzdem sie für das Funktionieren des Ökosystems wesentlich sind —, während Feature-Commits unverhältnismäßig viel Anerkennung erhalten. Quelle ↗
04 Was passiert laut der Stack Overflow Developer Survey 2025 mit dem Vertrauen der Entwickler in KI-generierten Code?
Die Stack Overflow Developer Survey 2025 fand das Vertrauen der Entwickler in KI-Ausgaben auf einem Allzeittief — die Mehrheit der Entwickler vertraut KI-generiertem Code nicht vollständig, trotz der raschen Verbreitung von KI-Coding-Tools. Quelle ↗
05 Was fanden Allspaw und Robbins über den Effekt der Schuldkultur auf technische Vorfallsuntersuchungen?
Allspaw und Robbins dokumentierten, dass die Angst vor Bestrafung Ingenieure dazu bringt, Informationen darüber zu verbergen, was während eines Vorfalls geschah. Diese versteckten Informationen hindern die Organisation daran, die tatsächlichen Bedingungen zu verstehen und zu beheben — was den nächsten Vorfall wahrscheinlicher macht. Quelle ↗