Der ultimative Guide

DORA Metrics

Was sind DORA Metrics und wofür brauchen wir sie? In diesem Guide erfahren Sie, wie Sie die DevOps-Performance in Verbindung mit Value Stream Management messen und verbessern können.

Einleitung

Durch die digitale Transformation entwickelt sich jedes Unternehmen unweigerlich zu einem Softwareunternehmen – unabhängig davon, in welcher Branche es agiert. Unternehmen müssen sich viel schneller an die sich ändernden Bedürfnisse ihrer Kunden anpassen und ihnen gleichzeitig noch einen stabilen Service bieten. Um all diesen Anforderungen vollumfänglich gerecht zu werden, müssen sich DevOps-Teams kontinuierlich verbessern.

DORA Metrics und Flow Metrics nehmen sich all dieser Anforderungen an, indem sie objektive Daten liefern, mit denen die Performance der Software-Delivery-Teams gemessen und Produktverbesserungen angekurbelt werden.

In den nächsten Abschnitten finden Sie heraus, was genau sich hinter diesen Metriken verbirgt und wie sie Ihnen beim Value Stream Management helfen können.

Was sind DORA Metrics?

DevOps-Teams nutzen DevOps-Metriken, um ihre Performance zu messen und herauszufinden, ob sie zu den Schlusslichtern (Low Performer) oder Spitzenreitern (Elite Performer) innerhalb ihrer Entwicklungsorganisation gehören. Die vier genutzten Metriken lauten: Deployment Frequency (DF), Lead Time for Changes (LT), Mean Time to Recovery (MTTR) und Change Failure Rate (CFR).

Metric Erklärung
Deployment Frequency Häufigkeit der Deployments in die Produktionsumgebung
Lead Time for Changes Zeitraum zwischen dem Eingang der Anfrage und dem Deployment in die Produktionsumgebung
Mean Time to Recovery Prozentzahl aller Deployments, die Ausfälle verursachen
Change Failure Rate Reparaturzeit nach Auftreten eines Ausfalls, der durch Hotfixes seitens der Entwickler verursacht wurde

Die Abkürzung „DORA“ steht für The DevOps Research and Assessment Team. Diese Google-Forschungsgruppe hat ein siebenjähriges Forschungsprojekt durchgeführt, in dem DevOps-Praktiken und -Capabilities eingehend analysiert wurden. Als Forschungsergebnis konnte die Gruppe vier wichtige Metriken ausmachen, mit denen die Softwareentwicklung und Bereitstellungsperformance gemessen werden können.

Dies hat die Arbeitsweise von DevOps-Teams revolutioniert, da diese Metriken Transparenz schaffen und handfeste Daten liefern, die als Grundlage für Verbesserungen und Entscheidungen dienen können.

Für die Erstellung dieses nützlichen DevOps-Leitfadens hat die Google-Forschungsgruppe Daten von mehr als 32.000 internationalen Fachleuten in diesem Bereich analysiert. Neben dem offiziellen DevOps-Bericht veröffentlichte die Gruppe auch ein ROI-White Paper zur DevOps-Transformation sowie das Buch „Accelerate: The Science of LeanSoftware and DevOps: Building and Scaling High Performing Technology Organizations“, das von Nicole Forsgren (DORA-Teamlead) mitverfasst wurde.

Im nächsten Abschnitt wird genauer auf die vier DORA Metrics eingegangen und erklärt, welchen Nutzen sie dem Value Stream Management liefern.

Gratis Poster

17 Metriken für bessere Software

Dieses Poster gibt Ihnen einen detaillierten Einblick in die Metriken, mit denen DevOps-Teams, CTOs, Produkt-Manager und Engineering Leaders ihre Entwicklungseffizienz steigern und bessere Software bauen können.

Kostenlos herunterladen
Poster: 17 Metriken für bessere Software

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öffentlich, 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.

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.

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
20 Fragen, die Sie mit einem Microservice-Katalog beantworten können

Poster

20 Fragen, die Sie mit einem Microservice-Katalog beantworten können

In diesem Poster werden die 20 wichtigsten Fragen angeführt, die Sie mit einem Microservice-Katalog problemlos beantworten können.

Microservices @ LeanIX - then, now and tomorrow

Video

Microservices @ LeanIX - then, now and tomorrow

Live Recording - EA Connect Day 2020 

