Vier Metriken, die zeigen, ob euer Delivery-Prozess wirklich besser wird

Ihr deployed in letzter Zeit häufiger. Das Team fühlt sich produktiv. Die Pipelines sind grün. Aber wenn du dir die Produktionsincidents ansiehst, stimmt etwas nicht. Deployments gehen schneller, trotzdem bricht bei jedem zweiten Release etwas, und die Recovery dauert Stunden. Werdet ihr wirklich besser – oder bewegt ihr euch nur schneller in die falsche Richtung?

Das ist ein blinder Fleck in vielen Engineering-Teams. Ohne eine Möglichkeit, die Delivery-Reife zu messen, verwechselt man leicht Aktivität mit Fortschritt. Es fühlt sich gut an, täglich auszuliefern, aber wenn jedes Deployment hohes Risiko und langsame Recovery bedeutet, seid ihr noch nicht reif. Ihr seid nur beschäftigt.

Die gute Nachricht: Delivery-Reife zu messen, erfordert keine teuren Tools oder komplexen Dashboards. Es gibt vier Metriken, die die Industrie über Jahre hinweg validiert hat. Sie stammen aus den State-of-DevOps-Reports von DORA (DevOps Research and Assessment) und werden von Tausenden Teams genutzt, um zu verstehen, wo sie stehen und was sie als Nächstes verbessern sollten.

Deployment-Frequenz: Wie oft liefert ihr aus?

Die Deployment-Frequenz misst, wie oft euer Team Änderungen in die Produktion bringt. Das ist das sichtbarste Zeichen für Delivery-Fähigkeit. Teams, die einmal im Monat releasen, arbeiten völlig anders als Teams, die mehrmals täglich deployen.

Bei niedriger Deployment-Frequenz ist jedes Release tendenziell groß. Ein ganzer Monat Änderungen geht auf einmal raus. Das bedeutet höheres Risiko, schwierigeres Debugging und längere Feedback-Schleifen. Bei hoher Frequenz ist jede Änderung klein. Ein einzelnes Feature, ein Bugfix oder eine Konfigurationsänderung geht unabhängig raus. Wenn etwas kaputtgeht, weißt du genau, was es verursacht hat.

Hohe Deployment-Frequenz geht nicht um Geschwindigkeit um der Geschwindigkeit willen. Es geht darum, die Größe jeder Änderung zu reduzieren. Kleinere Änderungen sind einfacher zu reviewen, einfacher zu testen und einfacher zurückzurollen. Sie geben dir auch schnelleres Feedback von Nutzern und Monitoring-Systemen.

Wenn dein Team weniger als einmal pro Woche deployed, frag dich zuerst, was häufigere Releases blockiert. Sind es manuelle Freigabeprozesse? Lange Testzyklen? Angst vor Fehlern? Die Antwort zeigt dir den nächsten Engpass.

Lead Time für Änderungen: Vom Commit bis zur Produktion

Die Lead Time misst, wie lange es dauert, bis eine Code-Änderung vom Commit bis zur Ausführung in der Produktion gelangt. Das ist etwas anderes als die Deployment-Frequenz. Du kannst wöchentlich deployen, aber jede Änderung kann tagelang im Review liegen, bevor sie gemerged wird.

Eine lange Lead Time bedeutet meist, dass es Wartepunkte in eurer Pipeline gibt. Das Code-Review dauert zu lange. Die CI-Pipeline ist langsam. Es gibt manuelle Gates, die eine Freigabe für das Deployment erfordern. Jeder Wartepunkt fügt Stunden oder Tage zum Delivery-Zyklus hinzu.

In reifen Teams wird die Lead Time in Stunden oder Minuten gemessen. Ein Entwickler schreibt Code, pusht ihn, automatisierte Checks laufen, und die Änderung ist noch am selben Tag in der Produktion. Das bedeutet nicht, dass die Qualität leidet. Es bedeutet, dass die Qualitätschecks automatisiert und schnell sind.

Wenn deine Lead Time in Wochen gemessen wird, schau dir an, wo die Zeit tatsächlich verbracht wird. Wartet sie auf ein Review? Wartet sie auf Tests? Wartet sie auf die Deployment-Freigabe? Jeder Wartepunkt ist ein Kandidat für Automatisierung oder Prozessänderung.

Change Failure Rate: Wie oft verursachen Deployments Probleme?

Diese Metrik balanciert die ersten beiden aus. Hohe Deployment-Frequenz und schnelle Lead Time bedeuten nichts, wenn jedes dritte Deployment die Produktion lahmlegt. Die Change Failure Rate misst den Prozentsatz der Deployments, die eine Verschlechterung oder einen Ausfall verursachen.

