Deployment Frequency
Wie der Name bereits suggeriert, bezieht sich die Deployment Frequency auf die Häufigkeit erfolgreicher Software-Releases in die Produktionsumgebung. In anderen Worten: sie misst, wie oft ein Unternehmen Code für eine bestimmte Applikation bereitstellt.
Die Metrik, die sich an der Gesamtzahl der Bereitstellungen pro Tag orientiert, wurde auf Grundlage von Fertigungskonzepten entwickelt, die die Losgrößen von Unternehmen misst und steuert.
Natürlich neigen erfolgreiche Unternehmen dazu, kleinere und dafür häufiger Lieferungen vorzunehmen. Oder auf die DevOps-Welt übertragen: häufigere, aber kleinere Deployments.
Ein Deployment pro Woche ist in den meisten Unternehmen Standard – erfolgreiche Unternehmen deployen Software bis zu 7-mal am Tag. Natürlich unterscheidet sich die Deploymentanzahl je nach Produkt.
Bei mobilen Applikationen, bei denen Kunden das neuste Update herunterladen müssen, werden in der Regel höchstens ein oder zwei Versionen pro Quartal veröffentlicht, während eine SaaS-Lösung mehrmals am Tag deployed werden kann.
| Frage |
Elite Performer |
High Performer |
Medium Performer |
Low Performer |
| Wie häufig deployed Ihr Unternehmen Code in die Produktionsumgebung oder released Code an die Endbenutzer? |
On-Demand (mehrere Deployments am Tag) |
Zwischen einmal pro Tag und einmal pro Woche |
Zwischen einmal pro Woche und einmal pro Monat |
Zwischen einmal pro Monat und einmal alle sechs Monate |
Quelle: 2019 Accelerate State of DevOps, Google
Wenn DevOps-Teams erkennen, dass sie zu den Low Performern bzw. Schlusslichtern gehören, können sie dem gezielt entgegenwirken, indem sie automatisierte Prozesse für das Testen und die Validierung neuen Codes implementieren. Dies verringert die Zeitspanne zwischen Fehlerbehebungen und Bereitstellung.
Lead Time for Changes
Diese Metrik misst die Zeitspanne zwischen dem Eingang der Anfrage und dem Deployment des Codes in die Produktionsumgebung. Lead Time for Changes misst die Geschwindigkeit der Softwarebereitstellung. Es wird genutzt, um ein besseres Verständnis für die Zykluszeiten der DevOps zu erhalten und herauszufinden, wie mit einer steigenden Anzahl an Anfragen umgegangen wird. Je geringer die Lead Time for Changes ist, desto effizienter deployen DevOps-Teams ihren Code.
Zur Berechnung der Lead Time for Changes sind zwei Daten (oder Zeitstempel) erforderlich: Die genaue Eingangszeit der Anfrage sowie die exakte Deploymentzeit. Oder in anderen Worten: die Zeitspanne von Produktbeginn und -abschluss. Die Durchschnittszeit wird als Indikator für die Gesamtperformance verwendet.
| Frage |
Elite Performer |
High Performer |
Medium Performer |
Low Performer |
| Wie lang ist die Zeitspanne zwischen Anfrageneingang und dem erfolgreichen Deployment in die Produktionsumgebung? |
Weniger als ein Tag |
Zwischen einem Tag und einer Woche |
Zwischen einer Woche und einem Monat |
Zwischen einem Monat und einem halben Jahr |
Quelle: 2019 Accelerate State of DevOps, Google
Bei einer hohen Lead Time for Changes können DevOps-Teams mehr automatisierte Deployments einrichten, Prozesse reviewen und Produkte sowie Features in handlichere Einheiten aufteilen.
Mean Time to Recover
Diese Metrik misst die Zeit, die für die Fehlersuche und Reparatur ausgefallener Services verstreicht. Es spielt absolut keine Rolle, wie gut ein DevOps-Team performt – ungeplante Ausfälle oder Incidents kommen immer vor. Und da sich Ausfälle nicht vermeiden lassen, kommt es eben auf die Zeit an, die für die Wiederherstellung eines Systems oder einer Applikation benötigt wird.
Wenn ein Unternehmen eine geringe Mean Time to Recover verweisen kann, fühlt sich die Führungsetage meistens wohler dabei, Innovationen durchzuführen oder experimentierfreudiger zu sein. Dies führt wiederum zu einem Wettbewerbsvorteil und steigert die Geschäftseinnahmen.
Diese Metrik ist wichtig, da sie Engineers als Anreiz dient, robustere Systeme zu entwickeln. Hierfür wird die durchschnittliche Zeit zwischen einer Fehlermeldung sowie deren Behebung verfolgt.
| Frage |
Elite Performer |
High Performer |
Medium Performer |
Low Performer |
| Wie lange dauert die Servicewiederherstellung nach einem Incident, der sich auf die Benutzer auswirkt? |
Weniger als eine Stunde |
Weniger als ein Tag |
Weniger als ein Tag |
Zwischen einer Woche und einem Monat |
Change Failure Rate
Diese Metrik erfasst den Prozentsatz der Änderungen, die an einem Code vorgenommen wurden und zu Incidents, Rollbacks oder Produktionsfehlern jeglicher Art führen. Die Change Failure Rate ist also ein echter Indikator für Qualität und Stabilität, während die vorherigen Metriken (Deployment Frequency und Lead Time for Changes) nicht die Qualität von Software widerspiegeln, sondern lediglich das Tempo der Softwarebereitstellung anzeigen. Laut dem DORA-Report weisen High Performer eine Change Failure Rate von 0% bis 15% auf.
Die Change Failure Rate wird berechnet, indem die Anzahl der beim Deployment auftretenden Fehler gezählt und dann durch die Gesamtzahl aller Deployments geteilt wird. Wenn diese Metrik über einen längeren Zeitraum hinweg verfolgt wird, gibt sie Aufschluss darüber, wie viel Zeit für die Behebung von Fehlern und Bugs im Vergleich zur Bereitstellung von neuem Code aufgewandt wird. Natürlich sollte es das Ziel eines jeden DevOps-Teams sein, diesen Durchschnitt so gering wie möglich zu halten.
| Frage |
Elite Performer |
High Performer |
Medium Performer |
Low Performer |
| Wie viel Prozent der Änderungen am Code führen zu einer Verschlechterung des Services? |
0-15% |
0-15% |
0-15% |
46-60% |
Quelle: 2019 Accelerate State of DevOps, Google
Um einer hohen Change Failure Rate entgegenzuwirken, sollten Teams Fehlern beim Deployment und Verzögerungen vorbeugen, die den kompletten Prozess in die Länge ziehen.
Mehr erfahren
.svg)