Änderungsfehlerrate (Change Failure Rate, CFR)

Was ist die Änderungsfehlerrate?

Die Änderungsfehlerrate (Change Failure Rate, CFR) ist eine Kennzahl für die Softwareentwicklungsleistung, die den Prozentsatz der Softwarelieferungen misst, die nach der Freigabe für die Produktion nachbearbeitet werden mussten. Niedrigere CFR-Werte weisen auf weniger Probleme in der Entwicklungs- und Testphase des Arbeitszyklus hin.

Softwareteams verwenden Entwicklungsmethoden wie Agile und DevOps, um Produkte in häufigen und kontinuierlichen Iterationszyklen zu entwickeln. Jede neue Softwareversion bringt Änderungen wie neue Features und Funktionen, Leistungsverbesserungen und Fehlerbehebungen für eine höhere Zuverlässigkeit mit sich.

Nicht alle Änderungen, die das Softwareteam vornimmt, sind erfolgreich. Änderungen können neue Softwarefehler, sogenannte Bugs, verursachen, die beim Testen nicht entdeckt wurden. Ein neu geschriebener Teil der Software kann zu Inkompatibilitäten mit Abhängigkeiten innerhalb des Produkts führen. Eine Version funktioniert möglicherweise korrekt, erfüllt jedoch nicht die Erwartungen der Kunden. Diese Situationen erfordern mehr Zeit für die Softwareentwicklung, um sie zu bewerten und zu beheben. Ein Änderungsfehler ist jeder Vorfall, der eine Korrekturmaßnahme wie einen Patch, einen Code-Rollback oder einen Hotfix erfordert.

Die Änderungsfehlerrate ist der Anteil oder Prozentsatz der Releases in der Produktion, die mit Fehlervorfällen verbunden sind.

Die CFR-Metrik wird von der Gruppe DevOps Research and Assessment (DORA) unterstützt. Unternehmen können die CFR in Verbindung mit anderen von DORA empfohlenen Metriken verwenden: Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen und durchschnittliche Wiederherstellungszeit. In Verbindung mit anderen relevanten Metriken kann CFR Aufschluss über die Effizienz und Effektivität der Softwareentwicklungsprozesse eines Unternehmens geben.

So berechnen Sie die Änderungsfehlerrate

Die CFR wird als Verhältnis der Anzahl der Änderungsfehler in einem bestimmten Zeitraum zur Gesamtzahl der Bereitstellungen im gleichen Zeitraum berechnet. Das ergibt ein Verhältnis zwischen null und eins. CFR-Benutzer multiplizieren die Zahl in der Regel mit 100, um einen Prozentsatz zu erhalten.

Beispiel für die Berechnung der CFR

Ein DevOps-Team gibt in einem Monat 30 Änderungen in die Produktion frei. Zehn dieser Änderungen mussten nach der Freigabe für die Produktion bewusst behoben werden. Die CFR-Quote beträgt 10/30, was 0,33 ergibt. Das Team verfolgt die CFR als Prozentsatz und berechnet daher (10/30) x 100, um 33 Prozent zu erhalten.

CFR-Genauigkeit

Der Schlüssel zur erfolgreichen CFR-Verfolgung ist die richtige Datenerfassung. Die Berechnung ist einfach, aber es gilt die Redewendung Garbage in, garbage out (Müll rein, Müll raus). Entwicklungsteams müssen die Gesamtzahl der Bereitstellungen zählen und dann Vorfälle fair und konsistent verfolgen und jeder dieser Bereitstellungen zuordnen.

Die Datenerfassung ist anfällig für Fehler und Versäumnisse, die die Ergebnisse verfälschen können. Häufige CFR-Fehler sind unter anderem:

• Lieferung als Bereitstellung gezählt: Builds, die geliefert, aber nicht bereitgestellt wurden, sollten nicht in dieser Leistungskennzahl berücksichtigt werden. Die Entscheidung, einen Build nicht bereitzustellen, kann viele Gründe haben, zum Beispiel dass das Unternehmen eine neue Anforderung für eine Funktion hinzugefügt hat. Etwas, das nicht bereitgestellt wurde, kann auch nicht bei der Bereitstellung fehlschlagen.
• Einbeziehung externer Vorfälle: Vorfälle wie Netzwerkausfälle, Hardwareausfälle oder Fehler in einem Datenbankserver oder anderen unterstützenden Diensten, die nicht mit dem Build in Zusammenhang stehen, sollten nicht als Änderungsfehler gezählt werden.
• Inkonsistenter oder unrealistischer Umfang von Vorfällen: Vorfälle können eine Reihe von Problemen umfassen, zum Beispiel Leistungs- oder Stabilitätsbeeinträchtigungen, und nicht nur vollständige Ausfälle. Teams müssen Anwendungsleistungsüberwachung und andere relevante Tools verwenden, um nicht katastrophale Vorfälle zu erkennen und nur relevante Vorfälle in die CFR-Berechnung einzubeziehen.

Verwendung von CFR

