Die Wissenschaft von Engineering-Incidents und Identität: Warum es selten die Schuld eines Einzelnen ist

TESTE_DICH · Wie gut kennst du diese Forschung?

1. 01 Was sagt James Reasons Schweizer-Käse-Modell darüber, wie komplexe Systeme versagen?

   Eine nachlässige Person ist immer die Grundursache jedes schwerwiegenden AusfallsAusfälle entstehen, wenn Lücken in mehreren Verteidigungsschichten sich gleichzeitig ausrichtenSoftwaresysteme scheitern aufgrund unzureichender Tests durch QA-IngenieureKomplexe Ausfälle sind von Natur aus zufällig und unvorhersehbar

   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 ↗

2. 02 Was ist laut dem Kapitel zur Postmortem-Kultur im SRE-Buch von Google der Hauptzweck eines schuld­freien Postmortems?

   Den Ingenieur zu identifizieren und formal zu rügen, der den Ausfall verursacht hatDen Vorfall zu dokumentieren, alle beitragenden Grundursachen zu verstehen und Präventivmaßnahmen einzuleitenEinen öffentlichen Bericht darüber zu erstellen, was für Kunden schiefgelaufen istDie Reduzierung der Bereitschaftsrotationsgröße des Teams zu rechtfertigen

   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 ↗

3. 03 Was fand die Studie von Champion et al. 2024 über Infrastruktur- und Klebstoffarbeit in Open-Source-Software-Ökosystemen?

   Infrastrukturingenieure werden häufiger anerkannt als Feature-Ingenieure aufgrund der Sichtbarkeit von VorfällenKlebstoffarbeit wie Dokumentation und Code-Review wird systematisch weniger anerkannt als Feature-CommitsOpen-Source-Maintainer werden durch Community-Stipendien gut für unsichtbare Arbeit entschädigtDie Studie fand keinen wesentlichen Unterschied in der Anerkennung zwischen verschiedenen Arten von Beiträgen

   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 ↗

4. 04 Was passiert laut der Stack Overflow Developer Survey 2025 mit dem Vertrauen der Entwickler in KI-generierten Code?

   Das Vertrauen in KI-generierten Code ist auf einem Allzeithoch, da die Modelle sich verbessernDas Vertrauen in KI-Ausgaben ist unter Entwicklern auf einem AllzeittiefDas Entwicklervertrauen in KI ist gegenüber den Vorjahren unverändert — die Bedenken sind übertriebenEntwickler vertrauen KI bei Dokumentation, aber nicht speziell bei der Code-Generierung

   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 ↗

5. 05 Was fanden Allspaw und Robbins über den Effekt der Schuld­kultur auf technische Vorfalls­untersuchungen?

   Schuld motiviert Ingenieure zu mehr Sorgfalt und reduziert künftige VorfälleDie Angst vor Bestrafung veranlasst Ingenieure, Informationen zurückzuhalten, was die Zuverlässigkeit im Laufe der Zeit verschlechtertSchuldkultur hat keinen messbaren Effekt auf den Informationsaustausch in PostmortemsSchuld sollte selektiv angewandt werden — nur auf Ingenieure, die schriftliche Verfahren verletzt haben

   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 ↗