Change Failure Rate

Für die Rechnung brauchen Sie zwei Zahlen aus demselben Zeitraum. Die erste ist die Zahl aller Deployments in Produktion. Die zweite ist die Zahl der Deployments, nach denen sofort eingegriffen werden musste, also mit Rollback, Hotfix, Fix Forward oder Patch. Die zweite geteilt durch die erste ergibt die Change Failure Rate (CFR). Die Rechnung selbst ist trivial. Schwierig ist die Definition, welches Deployment als fehlgeschlagen zählt, und die muss feststehen, bevor Sie den ersten Wert erheben. Sonst vergleicht das Team im nächsten Quartal eine andere Zählweise mit der alten.

Im DORA-Modell (DevOps Research and Assessment) gehört die CFR zur Instabilität der Software-Delivery. Seit dem Report 2024 steht neben ihr die Rework Rate. Sie zählt die ungeplanten Deployments, die nur stattfinden, weil ein Fehler in Produktion behoben werden muss. Die CFR fragt, wie oft ein Release scheitert, die Rework Rate, wie viel Nacharbeit das auslöst. Beide hängen laut DORA eng zusammen. Allein gelesen führt die CFR in die Irre: Ein Team, das zweimal im Jahr ausliefert, kann fast fehlerfrei sein und trotzdem jede Anforderung monatelang liegen lassen. Deshalb gehört die Kennzahl immer neben Deployment Frequency und Lead Time for Changes.

In der Industrie wiegt ein fehlgeschlagenes Deployment schwerer als im Webshop. Geht ein Update auf eine Steuerung oder ein Edge-Gateway schief, steht im ungünstigen Fall die Linie, und der Schichtleiter ruft an, bevor das Monitoring anschlägt. Hier lohnt eine zweite Zahl neben der CFR: die Releases, die ein Quality Gate wie der HiL-Prüfstand vor dem Rollout zurückgewiesen hat. Sie gehören nicht in die CFR, weil sie Produktion nie erreicht haben. Getrennt ausgewiesen zeigen sie aber, wie viele Fehler das Gate abfängt und wie viele erst an der Anlage auffallen.

Der häufigste Messfehler ist eine CFR, die zu gut aussieht. Wer fehlgeschlagene Deployments von Hand in ein Wiki einträgt, vergisst den stillen Hotfix am Freitagnachmittag, und nach drei Monaten steht dort ein Wert von 2 Prozent, den niemand glaubt. Oft rekonstruiert das Team die ersten Zahlen aus dem Gedächtnis des Release-Managers, weil schlicht keine Daten vorliegen. Belastbar wird der Wert, sobald die Pipeline Rollback-Events liefert, das Incident-System jeden Vorfall mit einer Deployment-ID verknüpft und ein Skript beides zuordnet.