Eine niedrige Change Failure Rate ist ein Zeichen dafür, dass eure Test-, Review- und Deployment-Strategien funktionieren. Änderungen werden validiert, bevor sie in die Produktion gelangen. Deployment-Strategien wie Canary-Releases oder Feature Flags reduzieren den Schadensradius von Fehlern.

Eine hohe Change Failure Rate bedeutet, dass etwas mit eurem Qualitätsprozess nicht stimmt. Vielleicht fangen die Tests keine echten Probleme. Vielleicht sind die Deployments zu groß. Vielleicht unterscheidet sich die Produktionsumgebung erheblich vom Staging.

Das Ziel ist nicht null Fehler. Das ist für die meisten Teams unrealistisch. Aber die Fehlerrate sollte niedrig genug sein, dass ihr eurem Deployment-Prozess vertraut. Wenn ihr jedes Mal nervös seid, wenn ihr deployed, ist eure Change Failure Rate zu hoch.

Time to Restore: Wie schnell könnt ihr wiederherstellen?

Wenn doch etwas schiefgeht, wie lange dauert es, bis alles wieder normal läuft? Die Time to Restore misst die Dauer von der Erkennung eines Fehlers bis zur vollständigen Wiederherstellung des Systems.

Langsame Recovery ist oft ein Zeichen von mangelnder Vorbereitung. Das Team hat keine klare Rollback-Prozedur. Das Rollback selbst dauert zu lange, weil Datenbank-Migrationen schwer rückgängig zu machen sind. Oder das Team muss manuell eine frühere Version neu bauen und deployen.

Schnelle Recovery kommt von Vorbereitung. Automatisierte Rollback-Skripte. Feature Flags, mit denen du problematische Features deaktivieren kannst, ohne neu zu deployen. Deployment-Strategien, die ein schrittweises Rollback ermöglichen. Klare Runbooks, die dem diensthabenden Engineer genau sagen, was zu tun ist.

Wenn eure Recovery-Zeit in Stunden oder Tagen gemessen wird, dokumentiert zunächst die häufigsten Fehlerszenarien und bereitet für jedes automatisierte Recovery-Schritte vor.

Wie diese Metriken zusammenspielen

Die vier Metriken sind nicht unabhängig. Ein Team, das häufig deployed, aber eine hohe Fehlerrate hat, ist nicht reif. Ein Team, das eine schnelle Lead Time hat, aber Tage für die Recovery braucht, ist nicht reif. Echte Delivery-Reife bedeutet, bei allen vier Metriken gleichzeitig gut abzuschneiden.

So sieht ein reifes Team aus:

Das folgende Diagramm zeigt, wie die vier Metriken zusammenhängen und sich gegenseitig verstärken.

• Deployments erfolgen mehrmals täglich.
• Lead Time wird in Stunden gemessen.
• Change Failure Rate ist niedrig, deutlich unter 15 Prozent.
• Recovery-Zeit wird in Minuten gemessen.

So sieht ein sich verbesserndes Team aus:

• Deployments erfolgen wöchentlich statt monatlich.
• Lead Time ist von Wochen auf Tage gesunken.
• Fehlerrate ist stabil oder sinkt.
• Recovery-Zeit ist von Tagen auf Stunden gesunken.

Die Richtung ist wichtiger als die absoluten Zahlen. Jedes Team fängt irgendwo an. Der Punkt ist: Messt, identifiziert die schwächste Metrik und verbessert sie.

Ein einfacher Weg, mit dem Messen zu beginnen

Ihr braucht keine spezielle Plattform, um diese Metriken zu tracken. Fangt mit einem einfachen Log an. Notiert für jedes Deployment:

• Datum und Uhrzeit des Deployments
• Ob das Deployment Probleme verursacht hat
• Wie lange die Recovery gedauert hat, falls es ein Problem gab
• Die Zeit zwischen Commit und Deployment

Nach ein paar Wochen schaut euch die Muster an. Welche Metrik ist die schwächste? Das ist euer Startpunkt. Konzentriert euch darauf, diese eine Metrik zu verbessern, bevor ihr zur nächsten übergeht.

Das eigentliche Ziel sind nicht die Zahlen

Diese Metriken zu messen, geht nicht darum, willkürliche Ziele zu erreichen. Es geht darum, die Delivery-Fähigkeit eures Teams zu verstehen und fundierte Entscheidungen darüber zu treffen, was als Nächstes verbessert werden soll. Die Zahlen geben euch ein Signal. Die Verbesserung gibt euch Vertrauen.

Ein Team, das häufig deployed, schnell wiederherstellt und selten etwas kaputtmacht, ist ein Team, das auf Nutzerbedürfnisse reagieren, Bugs schnell beheben und ohne Angst experimentieren kann. Das ist das eigentliche Ergebnis von Delivery-Reife. Die Metriken sind nur die Anzeigetafel.