Was sind DORA-Metriken? Die vier Schlüssel zur Messung
Zusammenfassung
DORA-Metriken sind vier Kennzahlen, die offenbaren, wie schnell und zuverlässig ein Software-Team Code ausliefert. Sie umfassen Deployment Frequency, Lead Time für Änderungen, Change Failure Rate und die Wiederherstellungszeit nach Fehlern in Production. Entwickelt von der von Google akquirierten DevOps Research and Assessment Gruppe und validiert über Tausende von Engineering-Teams bleiben sie das Grundmodell für die Messung von Software-Lieferung.
Was sind DORA-Metriken? Die vier Schlüssel zur Messung der Dev-Performance
Was sind DORA metriken? Das ist die Frage, die viele Entwickler stellen, wenn sie von diesen Kennzahlen hören. Was sind DORA-Metriken im Detail: Es sind vier Messgrößen, die die Leistung der Software-Lieferung quantifizieren. Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service. Diese vier Metriken wurden von Nicole Forsgren, Jez Humble und Gene Kim entwickelt, über Zehntausende von Engineering-Teams validiert und 2018 von Google akquiriert. Dieser Leitfaden erklärt, was jede Metrik misst, wie die Benchmarks in der Praxis aussehen und wo das Modell an seine Grenzen stößt. Die DORA-Metriken sind nicht irgendein akademisches Konzept, sondern ein bewährtes Framework, das zeigt, wie echte Teams wirklich funktionieren und warum Messung wichtig ist.
Woher DORA-Metriken kommen und warum die Forschung zählt
Das DORA-Programm startete 2014 mit einer konkreten Frage: Was machen High-Performing-Teams anders als alle anderen? Das Forschungsteam führte jährliche Umfragen mit Zehntausenden von Entwicklern über Branchen hinweg durch und suchte nach Praktiken, die starke Software-Lieferungsergebnisse vorhersagten.
Das Ergebnis war kontraintuiv. Elite-Teams handelten nicht mit Geschwindigkeit gegen Stabilität. Sie lieferten schneller und hatten weniger Production-Incidents. Dieses Ergebnis untergrub die Rechtfertigung für langsamere Release-Zyklen: Wenn wir seltener deployen, werden wir weniger Probleme verursachen. Die Daten sagten das Gegenteil.
Teams, die häufig deployten, bauten bessere Feedback-Schleifen auf, identifizierten Probleme früher und erholten sich schneller. Geschwindigkeit und Stabilität standen nicht in Opposition. Sie waren korreliert. Google akquirierte das DORA-Programm 2018 und das Team veröffentlicht jetzt einen jährlichen State of DevOps Report. Sie haben ihr Modell 2025 mit einer fünften Metrik (Rework Rate) aktualisiert und pflegen die Forschung als offene Initiative auf dora.dev.
Die vier Messgrößen und was jede wirklich misst
Das Modell wurde 2025 aktualisiert, um Rework Rate als fünfte Metrik hinzuzufügen, aber die vier ursprünglichen Schlüssel bleiben die Baseline für die meisten Tools und Team-Diskussionen. Jede Metrik misst ein anderes Aspekt deiner Pipeline und gibt dir Einblick in verschiedene Teile deines Delivery-Prozesses.
Deployment Frequency
Wie oft dein Team zu Production pusht. Das ist die vollständige Definition. Elite-Teams deployen on Demand: mehrmals täglich, wenn etwas ready ist. Low Performer deployen einmal im Monat oder weniger, manchmal alle paar Monate.
Für einen Solo-Builder bedeutet jede konsistente wöchentliche Shipping-Kadenz, dass du mit dieser einzelnen Messgröße solidly in der High-Performing-Bracket landest. Deployment Frequency ist ein Proxy für Pipeline-Vertrauen. Teams, die selten deployen, haben normalerweise fragile Infrastruktur, schwere manuelle Testing-Gates oder organisatorische Genehmigungsketten, die Releases zum Schneckentempo drosseln. Teams, die mehrmals täglich ausliefern, haben die meisten dieser Engpässe automatisiert. Die Häufigkeit ist ein Symptom, nicht die Ursache.
Lead Time für Änderungen
Die Zeit vom Commit im Version Control bis zur Live-Schaltung derselben Änderung in Production. Der größte Teil dieser Duration ist nicht Coden schreiben. Es ist Warten: Warten auf CI/CD-Pipelines, Warten auf einen Deployment-Slot, Warten auf jemanden mit Access zum Auslösen des Release.
Eine Lead Time von wenigen Stunden bedeutet, dass der Workflow tight und größtenteils automatisiert ist. Eine Lead Time in Wochen bedeutet, dass etwas Strukturelles Reibung erzeugt. Für Solo-Developer ist Lead Time, was zwischen dem Push eines Commits und dem Live-Sehen der Änderung durch User steht. Manchmal ist das eine Deployment-Pipeline, die zwölf Minuten dauert. Manchmal ist es interne Ungewissheit, ob eine Änderung stabil genug zum Shipping ist.
Change Failure Rate
Der Prozentsatz von Deployments, die ein Problem verursachen, das schwerwiegend genug für einen Hotfix, Rollback oder Incident Response ist. Dies ist das Quality-Signal im DORA-Modell. Der 2024 State of DevOps Report setzt Elite-Teams auf etwa 5% Change Failure Rate. Low Performer fahren mit 46 bis 63%.
Wenn etwa die Hälfte deiner Deployments sofortige Intervention erfordert, haben dein Testing Coverage und dein Review-Prozess erhebliche strukturelle Lücken. Change Failure Rate misst nicht abstrakte Code-Qualität. Sie misst, ob die Änderungen, die du shippen, sich in der Production-Umgebung speziell wie erwartet verhalten. Ein Test Suite, die lokal passed, aber nicht die Integration Paths abdeckt, die in Production fehlschlagen, wird diese Zahl nicht bewegen.
Time to Restore Service
Wenn ein Deployment einen Incident verursacht, wie lange dauert es, bis der Service wiederhergestellt ist? Ursprünglich MTTR (Mean Time to Recovery). Das DORA-Team aktualisierte 2025 auf Failed Deployment Recovery Time, die speziell die Wiederherstellung von Deployment-verursachten Incidents verfolgt, nicht Infrastructure-Fehler oder Third-Party-Ausfälle.
Diese Unterscheidung zählt, weil Deployment-verursachte Incidents unter der Kontrolle des Teams stehen. Elite-Teams stellen Service in unter einer Stunde wieder her. Low Performer können Tage bis eine Woche brauchen. Wenn du ein Solo-Builder bist, geht diese Metrik darum, ob du Monitoring hast. Teams ohne Alerting-Infrastruktur erfahren von Fehlern durch User-Beschwerden statt automatisierter Signale.
Wie die Performance-Tiers in der Praxis aussehen
Der State of DevOps Report unterteilt Teams in vier Tiers basierend auf ihren DORA-Nummern. Dies sind Ranges aus dem 2024 Report, keine hard cutoffs. Der Gap zwischen Elite und Low ist nicht inkrementell.
Laut 2024 Report können Low-Performing-Teams über 180-mal länger zum Deployen brauchen und über 2.500-mal länger zur Wiederherstellung im Vergleich zu Elite-Teams. Dies sind keine marginalen Unterschiede. Elite-Tier zu erreichen ist mit anhaltender Investition in CI/CD-Automatisierung, Test-Coverage und Observability-Tools möglich. Es passiert nicht durch schneller schreiben, sondern durch das Entfernen manueller Schritte zwischen Commit und zuverlässiger Production-Ausführung.
Wie AI-Entwicklungstools 2026 DORA-Nummern verschieben
Bis 2026 sind AI-Coding-Tools verbreitet genug, um DORA-Metriken zu beeinflussen. Teams mit Cursor, GitHub Copilot oder ähnlichen Tools schreiben schneller Code, was Deployment Frequency nach oben treibt. Lead Time hat sich auch verkürzt, weil mehr Code pro Developer pro Woche produziert wird. Dies bedeutet mehr Commits durch die Pipeline in kürzerer Zeit. Die Auswirkungen von AI auf diese Metriken sind bereits messbar und wichtig für die Zukunftsplanung.
Change Failure Rate ist in beide Richtungen gegangen. Teams mit starken Review-Prozessen und Test Coverage haben ihre Failure Rates stabil gehalten, während sie mehr ausliefern. Teams, die AI-generierten Code ohne angemessene Review ausliefern, haben steigende Failure Rates gesehen. Das DORA-Modell kümmert sich nicht, wie Code geschrieben ist. Es misst, was passiert, nachdem Code in Production geht.
Der 2024 State of DevOps Report fand, dass 41% der Teams AI-unterstützte Entwicklungstools nutzten. Diese Teams zeigten höhere Deployment Frequency ohne proportionale Change Failure Rate Erhöhung, wenn AI-Adoption mit automatisiertem Testing kombiniert wurde.
Voilà ce qui coince en pratique: AI accelerates the front end of the pipeline significantly. DORA tells you whether that acceleration is being absorbed cleanly or creating instability downstream.
Tools zur Nachverfolgung von DORA-Metriken ohne Überengineering
Die meisten Teams starten mit der Messung von DORA-Metriken, indem sie Daten aus Tools ziehen, die sie bereits nutzen: GitHub oder GitLab für Deployment Events, PagerDuty oder OpsGenie für Recovery Time Daten, und das Incident Management System für Change Failure Rate. Mehrere Plattformen haben DORA-Dashboards speziell um diese vier Metriken herum gebaut.
Für einen Solo-Builder ohne Budget: Ein Script, das den Timestamp jedes Production Deployments und Recovery Events logged, gibt dir Deployment Frequency und Recovery Time mit null Infrastrukturkosten. Lead Time kann aus Git Log Commit-Timestamps approximiert werden. Die meisten Entwickler haben bereits die Rohdata irgendwo, es geht nur darum, sie systematisch zu sammeln und auszuwerten.
Wo DORA-Metriken wirkliche Limits haben
Die Messung von DORA ist sinnvoll. Sie als vollständiges Bild von Engineering-Performance zu behandeln, erzeugt mehrere Blind Spots. Technical Debt Accumulation: Hohe Deployment Frequency mit niedriger Change Failure Rate sagt nichts darüber aus, ob die Codebase schwieriger zu bearbeiten wird. Ein Team kann Elite-DORA-Nummern erreichen, während es Schulden akkumuliert, die jedes neue Feature langsamer zum Shipping machen.
Outcome Alignment: Deployment Frequency misst Output, nicht Outcomes. Fünfmal täglich zu shippen zählt nicht, wenn keine dieser Änderungen eine Business-Metrik bewegt. Feature Flags, A/B Testing und Business Metrics Tracking sitzen außerhalb des DORA-Modells.
Sustainability: Das DORA-Team fügte 2023 eine Developer Experience Dimension hinzu. Nachhaltige High Performance erfordert Engineers, die nicht auf Burnout fahren. Die vier Core Metrics verfolgen nicht, ob Elite-Performance anderswo einen Preis hat.
Nutze DORA als Diagnostic Tool, nicht als Scoreboard. Die Fragen, die die Metriken stellen, sind oft actionable-r als die Zahlen selbst. Eine Change Failure Rate von 30% ist weniger hilfreich, als zu wissen, welche Änderungstypen am häufigsten fehlschlagen und warum.
Wie du anfängst, wenn du das noch nie gemessen hast
Ein sechs Monate altes Side Project ohne DORA-Daten ist normal. Die meisten kleinen Teams und Solo-Builder haben nie etwas davon gemessen. Wenn du bei null anfängst, wähle Deployment Frequency und Lead Time zuerst. Beide sind einfach aus Git-Commit-Timestamps und Deployment Logs zu extrahieren. Eine Lead Time von drei Tagen für eine Änderung, die vierzig Minuten zum Schreiben braucht, ist ein Signal wert zu untersuchen.
Change Failure Rate und Time to Restore erfordern, dass Incidents sich akkumulieren. Wenn etwas in Production bricht, log den Timestamp seiner Entdeckung und Behebung. Diese Daten kombinieren sich über Zeit. Nach jedem Production Incident, stelle zwei Fragen: Wie lange bis zur Erkennung? Wie lange von Erkennung bis Behebung? Diese Zahlen sind Time to Restore Inputs. Wenn du sie sechs Monate verfolgst, weißt du, ob dein Recovery-Prozess sich verbessert oder stagniert.
Drei Gründe, DORA-Metriken auch als Solo Dev zu messen: Die Metriken machen unsichtbare Reibung sichtbar, schaffen Accountability für Automatisierungsinvestitionen und geben dir etwas Konkretes zur Verbesserung. Der Grund nicht zu messen: Wenn du pre-launch ohne echte User bist, bedeuten die Zahlen nicht viel. Start zu messen, wenn du regelmäßig zu echten Usern shippen.
Ce n'est pas une idée parfaite. C'est une idée faisable.