Sobald Sie einen CFR-Wert ermittelt haben, können die Projektleiter aus den Bereichen Business und Software Engineering diesen bewerten und interpretieren. Änderungen an der Produktionsanwendung und der IT-Umgebung erfordern Entwicklungs- und Testzeit sowie andere Mitarbeiterressourcen. Änderungsfehler bedeuten, dass das Unternehmen mehr Zeit für die Behebung der Probleme aufwenden muss.

Niedrige und fallende CFR-Werte sind wünschenswert, während hohe CFR-Werte und steigende CFR-Trends unerwünscht sind. Im Allgemeinen liegt ein niedriger CFR zwischen null und 15 Prozent. Ein Wert in diesem Bereich weist auf eine hohe Softwareentwicklungs- und -bereitstellungsleistung hin. Ein CFR zwischen 16 und 30 Prozent entspricht einer mittleren Leistung. Höhere CFR-Werte über 30 Prozent stehen für eine geringe Leistung, an deren Verbesserung die Teams arbeiten sollten.

Softwareentwicklungsunternehmen sollten die Verfolgung der CFR als Kennzahl in Betracht ziehen, wenn sie die Bereitstellungsgeschwindigkeit erhöhen, die Vorlaufzeit verkürzen und mehr Builds schneller liefern möchten. Unternehmen, die noch am Anfang ihrer DevOps-Reise stehen, haben in der Regel zahlreiche Möglichkeiten, die DevOps-Codequalität, das Testen und die Workflows zu verbessern. Diese Unternehmen können durch die Verfolgung der CFR Einblicke in die DevOps-Reife gewinnen.

Der CFR ist auch in größeren und etablierteren Softwareunternehmen mit vielen Projekten und einer Vielzahl von Teams, darunter interne Teams, Auftragnehmer und Offshore-Anbieter, von großem Wert. Bei großen, komplexen Softwareunternehmen können schon wenige Prozentpunkte einen erheblichen Zeit- und Kostenunterschied ausmachen.

Das Problem mit einer CFR von null

Das theoretische Ideal für CFR ist Null – keine Fehler bei der Bereitstellung eines Builds in der Produktion. Obwohl Unternehmen bestrebt sind, CFR zu reduzieren, ist es unwahrscheinlich, dass sie null CFR erreichen. Änderungsfehler sind wie die Defekte, die sie verursachen: praktisch unvermeidbar. Entwickler machen Fehler, und Test-Tools und -strategien sind nicht perfekt. Das Streben nach null CFR und dessen Aufrechterhaltung wäre für das Unternehmen kostspieliger und problematischer als die Verwaltung eines realistischen CFR-Bereichs.

Verlangen Sie keinen CFR-Wert von null. Legen Sie stattdessen eine akzeptable Quote für Änderungsfehler fest, die das Unternehmen erreichen und als Benchmark beibehalten kann. CFR-Werte von 15 Prozent oder weniger weisen in der Regel auf einen effektiven und effizienten Entwicklungsbetrieb hin. Wenn die CFR-Werte auf oder unter diesem Niveau bleiben, gibt das Unternehmen ein akzeptables Maß an Ressourcen für die Behebung von Fehlern aus. Oberhalb dieses Niveaus kann das Unternehmen eine übermäßige CFR objektiv untersuchen und korrigieren.

Leistungskennzahlen im Zusammenhang mit CFR

CFR wird selten allein verwendet und häufig zusammen mit anderen DORA-Kennzahlen wie der Bereitstellungshäufigkeit, der Vorlaufzeit für Änderungen und der mittleren Zeit bis zur Wiederherstellung von Diensten verfolgt. Eine Kombination verschiedener Leistungskennzahlen kann nützliche Einblicke in die Effizienz der Softwareentwicklung liefern. Hier finden Sie eine kurze Erläuterung, wie die einzelnen von DORA empfohlenen Kennzahlen mit CFR zusammenwirken:

• Bereitstellungshäufigkeit: Deployment Frequency (DF) ist ein Maß für die Entwicklungsgeschwindigkeit, das erfasst, wie schnell das Unternehmen neue Builds veröffentlicht. Eine Senkung der CFR bei gleichzeitiger Erhöhung der DF kann darauf hindeuten, dass das Team seine Entwicklungseffizienz verbessert und effektivere Arbeitsabläufe implementiert. Dies kann zu niedrigeren Entwicklungskosten oder höherer Produktivität bei gleichen Kosten führen. Im Gegensatz dazu kann eine Erhöhung der DF bei gleichzeitiger Erhöhung der CFR auf unzureichende Tests oder schlechte Codequalität in der Eile zur Produktion hindeuten.
• Durchlaufzeit: Lead Time (LT) zeigt, wie schnell das Unternehmen von einem Code-Commit bis zur Bereitstellung gelangen kann. Eine Senkung der CFR bei gleichzeitiger Verkürzung der LT deutet ebenfalls auf eine bessere Entwicklungseffizienz und bessere Workflows hin, da die Fertigstellung jedes Builds weniger Zeit in Anspruch nimmt. Eine Verkürzung der LT bei steigender CFR kann auch auf Probleme bei den Tools und Workflows hindeuten.
• Durchschnittliche Wiederherstellungszeit: Die Mean Time to Restore (MTTR) misst die Zeit bis zur Behebung eines Problems. Sie ist die Zeit von der Erkennung eines Vorfalls bis zur Wiederherstellung des Normalzustands. Die MTTR steht in direktem Zusammenhang mit der CFR. Eine sinkende MTTR ist ein Indikator für die Kompetenz des Teams im Incident Management.

