DORA Metrics.
Messen. Verstehen.
Verbessern.
Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery — der Goldstandard zur Messung der Software-Delivery-Performance.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
DORA-Metriken sind vier KPIs zur Messung der DevOps-Performance: Deployment Frequency (Deployments pro Tag/Woche), Lead Time for Changes (Commit-zu-Deploy-Dauer), Change Failure Rate (Anteil fehlerhafter Releases) und Mean Time to Recovery (Wiederherstellungszeit nach Incidents). Sie stammen aus dem DORA-Forschungsprogramm (DevOps Research and Assessment) und korrelieren nachweislich mit Geschäftserfolg. Elite-Performer deployen mehrmals täglich mit Lead Times unter 1 Stunde und MTTR unter 1 Stunde.
Ohne Metriken
bleibt DevOps
Bauchgefühl.
„Wir sind schneller geworden." „Die Qualität hat sich verbessert." — Solche Aussagen hören wir häufig. Aber auf die Nachfrage „Um wie viel schneller?" wird es still.
Hier kommen die DORA Metrics ins Spiel. Entwickelt vom DORA-Team (heute Teil von Google Cloud), basieren sie auf Forschung mit Daten von über 36.000 Fachleuten weltweit. Sie korrelieren nachweislich mit dem Geschäftserfolg von Softwareorganisationen.
Grundlage des jährlichen State of DevOps Report.
Quelle: Accelerate State of DevOps Report 2024 · DORA / Google Cloud
DORA misst Outcomes.— Forsgren, Humble, Kim · „Accelerate" (2018)
Velocity misst nur
geschätzten Aufwand.
- 01Messen tatsächliche Delivery-Leistung
- 02Korrelieren mit Geschäftserfolg
- 03Branchenübergreifend vergleichbar
- 04Schwer zu manipulieren
- 05Berücksichtigen Geschwindigkeit UND Stabilität
- 01Messen nur geschätzten Aufwand, nicht Wertlieferung
- 02Kein Zusammenhang mit Geschäftserfolg belegt
- 03Nicht zwischen Teams vergleichbar
- 04Leicht aufzublähen (Inflation)
- 05Ignorieren Qualität und Stabilität
Vier Kennzahlen.
Geschwindigkeit
und Stabilität.
Jede Metrik beleuchtet einen anderen Aspekt Ihrer Delivery-Performance. Gemeinsam bilden sie ein ausgewogenes Bild aus Geschwindigkeit (Deployment Frequency, Lead Time) und Stabilität (Change Failure Rate, MTTR).
- /01
Deployment Frequency
Wie oft deployt Ihr Team erfolgreich in die Produktion? Diese Metrik misst die Geschwindigkeit, mit der Ihr Team Wert an Kunden liefert. Eine hohe Deployment Frequency ist ein Indikator für kleine Batch-Größen, automatisierte Pipelines und Vertrauen in den Release-Prozess.
EliteMehrmals pro TagHighEinmal pro Woche bis einmal pro MonatMediumEinmal pro Monat bis alle 6 MonateLowSeltener als alle 6 MonateSo messen SieZählen Sie die Anzahl erfolgreicher Deployments in die Produktionsumgebung pro Zeiteinheit. Nutzen Sie Deployment-Logs aus Jenkins, GitLab CI, ArgoCD oder Ihrem Release-Management-Tool.
Verbesserungstipps- 01Reduzieren Sie die Batch-Größe: Kleinere, häufigere Releases statt großer Big-Bang-Deployments
- 02Automatisieren Sie den gesamten Deployment-Prozess — kein manueller Schritt darf den Release blockieren
- 03Implementieren Sie Feature Flags, um unfertigen Code sicher zu deployen
- 04Entkoppeln Sie Deployment von Release: Deployen Sie kontinuierlich, aktivieren Sie Features gezielt
- /02
Lead Time for Changes
Wie lange dauert es vom Code-Commit bis zum produktiven Deployment? Die Lead Time for Changes misst die Effizienz Ihrer gesamten Delivery-Pipeline — von der Entwicklung über Tests und Quality Gates bis zum Release.
EliteWeniger als 1 StundeHigh1 Tag bis 1 WocheMedium1 Woche bis 1 MonatLowMehr als 1 MonatSo messen SieMessen Sie die Zeitspanne vom ersten Commit eines Changesets bis zum erfolgreichen Deployment in Produktion. Erfassen Sie die Daten aus Ihrem Git-System und Deployment-Tool.
Verbesserungstipps- 01Identifizieren Sie Wartezeiten mit Value-Stream-Mapping — oft sind 80 % der Lead Time reine Wartezeit
- 02Automatisieren Sie Quality Gates: Code Review, Tests, Security Scans müssen parallel laufen
- 03Eliminieren Sie manuelle Freigabeprozesse — ersetzen Sie sie durch automatisierte Policy Checks
- 04Nutzen Sie Trunk-Based Development statt langlebiger Feature-Branches
- /03
Change Failure Rate
Wie viel Prozent der Deployments führen zu einem Fehler, der einen Hotfix, Rollback oder Patch erfordert? Die Change Failure Rate misst die Qualität Ihrer Releases und die Effektivität Ihrer Quality Gates.
Elite0–5 %High6–15 %Medium16–30 %LowMehr als 30 %So messen SieTeilen Sie die Anzahl fehlgeschlagener Deployments (die einen Hotfix, Rollback oder Patch erfordern) durch die Gesamtzahl der Deployments. Erfassen Sie Incidents aus Ihrem Incident-Management-System.
Verbesserungstipps- 01Investieren Sie in automatisierte Tests: Unit, Integration, E2E — je mehr, desto besser
- 02Implementieren Sie Canary Deployments oder Blue-Green Deployments für risikoarme Releases
- 03Führen Sie Post-Mortems nach jedem Fehler durch — ohne Schuldzuweisungen (Blameless)
- 04Stärken Sie Code Reviews: Vier-Augen-Prinzip mit klaren Review-Checklisten
- /04
Mean Time to Recovery (MTTR)
Wie schnell kann Ihr Team einen Service nach einem Ausfall oder Fehler wiederherstellen? MTTR misst die Resilienz Ihrer Systeme und die Reaktionsfähigkeit Ihres Teams — von der Erkennung des Problems bis zur Lösung.
EliteWeniger als 1 StundeHighWeniger als 1 TagMedium1 Tag bis 1 WocheLowMehr als 1 WocheSo messen SieMessen Sie die Zeitspanne vom Erkennen eines Produktionsproblems bis zur vollständigen Wiederherstellung. Nutzen Sie Daten aus Monitoring-Tools (Grafana, Datadog, PagerDuty) und Incident-Tickets.
Verbesserungstipps- 01Investieren Sie in Observability: Logging, Monitoring und Alerting müssen lückenlos sein
- 02Implementieren Sie automatisierte Rollback-Mechanismen — ein Klick, nicht ein Kriegsrat
- 03Führen Sie regelmäßige Incident-Response-Übungen durch (Game Days)
- 04Reduzieren Sie die Mean Time to Detect (MTTD) mit proaktivem Monitoring und Anomalie-Erkennung
Ein häufiger Irrtum: Schnellere Deployments führen zu mehr Fehlern. Die DORA-Forschung zeigt das Gegenteil — Elite-Performer sind gleichzeitig schneller und stabiler. Kleine, häufige Releases reduzieren das Risiko pro Release und ermöglichen schnellere Recovery.
Die meisten Daten
liegen bereits
in Ihren Systemen.
Sie müssen sie nur zusammenführen. Drei Kategorien von Quellen und Tools.
Datenquellen
- —CI/CD-Systeme: Jenkins, GitLab CI, GitHub Actions, Azure DevOps
- —Versionskontrolle: Git-Commit-Historie und Merge-Zeitpunkte
- —Deployment-Logs: ArgoCD, Spinnaker, Octopus Deploy
- —Incident-Management: PagerDuty, Opsgenie, ServiceNow
- —Monitoring: Grafana, Datadog, Prometheus, New Relic
Spezialisierte DORA-Tools
- —Sleuth — automatische DORA-Erfassung aus Git und CI/CD
- —LinearB — Developer Productivity und DORA Metrics
- —Faros AI — Engineering Intelligence Platform
- —Jellyfish — Engineering Management Platform
- —Eigene Dashboards mit Grafana + Prometheus
Open-Source-Optionen
- —Four Keys Project (Google) — Referenzimplementierung auf GitHub
- —DevLake (Apache) — Open-Source Engineering Analytics
- —Backstage (Spotify) — Developer Portal mit Metrics-Plugins
- —Custom Scripts mit Git-Log-Analyse und API-Integration
DORA-Dashboard aufbauen —
fünf Schritte.
- /01
Datenquellen identifizieren
Welche CI/CD-Tools, Git-Hosting und Incident-Systeme nutzen Sie?
- /02
Events definieren
Was zählt als „Deployment"? Was als „Change Failure"? Klare Definitionen sind entscheidend.
- /03
Daten zusammenführen
Webhooks, API-Calls oder Batch-Jobs — bringen Sie alle Events in ein zentrales System.
- /04
Dashboard visualisieren
Grafana, Datadog oder ein Custom-Dashboard — zeigen Sie Trends, nicht nur Momentaufnahmen.
- /05
Team-Review etablieren
Monatliches Review der DORA Metrics im Team. Trends besprechen, Maßnahmen ableiten.
Wo steht die
Branche?
Der jährliche State of DevOps Report kategorisiert Teams in vier Performance-Stufen.
Gleiche Metriken.
Andere
Benchmarks.
Die Standard-DORA-Benchmarks stammen aus der IT-Welt — Webapplikationen, Cloud-Services, SaaS. Für industrielle Umgebungen gelten andere Maßstäbe. Die Metriken bleiben dieselben, aber die Interpretation ändert sich.
In der OT-Welt sind ungeplante Deployments ein Sicherheitsrisiko. Elite-Performance bedeutet hier: automatisierte, reproduzierbare Releases im geplanten Wartungsfenster — nicht 50 Deployments pro Tag.
Industrielle Systeme erfordern oft Hardware-in-the-Loop-Tests, Simulationen und Validierungsschritte, die Zeit brauchen. Der Fokus liegt auf der Automatisierung dieser Schritte, nicht auf deren Elimination.
Bei SPS-gesteuerten Anlagen kann ein fehlerhaftes Deployment Menschen gefährden. Die Change Failure Rate muss hier durch umfassende Simulation, Quality Gates und IEC 62443-konforme Prozesse minimiert werden.
Ein Rollback auf einer SPS-Anlage ist komplexer als ein Container-Neustart. Automatisierte Rollback-Mechanismen und getestete Recovery-Prozeduren sind der Schlüssel — nicht die reine Geschwindigkeit.
In der OT-Welt geht es nicht darum, so schnell wie möglich zu deployen. Es geht darum, den Weg vom Commit zum Deployment vollständig zu automatisieren — mit allen notwendigen Quality Gates, Simulationen und Validierungsschritten. Mehr dazu in unserem Industrial DevOps Angebot.
Von der Messung
zur
Verbesserung.
Metriken erheben ist der erste Schritt. Der eigentliche Wert entsteht durch die systematische Verbesserung. Dieser 6-Schritte-Plan hat sich in über 75 Projekten bewährt.
- /01
Baseline etablieren
Erheben Sie die vier DORA Metrics für mindestens ein Team über 4 Wochen. Nutzen Sie vorhandene Daten aus Git, CI/CD und Incident-Management. Perfekte Datenqualität ist nicht nötig — eine grobe Baseline reicht.
- /02
Engpässe identifizieren
Analysieren Sie, welche Metrik am weitesten vom Zielwert entfernt ist. Führen Sie ein Value-Stream-Mapping durch, um die Ursachen zu finden. Oft sind es Wartezeiten auf Freigaben, fehlende Testautomatisierung oder manuelle Deployment-Schritte.
- /03
Einen Hebel wählen
Fokussieren Sie sich auf eine Metrik und einen konkreten Verbesserungsbereich. Beispiel: Wenn die Lead Time hoch ist, automatisieren Sie zuerst die Quality Gates. Nicht alles auf einmal ändern.
- /04
Maßnahme umsetzen (2–4 Wochen)
Setzen Sie die gewählte Verbesserung in einem kurzen Sprint um. Kleine, messbare Änderungen sind besser als große Transformationsprojekte. Dokumentieren Sie, was Sie verändert haben.
- /05
Messen und vergleichen
Erheben Sie die DORA Metrics erneut und vergleichen Sie mit der Baseline. Hat sich die Zielmetrik verbessert? Haben sich andere Metriken verschlechtert (Trade-offs)? Teilen Sie die Ergebnisse im Team.
- /06
Kontinuierlich iterieren
Wiederholen Sie den Zyklus: nächster Engpass, nächste Maßnahme, nächste Messung. Etablieren Sie ein monatliches oder quartalmäßiges DORA Review im Team. Der Trend ist wichtiger als der absolute Wert.
Messen.
Verstehen.
Verbessern.
DORA Metrics sind kein Selbstzweck. Sie sind ein Werkzeug, um datengetriebene Entscheidungen über Ihre DevOps-Strategie zu treffen. Die vier Metriken decken Geschwindigkeit und Stabilität gleichermaßen ab — und zeigen, dass beides kein Widerspruch ist.
Starten Sie einfach: Erheben Sie die vier Metriken für ein Team, vergleichen Sie mit den Benchmarks und identifizieren Sie Ihren größten Hebel. Das dauert einen halben Tag — und liefert Erkenntnisse, die Ihre gesamte DevOps-Strategie auf eine solide Basis stellen.
Für industrielle Umgebungen gelten besondere Maßstäbe — aber die Metriken funktionieren auch hier. Der Schlüssel ist nicht blinde Geschwindigkeit, sondern automatisierte, reproduzierbare und sichere Delivery-Prozesse.
Der Trend ist wichtiger als der absolute Wert.
Was Kunden
wirklich fragen.
- Q.01
- Was sind DORA Metrics?
- DORA Metrics sind vier Schlüsselmetriken zur Messung der Software-Delivery-Performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery. Sie wurden vom DORA-Team (DevOps Research and Assessment) entwickelt und korrelieren nachweislich mit dem Geschäftserfolg von Softwareorganisationen.
- Q.02
- Wie misst man DORA Metrics?
- DORA Metrics werden aus CI/CD-Pipeline-Daten, Git-Commits, Deployment-Logs und Incident-Management-Systemen erhoben. Tools wie Sleuth, LinearB, Faros AI, das Open-Source-Projekt Four Keys von Google oder eigene Dashboards mit Grafana können die Erfassung automatisieren. Die meisten Daten liegen bereits in Ihren bestehenden Systemen.
- Q.03
- Was ist eine gute Deployment Frequency?
- Laut DORA-Benchmark deployen Elite-Performer mehrmals täglich, High-Performer wöchentlich bis monatlich. Für Industrial DevOps gelten andere Maßstäbe — hier ist ein kontrollierter Release-Rhythmus mit Quality Gates entscheidend, nicht die bloße Häufigkeit.
- Q.04
- Warum sind DORA Metrics besser als Velocity oder Story Points?
- DORA Metrics messen Outcomes (tatsächliche Delivery-Leistung), während Velocity und Story Points nur Output messen. DORA korreliert nachweislich mit Geschäftserfolg und organisatorischer Performance, während Velocity leicht manipulierbar ist und keinen Zusammenhang mit dem Geschäftsergebnis hat.
- Q.05
- Wie oft sollte man DORA Metrics erheben?
- Idealerweise kontinuierlich und automatisiert über ein Dashboard. Mindestens aber sollten Sie die Metriken monatlich erheben und im Team besprechen. Entscheidend ist der Trend über die Zeit, nicht eine einzelne Momentaufnahme.
- Q.06
- Gelten DORA Metrics auch für industrielle Umgebungen?
- Ja, die vier Metriken sind universell anwendbar. Allerdings müssen die Benchmarks an den industriellen Kontext angepasst werden. Eine SPS-Anlage braucht keine 50 Deployments pro Tag — aber automatisierte, reproduzierbare Releases im geplanten Wartungsfenster sind auch hier Elite-Performance.
- Q.07
- Was ist der Unterschied zwischen Lead Time und Cycle Time?
- Lead Time for Changes (DORA) misst die Zeit vom ersten Commit bis zum produktiven Deployment. Cycle Time misst die Zeit von der ersten Arbeit an einem Item bis zu dessen Fertigstellung. DORA fokussiert bewusst auf die Pipeline-Effizienz, nicht auf die gesamte Entwicklungszeit.
- Q.08
- Kann man DORA Metrics auch ohne spezielle Tools messen?
- Ja. Für den Start genügen Git-Logs, CI/CD-Logs und eine einfache Tabellenkalkulation. Zählen Sie Deployments, messen Sie die Zeit vom Commit zum Deployment, notieren Sie fehlgeschlagene Releases und Recovery-Zeiten. Automatisierung kommt später.
Bevor Sie
DORA messen.
3 Minuten.
Unser kostenloser DevOps-Reifegrad-Schnellcheck als erste Orientierung. Personalisierter Report mit Score, Benchmark-Vergleich und Top-3-Handlungsempfehlungen.
Verwandte Artikel
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Reifegradmodelle und Value-Stream-Mapping — die wichtigsten Methoden.
DevOps-Kultur aufbauen: CALMS & Coaching
Kultur, Automatisierung, Lean, Messung und Sharing — das CALMS-Framework in der Praxis.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance