Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·Practices

Change Failure Rate

// Direkte Antwort

Was sagt die Change Failure Rate aus?

Die Change Failure Rate misst, wie oft ein Deployment zu einem Ausfall oder Rollback führt. Sie ist eine der vier DORA-Metriken und zeigt, wie stabil der Release-Prozess tatsächlich ist — ein Wert unter 5 Prozent gilt als Zeichen eines ausgereiften Teams.

DORA Metrics messen
// Im DetailChange Failure Rate

Die Change Failure Rate (CFR) wird berechnet als Anteil der Deployments, die in Produktion zu einem Service-Beeinträchtigung führen — also einen Rollback, einen Hotfix oder ein Patch erforderlich machen. Die Formel ist bewusst einfach: fehlgeschlagene Deployments geteilt durch alle Deployments im Betrachtungszeitraum. Entscheidend ist eine konsistente Definition davon, was als „Fehler" zählt, damit der Wert über Teams und Zeiträume vergleichbar bleibt.

Die CFR ist eine der vier DORA-Metriken und bildet zusammen mit der Deployment Frequency und der Lead Time for Changes ein Spannungsfeld ab: Wer Tempo und Stabilität gleichzeitig im Blick behält, vermeidet, dass schnelle Releases zulasten der Qualität gehen. Laut DORA-Klassifikation liegen High Performer typischerweise im Bereich von 5 bis 15 Prozent. Die Kennzahl misst nicht die Schuld eines Einzelnen, sondern die Reife des gesamten Release-Prozesses — von Tests über Quality Gates bis zur Deployment-Strategie.

In der Industrie ist die CFR besonders relevant, wenn Software auf Steuerungssysteme, Edge-Geräte oder Maschinen ausgerollt wird, wo ein fehlgeschlagenes Update Produktionsstillstand bedeutet. Ein typischer Stolperstein ist die unsaubere Erfassung: Werden Fehler manuell und unvollständig dokumentiert, sieht die CFR künstlich niedrig aus. Sinnvoll ist es, fehlgeschlagene Deployments automatisch aus Incident-Daten und Rollback-Events abzuleiten, statt sie nachträglich zu schätzen.

// Beispiele aus der Praxis2 Szenarien
/01

Automatisierte CFR-Erfassung im Maschinenbau

Ein Hersteller koppelt seine Deployment-Pipeline an das Incident-System und markiert jedes Deployment automatisch als fehlgeschlagen, wenn innerhalb von 24 Stunden ein Rollback oder Hotfix erfolgt. So entsteht eine belastbare CFR ohne manuelle Pflege.

/02

Quality Gate senkt die Failure Rate

Ein Embedded-Team führt vor dem Produktiv-Deployment automatisierte Hardware-in-the-Loop-Tests als verpflichtendes Quality Gate ein. Die Change Failure Rate sinkt innerhalb von zwei Quartalen von 22 auf unter 10 Prozent.

// Häufige FragenFAQ
Wie wird die Change Failure Rate konkret berechnet?
Man teilt die Anzahl der Deployments, die einen Rollback, Hotfix oder eine Korrektur erforderten, durch die Gesamtzahl aller Deployments im selben Zeitraum. Das Ergebnis wird als Prozentsatz ausgedrückt. Wichtig ist eine einheitliche, dokumentierte Definition davon, was als Fehler gilt.
Was ist ein guter Wert für die Change Failure Rate?
Nach der DORA-Klassifikation liegen leistungsstarke Teams meist zwischen 5 und 15 Prozent. Werte deutlich darüber deuten auf unzureichende Tests, fehlende Quality Gates oder zu große Releases hin. Ein sehr niedriger Wert kann auch auf lückenhafte Erfassung hindeuten.
Wie senkt man die Change Failure Rate, ohne langsamer zu werden?
Kleinere, häufigere Deployments reduzieren das Risiko pro Release, weil weniger Änderungen gleichzeitig wirksam werden. Automatisierte Tests, Canary- oder Blue-Green-Deployments und solide Rollback-Mechanismen senken die Failure Rate, ohne die Deployment Frequency zu drosseln.
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance