DORA Metrics: DevOps-Performance messen und verbessern
Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery — die vier DORA Metrics sind der Goldstandard zur Messung der Software-Delivery-Performance. So setzen Sie sie ein.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Warum DevOps-Performance messen?
„Wir sind schneller geworden.“ „Die Qualität hat sich verbessert.“ „DevOps funktioniert bei uns.“ — Solche Aussagen hören wir häufig. Aber wenn wir nachfragen „Um wie viel schneller?“ oder „Woran messen Sie das?“, wird es still.
Ohne objektive Metriken bleibt DevOps ein Bauchgefühl. Sie können weder Fortschritte nachweisen noch Investitionen begründen. Führungskräfte fragen zurecht: „Was bringt uns DevOps konkret?“ — und ohne Zahlen haben Sie keine Antwort.
Hier kommen die DORA Metrics ins Spiel. Entwickelt vom DORA-Team (DevOps Research and Assessment, heute Teil von Google Cloud), basieren sie auf jahrelanger Forschung mit Daten von über 36.000 Fachleuten weltweit. Sie korrelieren nachweislich mit dem Geschäftserfolg von Softwareorganisationen — und bilden die Grundlage des jährlichen „State of DevOps Report“.
Warum DORA Metrics und nicht Velocity oder Story Points?
DORA Metrics (Outcomes)
- Messen tatsächliche Delivery-Leistung
- Korrelieren mit Geschäftserfolg
- Branchenübergreifend vergleichbar
- Schwer zu manipulieren
- Berücksichtigen Geschwindigkeit UND Stabilität
Velocity / Story Points (Output)
- Messen nur geschätzten Aufwand, nicht Wertlieferung
- Kein Zusammenhang mit Geschäftserfolg belegt
- Nicht zwischen Teams vergleichbar
- Leicht aufzublähen (Inflation)
- Ignorieren Qualität und Stabilität
Die 4 DORA Metrics im Detail
Jede Metrik beleuchtet einen anderen Aspekt Ihrer Software-Delivery-Performance. Gemeinsam bilden sie ein ausgewogenes Bild aus Geschwindigkeit (Deployment Frequency, Lead Time) und Stabilität (Change Failure Rate, MTTR).
Deployment Frequency
Deployment-HäufigkeitWie 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.
So messen Sie
Zä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
- Reduzieren Sie die Batch-Größe: Kleinere, häufigere Releases statt großer Big-Bang-Deployments
- Automatisieren Sie den gesamten Deployment-Prozess — kein manueller Schritt darf den Release blockieren
- Implementieren Sie Feature Flags, um unfertigen Code sicher zu deployen
- Entkoppeln Sie Deployment von Release: Deployen Sie kontinuierlich, aktivieren Sie Features gezielt
Lead Time for Changes
Vorlaufzeit für ÄnderungenWie 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.
So messen Sie
Messen 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
- Identifizieren Sie Wartezeiten mit Value-Stream-Mapping — oft sind 80 % der Lead Time reine Wartezeit
- Automatisieren Sie Quality Gates: Code Review, Tests, Security Scans müssen parallel laufen
- Eliminieren Sie manuelle Freigabeprozesse — ersetzen Sie sie durch automatisierte Policy Checks
- Nutzen Sie Trunk-Based Development statt langlebiger Feature-Branches
Change Failure Rate
Änderungs-FehlerquoteWie 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.
So messen Sie
Teilen 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
- Investieren Sie in automatisierte Tests: Unit, Integration, E2E — je mehr, desto besser
- Implementieren Sie Canary Deployments oder Blue-Green Deployments für risikoarme Releases
- Führen Sie Post-Mortems nach jedem Fehler durch — ohne Schuldzuweisungen (Blameless)
- Stärken Sie Code Reviews: Vier-Augen-Prinzip mit klaren Review-Checklisten
Mean Time to Recovery (MTTR)
Mittlere WiederherstellungszeitWie 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.
So messen Sie
Messen 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
- Investieren Sie in Observability: Logging, Monitoring und Alerting müssen lückenlos sein
- Implementieren Sie automatisierte Rollback-Mechanismen — ein Klick, nicht ein Kriegsrat
- Führen Sie regelmäßige Incident-Response-Übungen durch (Game Days)
- Reduzieren Sie die Mean Time to Detect (MTTD) mit proaktivem Monitoring und Anomalie-Erkennung
Geschwindigkeit und Stabilität gehören zusammen
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.
DORA Metrics in der Praxis messen
Die Theorie ist klar — aber wie erheben Sie die Metriken konkret? Die gute Nachricht: Die meisten Daten liegen bereits in Ihren bestehenden Systemen. Sie müssen sie nur zusammenführen.
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
Ein DORA-Dashboard aufbauen — Schritt für Schritt
DORA Benchmark 2026: Wo steht die Branche?
Der jährliche State of DevOps Report kategorisiert Teams in vier Performance-Stufen. Hier sind die aktuellen Benchmark-Werte und was sie bedeuten.
Elite Performer
Top-Performer mit vollautomatisierten Pipelines, Feature Flags, Canary Deployments und einer starken DevOps-Kultur. Diese Teams deployen kontinuierlich und reagieren in Minuten auf Probleme.
High Performer
Gut aufgestellte Teams mit funktionierenden CI/CD-Pipelines und automatisierten Tests. Die meisten Quality Gates sind automatisiert, manuelle Schritte werden sukzessive eliminiert.
Medium Performer
Teams mit grundlegender CI/CD, aber noch vielen manuellen Schritten. Testabdeckung ist lückenhaft, Deployments erfordern oft Koordination mehrerer Teams.
Low Performer
Teams mit überwiegend manuellen Prozessen. Releases sind große Events mit hohem Risiko. Wenig Automatisierung, lange Feedback-Zyklen.
DORA Metrics für Industrial DevOps
Die Standard-DORA-Benchmarks stammen aus der IT-Welt — Webapplikationen, Cloud-Services, SaaS-Produkte. Für industrielle Umgebungen mit SPS/PLC, SCADA und cyber-physischen Systemen gelten andere Maßstäbe. Die Metriken bleiben dieselben, aber die Interpretation ändert sich.
Deployment Frequency
In der OT-Welt sind ungeplante Deployments ein Sicherheitsrisiko. Elite-Performance bedeutet hier: automatisierte, reproduzierbare Releases im geplanten Wartungsfenster — nicht 50 Deployments pro Tag.
Lead Time for Changes
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.
Change Failure Rate
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.
Mean Time to Recovery
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.
Der Schlüssel: Automatisierung, nicht 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. Die Geschwindigkeit kommt dann von selbst. Mehr dazu erfahren Sie in unserem Industrial DevOps Angebot.
Von der Messung zur Verbesserung: Ihr Aktionsplan
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.
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.
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.
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.
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.
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.
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.
Wo stehen Sie? Kostenloser Reifegrad-Check
Bevor Sie DORA Metrics im Detail messen, hilft unser kostenloser DevOps-Reifegrad-Schnellcheck als erste Orientierung. In 3 Minuten erhalten Sie einen personalisierten Report mit Score, Benchmark-Vergleich und Top-3-Handlungsempfehlungen.
Fazit: 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.
Und dann: regelmäßig wiederholen. Quartal für Quartal. Der Trend ist wichtiger als der absolute Wert.
Häufig gestellte Fragen zu DORA Metrics
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.
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.
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.
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.
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.
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.
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.
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.
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.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchen