Früh in meiner Karriere habe ich nach Bauchgefühl gedehuggt. Etwas ging kaputt, ich starrte auf den Code, änderte etwas, deployte neu, hoffte. Manchmal funktionierte es. Oft machte es die Sache schlimmer.
Wenn du Systeme baust, von denen Menschen abhängen, kannst du dir Raten nicht leisten. Ich habe ein Framework für systematisches Debuggen entwickelt. Es ist nicht glamourös, aber es funktioniert jedes Mal.
Das Framework: ISOLATE
I — Identifiziere das Symptom (nicht die Ursache) S — Schätze den Schadensradius ein (Scope the blast radius) O — Beobachte die Daten (Observe the data: Logs, Metriken, Traces) L — Liste Hypothesen auf (List hypotheses: mindestens 3) A — Bewerte jede Hypothese mit Beweisen (Assess each hypothesis with evidence) T — Teste den Fix isoliert (Test the fix in isolation) E — Erkläre, was passiert ist (Explain what happened: Postmortem)
Lass mich ein reales Beispiel durchgehen.
Realer Fall: Dashboard lädt 30 Sekunden
I — Identifiziere das Symptom. Nutzer melden, dass das Qualitäts-Dashboard 30+ Sekunden zum Laden braucht. Lokal lädt es in 2 Sekunden. Nur in Produktion.
Springe noch nicht zu "es ist ein Datenbankproblem" oder "es ist ein Netzwerkproblem". Beschreibe einfach, was du siehst.
S — Schätze den Schadensradius ein. Sind es alle Nutzer oder bestimmte? Alle Browser? Wann hat es angefangen? Korreliert es mit einem Deploy?
In diesem Fall: alle Nutzer, begann vor 3 Tagen, kein Deploy in diesem Zeitfenster. Das schließt "wir haben kaputten Code ausgeliefert" als Ursache aus.
O — Beobachte die Daten.
\\