Per Bernhardt - Staff Software Engineer - LeanIX

 

Maximize the Development Efficiency of Your Microservices Landscape with LeanIX

Webinar

Maximize the Development Efficiency of Your Microservices Landscape with..

Watch this on-demand webinar hosted by The Open Group, where LeanIX shares insights on how we can help bring order and clarity to your complex microservices architecture.

Efficiently Navigate your Microservices with LeanIX

Webinar

Efficiently Navigate your Microservices with LeanIX

Watch this interview-style webinar on how to build reliable software using a microservice catalog - including a product demo

DORA Metrics: Die Vorteile

Warum sollte also jedes DevOps-Teams auf DORA Metrics zurückgreifen? Die Antwort ist ziemlich einfach: Wenn es keine Daten gibt, die die Performance erfassen, ist es im Grunde genommen unmöglich, Verbesserungen vorzunehmen.

DORA Metrics brechen abstrakte Prozesse in der Softwareentwicklung und -bereitstellung auf und machen sie greifbarer und transparenter. So können Engineering Leads konkrete Schritte zur Optimierung von Prozessen unternehmen und den Wert der Softwareentwicklung steigern.

Nachfolgend finden Sie einen Überblick über die überzeugendsten Vorteile von DORA Metrics.

Entscheidungsfindung

Unternehmen, die ihren Entwicklungs- und Bereitstellungsprozess rationalisieren, steigern den Mehrwert der von ihnen entwickelten Software und sind langfristig auch erfolgreicher. Indem die Performance mithilfe der DORA Metrics verfolgt wird, können DevOps-Teams Trends ermitteln, die die Grundlage für fundierte Entscheidungen bilden und dadurch positive Veränderungen bewirken.

Schaffung von Mehrwert

In den letzten Jahren ist Value Stream Management zu einem wichtigen Bestandteil der Softwareentwicklung geworden. In diesem Zusammenhang spielen DORA Metrics eine beachtliche Rolle, da sie zeigen, welcher Mehrwert den Kunden überhaupt geliefert wird und welches Performance-Niveau erforderlich ist, um die gewünschten Geschäftsergebnisse zu erreichen. Sobald DevOps-Teams sich dieser Metriken bedienen, können sie in kürzester Zeit einen Zuwachs an generiertem Mehrwert feststellen.

Erfolgszyklus

Wenn Performance gemessen wird, ist die Wahrscheinlichkeit groß, dass sich das Verhalten innerhalb Ihrer Entwicklungsorganisation verändert. Personen, die sich für eine bestimmte Metrik verantwortlich fühlen, versuchen alles in ihrer Macht stehende zu tun, um diese Metrik auf ihrer Seite zu verbessern. Obwohl das in anderen Kontexten eine verzerrende Wirkung nach sich ziehen kann, ist dies genau der Effekt, der bei DevOps gewünscht ist. Es hilft, schwerfälligen Prozessen ein Ende zu bereiten und Ineffizienzen zu reduzieren.

Webinar

Schaffen Sie Transparenz über Ihre Microservices

Erfahren Sie, wie Sie autonomen Teams mehr Freiraum bieten können, während Sie gleichzeitig Themen wie Governance Rechnung tragen und eine schnelle Softwareentwicklung durch die Automatisierung der Microservices-Entdeckung und -Katalogisierung begünstigen.

Jetzt ansehen
Events_Cover Image for Recording_The Open Group Webinar_042021

DORA Metrics: Die Herausforderungen

DORA Metrics sind zwar eine großartige Möglichkeit für DevOps-Teams, ihre Performance zu messen und zu verbessern ­– dennoch gibt es auch einige Herausforderungen, derer sich die Teams bewusst sein müssen. Für die meisten Unternehmen sind die vier Metriken lediglich ein Ausgangspunkt und müssen an den Kontext der jeweiligen Applikation angepasst werden, und eben nicht nur an die Teams oder Entwicklungsorganisation.

