Wenn man den Fokus auf den Prozess und das System legt statt auf Schuldzuweisungen, schafft man psychologische Sicherheit. Nur so werden Fehler offen kommuniziert und echte Ursachen behoben, anstatt sie zu vertuschen. In der Technik (besonders im SRE-Umfeld) nennt man das oft Blameless Post-Mortem: Man fragt „Wie konnte das System das zulassen?“ und nicht „Wer hat Enter gedrückt?“.
Das Symptom
Der Grundsatz lautet: Menschliches Versagen ist ein Symptom, keine Ursache. Wenn ein Mensch das System versehentlich zerstören kann, ist das System schlecht designt, nicht der Mensch inkompetent.
Ein perfektes Beispiel für ein System, das auf menschliche Fehler ausgelegt ist, ist ein Bleistift mit Radierer am anderen Ende. Er signalisiert zwei Dinge:
- Fehler werden erwartet (sonst wäre der Gummi nicht fest montiert).
- Korrektur ist billig (Mean Time to Recovery $\approx$ 0 Sekunden).
In meiner Welt der Command Line gibt es dafür direkte Entsprechungen:
- Der Radierer:
git restoreodergit reset. - Der Lehrer, der dich stoppt: Der Rust-Compiler oder shellcheck .
- Der Bleistift ohne Radierer oder Kugelschreiber:
rm -rfohne Backup.
Der Wassermelonen-Effekt
Das Gegenteil dieser Kultur ist der „Wassermelonen-Effekt“: Außen schön grün, innen blutrot. Manager fragen oft: “Ich brauche den Status.” – meinen im Subtext aber: “Ich möchte, dass dieser grün ist.” Der Mitarbeiter versteht: “Dann muss ich halt lügen.”
Das Ergebnis ist fatal:
- Verlust der Realität: Man steuert anhand gefälschter Karten.
- Überraschender Knall: Projekte scheitern nicht langsam, sondern katastrophal.
Im SRE gilt daher:
„Bad news is better than no news. And bad news does not get better with age.“
Ein roter Status ist keine Schande, sondern ein Signal, dass das „Error Budget“ aufgebraucht ist und man Stabilität vor neue Features stellen muss.
Rapid Unscheduled Disassembly (RUD)
Wenn man die “Wassermelone” zu lange spielt, endet es oft in dem, was SpaceX euphemistisch als „Rapid Unscheduled Disassembly“ bezeichnet: Das System zerlegt sich spontan und ungeplant in seine Einzelteile. In einer guten Fehlerkultur feiern wir den „Near Miss“ (den Beinahe-Unfall). Wer sagt: „Ich glaube, da ist ein Haarriss in der Config“, ist kein Pessimist, sondern verhindert das RUD. Wer Angst hat, für den Haarriss bestraft zu werden, schweigt – bis es knallt.
Fünfmal “Warum?”
Wie kommen wir von “Person X hat Mist gebaut” zu “Systemfehler”? Mit der 5 Whys Methode. Man fragt so lange „Warum“, bis man bei einem Prozessmangel ankommt.
Beispiel: Der Blog ist down.
- Warum? Caddy ist abgestürzt.
- Warum? Die Config war fehlerhaft.
- Warum? Ich habe via
vidirekt auf dem Server editiert. - Warum? Es gab keine Validierung vor dem Restart.
- Warum (Root Cause)? Es fehlt eine CI/CD-Pipeline, die
caddy validateausführt.
Ergebnis: Nicht „Ich war dumm“, sondern „Das Deployment-Verfahren ist unsicher“.
Proaktiv statt Reaktiv: Das Chaos Engineering
Die höchste Stufe dieser Kultur ist das Chaos Engineering. Anstatt darauf zu warten, dass ein Fehler zufällig passiert, provozieren wir ihn absichtlich (z.B. durch das Abschalten von Servern im laufenden Betrieb). Wir fragen nicht: “Was tun wir, wenn das Backup fehlschlägt?” Wir kappen die Verbindung zur Datenbank, beobachten und messen, ob der Failover greift. Wer Fehler proaktiv einlädt, verliert die Angst vor ihnen.
Fazit
Wer Fehler bestraft, bekommt keine fehlerfreie Software, sondern nur Mitarbeiter, die besser im Vertuschen werden.
Kommentare