Reduzierung der Änderungsfehlerrate      

Softwareentwicklungsunternehmen verfügen über zahlreiche Strategien zur Reduzierung der CFR:

• Arbeiten Sie in kleinen Schritten und schnell: Iterative Softwareentwicklungsparadigmen wie DevOps zielen auf kleine und häufige Änderungen ab. Durch kurze Zyklen und einen begrenzten Umfang werden Änderungen minimiert, Testziele klar definiert und eine effektive Problemverfolgung und -behebung ermöglicht. Wenn Sie nur einen Teil ändern und der Build fehlschlägt, ist es leicht zu erkennen, wo das Problem liegt.
• Verbessern Sie die Codequalität: Verwenden Sie Tools und Richtlinien, um die Art und Weise zu verwalten, wie Software entworfen und erstellt wird. Code-Checker können automatisch Stil-, Syntax- und andere Qualitätsprobleme identifizieren, oft innerhalb der IDE und des Compilers. Die Behebung von Codequalitätsproblemen ist in der Regel Teil eines Änderungsmanagementprozesses.
• Investieren Sie in Tests: Die Tests sollten den Änderungen im Build angemessen sein. Wenn das Testen unzureichend ist oder die Codeänderungen nicht ordnungsgemäß überprüft werden, gibt es keine Möglichkeit, die Integrität dieser Änderungen zu validieren. Unvollständige Tests führen zu unentdeckten Fehlern in der Produktion.
• Verbessern Sie die Bug-Berichterstattung: Verwenden Sie Tools und Verfahren, um Bereitstellungsfehler zu verfolgen. Sammeln Sie Informationen über die Art jedes Fehlers und seine Auswirkungen. Dieser Kontext kann bei der Behebung helfen und Aufschluss über die Ursachen geben. Das Verständnis, warum Fehler aufgetreten sind, kann zu einer besseren Codierung und zu besseren Tests in zukünftigen Releases führen.
• Nutzen Sie Code-Reviews: Automatisierung hat ihre Grenzen. Führen Sie gründliche Code-Reviews durch Ihre Mitarbeiter durch. Mergen Sie Pull-Anfragen nicht ohne eine zufriedenstellende Überprüfung. Das Pullen von Code, das Vornehmen von Änderungen und das anschließende Mergen dieser Änderungen ohne angemessene Überprüfung kann zu Fehlern führen, die zu Bereitstellungsfehlern führen.

Tools zur Verwaltung der Fehlerquote bei Änderungen

DevOps-Tool-Ketten umfassen in der Regel die Möglichkeit, Metriken zur Softwareentwicklung und -bereitstellung zu verfolgen, mit denen Unternehmen die CFR messen. Zu den Software-Lifecycle-Tools, die CFR berücksichtigen, gehören die folgenden:

• DX, eine Plattform zur Verfolgung der Produktivität von Entwicklern und Softwareteams
• Hatica, ein Projektmanagement- und Analyse-Tool für Entwicklungsteams
• Jit Open ASPM Platform, das automatisierte Sicherheitstests während der Entwicklung verfolgt
• LaunchDarkly, ein Release-Management-Tool, das Feature-Flags zur Bereitstellung von Änderungen verwendet
• Metridev, eine Plattform zur Verfolgung von Metriken für Entwicklungsteams und Führungskräfte
• Opsera Unified Insights, ein Tool zur Verfolgung von Metriken über die CI/CD-Tool-Chain
• Swarmia, ein Tool zur Produktivitätsverfolgung für Softwareteams mit Berichterstellung
• Waydev, ein Analyse-Tool zur Verfolgung von Entwicklungsinitiativen

Entwicklungsgeschichte der Änderungsfehlerrate

Die Geschichte der CFR ist eng mit der Entstehung von DORA verbunden. DORA begann als Unternehmen, das die Best Practices und Ergebnisse von DevOps mit dem Erreichen von Geschäftszielen in Beziehung setzen wollte.

Das DORA-Team identifizierte vier Metriken, die DevOps eng mit der Unternehmensleistung korrelieren: DF, Change LT, CFR und MTTR. Darüber hinaus stellte das DORA-Team fest, dass Trunk-basierte Entwicklungsansätze bei leistungsstarken Teams vorherrschend waren. Trunk-basierte Entwicklung ist eine Versionierungspraxis, bei der kleine, häufige Updates in einen zentralen Trunk oder Hauptzweig zusammengeführt werden.

DORA veröffentlichte seine ersten Ergebnisse im 2014 State of DevOps Report. DORA publiziert regelmäßig Jahresberichte und andere Leitfäden.

Google hat DORA im Dezember 2018 übernommen. DORA ist weiterhin als Forschungsunternehmen tätig, das sich mit der Analyse von Softwarebereitstellung und Unternehmensleistung befasst.