Damit jedem klar ist, warum es hier geht, kommt hier der Klassiker:
(c) DevOps Fundamentals, Curse Book, Seite 195 „Messen und Verbessern.“
RICHTIGE KENNZAHLEN AUSWÄHLEN
Angenommen Ihr Betrieb oder das Team, ist in einem „kriegs-Szenario.“ (überleben ist wichtig) nun habt Ihr 1000 Flieger (Bomber) an die Fron geschickt und von den 1000 kommen nur 300 überlebende zurück, jeder von den 300 weist einen, nähe zu identischen, Beschädigung-muster auf.
Verzerrung durch Fokus auf die Überlebenden
Bild 2: Das zurückgekehrte Flugzeug
Analyse:
Sie haben 100% gegeben und haben 70% Verlust, wobei 30% der Überlebenden zur Analyse zur Verfügung stehen.
FATAL: „OK, na, wenn es da weh tut, wo die löcher sind dann verstärken wir genau diese Stellen und machen uns damit Stärker“ !
Clever: OK, wenn die 30% hier Beschädigung aufweist, jedoch aber diese Beschädigung nicht so gravierend ist, und ein Rückflug war noch möglich, dann müssen wir genau die Stellen verstärken die keine Beschädigung aufweisen (Fahrer-Kabine etc., wird der „Fahrer“ getroffen: stürzt in, folge das Flugzeug ab?)
Erkenntnis
Das Messen bzw., das Beobachten der Kennzahlen ist enorm wichtig, welches nähe zu 100% die eigene Qualität spiegeln kann.
Was b.z.w welche Kennzahlen sollte ich wählen?
Na ja das liegt auf der Hand, der Unsicherheit gegenüber kann eine „Betcher–Strategie“ gefahren werden. Was heißt das?
Wenn es mal kracht „und das macht es oft“, wäre es nicht vom Vorteil in dem verlauf einige „Anomalien“ zu entdecken? (z.B. wenn das Storage-System langsame latenz- Zeit aufweist, würde hier die Zeit deutlich Ansteigen.) Mann kann sie (die Kennzahlen, als verlauf, bzw. zustand zum Zeitpunkt x jede x Sekunde in der Datenbank notieren) alle erstmal in für die Analyse Sammeln.