DORA-Metriken sind die Kennzahlen für Software-Delivery-Performance aus dem DORA-Forschungsprogramm: Change Lead Time, Deployment-Frequenz und Failed Deployment Recovery Time beschreiben den Durchsatz, Change Fail Rate und Deployment Rework Rate die Instabilität. Zusammen zeigen sie, wie schnell und wie sicher ein Team Änderungen in Produktion bringt.
Was sind DORA-Metriken?
DORA-Metriken sind ein kleiner Satz von Kennzahlen für die Leistungsfähigkeit der Softwareauslieferung. Sie stammen aus dem Forschungsprogramm DORA (DevOps Research and Assessment), das heute zu Google Cloud gehört. Die Forschung begann 2014 und brachte die bekannten „Four Keys“ hervor, die durch die jährlichen State-of-DevOps-Reports und das Buch Accelerate populär wurden. Seitdem hat sich das Modell weiterentwickelt: 2023 wurde die Wiederherstellungsmetrik von MTTR in Failed Deployment Recovery Time umbenannt, 2024 kam die Deployment Rework Rate als fünfte Metrik hinzu.
Die zentrale Erkenntnis: Geschwindigkeit und Stabilität sind kein Widerspruch. Teams, die kleine Änderungen häufig ausliefern, haben in der Regel auch weniger Fehler und erholen sich schneller. Deshalb werden die Metriken immer gemeinsam betrachtet.
Die fünf DORA-Metriken im Überblick
DORA ordnet die Metriken aktuell zwei Faktoren zu, Durchsatz und Instabilität:
| Metrik | Faktor | Was sie misst |
|---|---|---|
| Change Lead Time | Durchsatz | Zeit vom Commit einer Änderung bis zu ihrem Einsatz in Produktion |
| Deployment-Frequenz | Durchsatz | Wie oft in einem Zeitraum in Produktion ausgeliefert wird |
| Failed Deployment Recovery Time | Durchsatz | Wie lange die Wiederherstellung nach einem fehlgeschlagenen Deployment dauert, das sofortiges Eingreifen erfordert |
| Change Fail Rate | Instabilität | Anteil der Deployments, die sofortiges Eingreifen erfordern, etwa Rollback oder Hotfix |
| Deployment Rework Rate | Instabilität | Anteil ungeplanter Deployments, die wegen eines Vorfalls in Produktion nötig werden |
Die Failed Deployment Recovery Time ist bewusst enger gefasst als eine allgemeine MTTR: Sie umfasst nur Störungen, die durch eine Änderung verursacht wurden, nicht etwa den Ausfall einer Cloud-Region oder einer Drittanbieter-API. So bleibt die Kennzahl auf den Auslieferungsprozess fokussiert, den das Team tatsächlich beeinflusst.
So messen Sie DORA-Metriken
Die Daten für alle fünf Metriken liegen bereits in Ihrer Toolchain. Die Aufgabe besteht darin, sie konsistent zu verknüpfen.
- Commits und Merges aus der Versionsverwaltung liefern den Startpunkt der Change Lead Time.
- Deployment-Ereignisse aus CI/CD liefern die Deployment-Frequenz und das Ende der Lead Time. Jedes Ereignis sollte Service, Version, Umgebung und Commit-SHA enthalten.
- Incidents, Rollbacks und Hotfixes aus Incident Management und Pipeline markieren, welche Deployments fehlgeschlagen sind und welche Folge-Deployments ungeplante Nacharbeit waren.
- Wiederherstellung ist die Zeit zwischen Erkennung des fehlerhaften Deployments und wiederhergestelltem Service, idealerweise durch Telemetrie belegt statt durch einen Ticketstatus.
Ein illustratives Beispiel: Ein Team liefert in einem Monat 60 Deployments aus. Vier davon erforderten einen Rollback oder Hotfix, die Change Fail Rate liegt also bei 4 / 60 = 6,7 %. Drei weitere Deployments waren ungeplante Korrekturen nach Produktionsvorfällen, die Deployment Rework Rate beträgt 3 / 60 = 5 %. Die mittlere Wiederherstellungszeit der vier Fehlschläge lag bei 38 Minuten. Aussagekräftig wird das erst im Verlauf über mehrere Monate.
Warum DORA-Metriken wichtig sind
DORA-Metriken geben Engineering-Leitung und Teams eine gemeinsame, ergebnisorientierte Sprache. Codezeilen, Story Points oder Ticketzahlen lassen sich leicht manipulieren und sagen nichts darüber, ob Nutzer funktionierende Software erhalten. DORA-Metriken hängen dagegen direkt mit Zuverlässigkeitspraktiken zusammen: Eine hohe Change Fail Rate deutet auf schwache Tests oder riskante Release-Strategien hin, eine lange Lead Time auf große Batches oder langsame Reviews, eine lange Recovery Time auf fehlende Observability oder unklare Runbooks. Sie ergänzen SLOs, die die nutzerseitige Zuverlässigkeit beschreiben, die jede Auslieferung schützen muss.
Best Practices
- Pro Service oder Team messen, nicht pro Unternehmen. Ein Gesamtwert verdeckt die Services, die Unterstützung brauchen.
- Zur Verbesserung nutzen, nicht zum Ranking. DORA selbst warnt davor, die Metriken zu individuellen Zielvorgaben zu machen.
- Erfassung automatisieren. Manuell gemeldete Zahlen driften und genießen wenig Vertrauen.
- Batch-Größe reduzieren. Kleinere Änderungen, Feature Flags und Canary Deployments verbessern Durchsatz und Stabilität zugleich.
- Aus Fehlern lernen. Jedes fehlgeschlagene Deployment verdient ein kurzes, schuldfreies Postmortem.
Typische Fehler
- Nur die Deployment-Frequenz optimieren, etwa indem eine Änderung in viele triviale Deployments zerlegt wird.
- Jeden Incident als fehlgeschlagenes Deployment zählen und damit Infrastrukturausfälle in eine Delivery-Metrik mischen.
- Die veraltete MTTR-Definition verwenden und mit aktuellen DORA-Benchmarks vergleichen.
- Teams mit sehr unterschiedlichen Systemen gegeneinander vergleichen statt mit ihrer eigenen Ausgangslage.
Benchmarks richtig einordnen
Die DORA-Reports gruppieren befragte Teams regelmäßig in Leistungscluster und veröffentlichen dafür Bandbreiten, etwa für Deployment-Frequenz oder Change Fail Rate. Diese Cluster werden jedes Jahr neu aus den Umfragedaten berechnet und können sich von Report zu Report verschieben. Nutzen Sie sie daher als grobe Orientierung, nicht als festes Ziel. Wichtiger ist, dass Sie Ihre Werte konsistent erheben, Definitionen dokumentieren und sie mit dem eigenen Verlauf vergleichen. Eine Verbesserung der Change Lead Time von zehn auf drei Tage ist für ein Team aussagekräftiger als die Frage, in welchem Cluster es gerade liegt.
Wie Obseria unterstützt
Das Deployment-Tracking von Obseria erfasst Deployment-Ereignisse mit Version und Service und korreliert sie mit Traces, Fehlern und SLOs. So sehen Sie, welches Deployment einen Service verschlechtert hat und wann er sich erholt hat. Zusammen mit Incident Management und Automatisierungs-Workflows liefert das die Telemetrie-Seite von fehlgeschlagenen Deployments und Recovery Time. Die Lead Time vom Commit bis zum Deployment stammt weiterhin aus Ihrer Versionsverwaltung und Ihrem CI/CD-System.