Ursachenanalyse - Lean Software Development

1Warum Grundursachen wichtig sind

Die meiste Problemlösung behandelt Symptome, nicht Ursachen.

Deployment fehlgeschlagen? Zurückrollen und erneut deployen. Bug in Production? Hotfix drauf. Build ist langsam? Mehr Build-Server hinzufügen.

Diese Fixes beheben den unmittelbaren Schmerz. Das Problem verschwindet... bis es wiederkommt. Weil Sie nicht behoben haben, was es verursacht hat.

Ursachenanalyse bedeutet, „warum?" zu fragen, bis Sie die systemische Ursache finden – das, was, wenn behoben, das Problem dauerhaft verhindern würde.

Das Deployment ist nicht wegen eines zufälligen Fehlers fehlgeschlagen. Es ist fehlgeschlagen, weil die Test-Suite instabil ist. Die Test-Suite ist instabil, weil Tests State teilen. Tests teilen State, weil das Testing-Framework nicht verstanden wurde, als es eingerichtet wurde.

Beheben Sie das unmittelbare Symptom (Deployment wiederholen) und Sie werden morgen erneut wiederholen. Beheben Sie die Grundursache (Verständnis des Test-Frameworks korrigieren) und Deployments hören auf zu scheitern.

Ursachenanalyse braucht anfangs mehr Zeit. Aber sie spart exponentiell mehr Zeit, indem sie Wiederauftreten verhindert.

Die Gefahr von Schnelllösungen

Jede Schnelllösung, die Grundursachen nicht adressiert, schafft ein Muster: das Problem tritt erneut auf, Sie beheben es wieder, es wird 'normal'. Irgendwann haben Sie ein System, das von Workarounds zusammengehalten wird, wo die eigentlichen Probleme unter Schichten von Patches unsichtbar sind.

2Fünf Warums

Die Fünf Warums sind die einfachste Ursachenanalyse-Technik: Fragen Sie weiter „warum?", bis Sie eine Grundursache erreichen, normalerweise nach etwa fünf Iterationen.

Beispiel:

Problem: Production war 2 Stunden lang ausgefallen.

Warum? Eine fehlerhafte Konfiguration wurde deployed.
Warum? Die Config-Änderung wurde nicht getestet.
Warum? Wir haben keine Tests für Config-Änderungen.
Warum? Config wird getrennt vom Code verwaltet.
Warum? Das Infrastruktur-Team hat es eingerichtet, bevor das Dev-Team GitOps eingeführt hat.

Grundursache: Historische Trennung von Config und Code in der Deployment-Pipeline.

Gegenmaßnahme: Config in dasselbe Repository und dieselbe CI/CD-Pipeline wie den Anwendungscode verschieben.

Fallstricke der Fünf Warums:

Zu früh aufhören: „Menschliches Versagen" ist niemals eine Grundursache. Warum ist der Fehler passiert? Welches System hat ihn ermöglicht?
Eingleisig: Echte Probleme haben oft mehrere Ursachen. Fünf Warums können parallele Ursachenketten übersehen.
Meinungsgetrieben: Ohne Daten könnten Sie „warum?" fragen und Spekulation statt Fakten erhalten.
Schuldzuweisung: Wenn Fünf Warums zu „wer hat es vermasselt?" degeneriert, wird es falsch verwendet.

Fünf Warums funktioniert am besten als Ausgangspunkt, ergänzt durch Daten und mehrere Perspektiven.

3Ishikawa (Fischgräten)-Diagramme

Das Ishikawa-Diagramm, auch Fischgräten- oder Ursache-Wirkungs-Diagramm genannt, hilft dabei, mehrere Ursachenkategorien gleichzeitig zu untersuchen.

Das Problem ist der „Kopf" des Fisches. Hauptursachenkategorien sind die „Gräten". Unterursachen zweigen von jeder Gräte ab.

Gängige Kategorien (die 6 M):

Manpower (Arbeitskraft): Menschen, Fähigkeiten, Schulung
Method (Methode): Prozesse, Verfahren
Machine (Maschine): Tools, Ausrüstung, Systeme
Material: Inputs, Daten, Abhängigkeiten
Measurement (Messung): Metriken, Monitoring, Feedback
Mother Nature (Umwelt): Externe Faktoren, Kontext

Für Software könnten Sie anpassen:

People (Menschen): Fähigkeiten, Kommunikation, Teamstruktur
Process (Prozess): Workflow, Übergaben, Richtlinien
Technology (Technologie): Tools, Infrastruktur, Architektur
Data (Daten): Inputs, State, Abhängigkeiten
Measurement (Messung): Sichtbarkeit, Monitoring, Alerting
Environment (Umgebung): Externe Services, Last, Kontext

Das Diagramm hilft Teams, Ursachen systematisch zu brainstormen, anstatt sich auf die erste Idee zu fixieren. Es zeigt, dass Probleme normalerweise mehrere beitragende Ursachen haben.

Techniken kombinieren

Verwenden Sie Fünf Warums, um tief in jeden Zweig der Fischgräte zu bohren. Die Fischgräte stellt sicher, dass Sie breit erkunden; Fünf Warums stellt sicher, dass Sie tief erkunden. Zusammen sind sie mächtig.

Grundursache gefunden

Vorfall: Deployment-Fehler verursachte 2-stündigen Ausfall. Fünf Warums führten zu: Config nicht getestet → Config separat verwaltet → historische Architekturentscheidung. Fischgräte zeigte: auch kein Deployment-Runbook (Prozess), kein Canary-Prozess (Methode). Alle drei adressiert.

Grundursache übersehen

Vorfall: Deployment-Fehler verursachte 2-stündigen Ausfall. Post-Mortem-Schlussfolgerung: 'Entwickler hätte vorsichtiger sein sollen.' Action Item: 'Beim nächsten Mal vorsichtiger sein.' Problem tritt zwei Wochen später mit einem anderen Entwickler erneut auf.