Im Folgenden finden Sie Herausforderungen, auf die Sie sich bei der Nutzung von DORA Metrics vorbereiten sollten:

  • Dezentralisierte Umgebung und Daten: Die Daten finden sich in unterschiedlichen Quellen in der gesamten IT-Landschaft verteilt.
  • Datenextraktion: Daten sind lediglich im Rohformat verfügbar.
  • Datentransformation: Daten müssen transformiert und kombiniert werden, damit sie als Berechnungsgrundlage herangezogen werden können.
  • Geschwindigkeit vs. Stabilität: Singuläre Metriken sollten in den richtigen Kontext gesetzt werden. Eine hohe Change Failure Rate könnte Hinweise auf eine mangelhafte Qualitätskontrolle geben, wohingegen aus einer hohen Deployment Frequency keine direkten Schlüsse auf die Qualität des Codes oder des Produkts gezogen werden können.

 

DORA Metrics und Value Stream Management

In diesem Guide wurde bereits kurz auf die Bedeutung von DORA Metrics für das Value Stream Management eingegangen. Heutzutage verwenden immer mehr Unternehmen nicht nur DORA Metrics zur Rationalisierung und Optimierung der Softwareentwicklung und -bereitstellung, sondern auch Value Stream Management für eine umfassende Transparenz über den gesamten Produktionsprozess.

Indem jeder Schritt mithilfe einer geeigneten VSM-Plattform wie LeanIX VSM überwacht wird – sprich von der Kundenanfrage bis zur Bereitstellung des Produkts – stellt dieser Managementansatz sicher, dass das volle Potenzial der Software ausgeschöpft und diese effizient an den Kunden geliefert wird.

Fazit

DORA ist bis dato die beste Methode zur Visualisierung und Messung der Performance von Engineering- und DevOps-Teams. Unternehmen sollten jedoch noch einen Schritt weiter gehen. Um das maximale Potenzial der Software für die Kunden freizusetzen, müssen DORA-Metriken ein inhärenter Bestandteil des Value Stream Managements sein.

Indem Service Catalogs, agile Planung und Bereitstellungsplattformen durch eine Plattform wie LeanIX VSM miteinander gebündelt werden, erhalten Softwareunternehmen einen holistischen Blick auf den Softwareentwicklungsprozess. Und genau den braucht es, um Ineffizienzen zu reduzieren und die Softwareentwicklung und -bereitstellungen zu optimieren.

Free trial

Build Reliable Digital Products Faster

Connect teams, technology, and processes for efficient software delivery with LeanIX Value Stream Management solution.

Free 14-Day Trial
VSM_header_mobile_edited (1)
KOSTENLOSE 14-TÄGIGE TESTVERSION

Entdecken Sie LeanIX Value Stream Management

HubSpot Video

Nutzen Sie Integrationen zu all Ihren bevorzugten DevOps-Tools, um zu analysieren, wie genau DORA und Flow Metrics, Standards und Schwachstellen mit den Geschäftsergebnissen Ihres Unternehmens zusammenhängen.

  • Entdecken und katalogisieren Sie Software-Artefakte
  • Ermitteln, analysieren und beseitigen Sie Ineffizienzen
  • Fördern Sie den Wissensaustausch zwischen Ihren Entwickler-Teams

Sie möchten sich selbst überzeugen? Dann melden Sie sich für eine kostenlose zweiwöchige Testversion an und schöpfen Sie das volle Potenzial Ihrer Softwareentwicklung aus.

Start 14-Day Trial

FAQ: DORA Metrics

Was sind DORA Metrics?

DevOps-Teams nutzen DevOps-Metriken, um ihre Performance zu messen und herauszufinden, ob sie zu den Schlusslichtern (Low Performer) oder Spitzenreitern (Elite Performer) innerhalb ihrer Entwicklungsorganisation gehören. Die vier genutzten Metriken lauten: Deployment Frequency (DF), Lead Time for Changes (LT), Mean Time to Recovery (MTTR) und Change Failure Rate (CFR).

Was beschreibt die Deployment Frequency?

Die Deployment Frequency bezieht sich 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.

Was beschreibt die Lead Time for Changes?

Diese Metrik misst die Zeitspanne zwischen dem Eingang der Anfrage und dem Deployment des Codes in die Produktionsumgebung. Die 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.

Was beschreibt die 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 wird berechnet, indem die Anzahl der beim Deployment auftretenden Fehler gezählt und dann durch die Gesamtzahl aller Deployments geteilt wird.

Was beschreibt die Mean Time to Recover?

Die Mean Time to Recover misst die Zeit, die für die Fehlersuche und Reparatur ausgefallener Services verstreicht. Hierfür wird die durchschnittliche Zeit zwischen einer Fehlermeldung sowie deren Behebung verfolgt.