Was sind DORA-Metriken?

Die vom DevOps Research and Assessment Team (DORA) von Google entwickelten DORA-Metriken bieten branchenübliche Benchmarks für die Softwarebereitstellung und DevOps-Reifegrade.

Im Wesentlichen konzentrieren sich die DORA-Metriken auf zwei Dimensionen:

1. Durchsatz: Wie schnell DevOps-Teams Software bereitstellen.
   
   
2. Stabilität: Wie zuverlässig und sicher DevOps-Teams Software bereitstellen.

Durchsatzorientierte Metriken zeigen, wie schnell Codeänderungen den Softwareentwicklungszyklus (von der Ideenfindung bis zur Produktion) durchlaufen, während stabilitätsorientierte Metriken zeigen, wie häufig Bereitstellungen ausfallen und wie schnell Teams sich davon erholen. In Kombination liefern sie Führungskräften und DevOps-Teams evidenzbasierte, reproduzierbare Einblicke in die DevOps-Leistung. Unternehmen müssen sich nicht auf die subjektive Leistung oder oberflächliche Indikatoren wie „geschriebene Codezeilen“ oder „geleistete Arbeitsstunden“ verlassen.

Durch das Tracking von DORA-Metriken können DevOps-Teams sehen, wie sie im Vergleich zu branchenweit anerkannten Leistungstufen (niedrig, mittel, hoch und Elite) abschneiden und ob sie auf die unternehmensweiten Ziele abgestimmt sind. Es hilft Unternehmen dabei, Engpässe in CI/CD-Pipelines (Continuous Integration/Continuous Delivery), Softwaretests und im Incident-Management objektiv zu identifizieren.   

Die DORA-Metriken erleichtern es der Führungsebene außerdem, den Zustand der Entwicklungsabteilungen gegenüber den Geschäftspartnern zu kommunizieren und Investitionen in fortschrittliche Tools für Automatisierung, Observability und Site Reliability Engineering (SRE) zu rechtfertigen, die zur Optimierung der DevOps-Praktiken beitragen.

Im DevOps-Kontext bezeichnet DORA das DevOps Research and Assessment Team, das die Metriken zur Leistung von Softwareentwicklungsteams bekannt gemacht hat.

DORA – mittlerweile Teil von Google Cloud – begann als unabhängiges Forschungprojekt, das untersuchte, wie sich Softwarebereitstellungsprozesse auf Geschäftsergebnisse auswirken. Das DORA-Team wollte eine zentrale Frage beantworten: Was unterscheidet leistungsstarke Softwareteams von leistungsschwachen Teams?

Es wurden Umfrage- und Telemetriedaten von Tausenden von Teams erfasst und festgestellt, dass eine kleine Anzahl von Metriken in Bezug auf Betrieb und Bereitstellung die Gesamtleistung präzise vorhersagen konnte. Bei diesen Metriken handelt es sich um die Bereitstellungsfrequenz, die Vorlaufzeit für Änderungen, die Fehlerrate bei Änderungen und die Wiederherstellungszeit bei fehlgeschlagenen Bereitstellungen. Die Ergebnisse bewiesen auch, dass die Geschwindigkeit der Veröffentlichung und die Softwarestabilität eng miteinander verbunden sind, sodass Teams nicht das eine dem anderen vorziehen müssen.

Schließlich wurden die vier Indikatoren zu den standardisierten DORA-Metriken, die branchenübliche Benchmarks für die Leistung der Softwarebereitstellung lieferten. 2024 fügte das DORA-Forschungsteam dem Framework eine fünfte Metrik hinzu – die Nachbearbeitungsrate bei der Bereitstellung.  

Die fünf DORA-Metriken können in zwei übergeordnete Kategorien eingeteilt werden: „Durchsatz“ und „Stabilität“.

Zu den Metriken gehören die Bereitstellungsfrequenz, die Vorlaufzeit für Änderungen und die Wiederherstellungszeit bei fehlgeschlagenen Bereitstellungen, die miteinander kombiniert beschreiben, wie viele Änderungen eine Anwendung verarbeiten kann und wie schnell Änderungen in die Produktion gelangen.

Stabilitätsmetriken umfassen die Fehlerrate bei Änderungen und Nachbearbeitungsrate bei der Bereitstellung, die den Anteil der Bereitstellungen messen, die Fehler verursachen, sowie den Anteil der Bereitstellungen, die ungeplant oder durch Produktionsvorfälle verursacht wurden.

Die Bereitstellungsfrequenz misst, wie oft ein Team erfolgreich Code über einen bestimmten Zeitraum (pro Tag, pro Woche, pro Monat) für die Produktion bereitstellt.

Die Bereitstellungsfrequenz ist eines der sichtbarsten Signale dafür, wie flexibel und souverän sich ein Softwareteam in seinem Bereitstellungsprozess verhält. Wenn ein Team Code mehrfach täglich für die Produktion bereitstellt, bedeutet das in der Regel, dass automatisierte Entwicklungs-, Test- und Bereitstellungsprozesse reibungslos ablaufen und solide Observability-Mechanismen vorhanden sind. Unter diesen Bedingungen können Entwicklungsteams Software freigeben, ohne befürchten zu müssen, dass das System zusammenbricht.

Im Gegensatz dazu verlassen sich Teams, die nur einmal im Monat (oder sogar seltener) Software bereitstellen, oft auf langlebige Code-Branches, manuelle Tests, komplexe Genehmigungsprotokolle und große Release-Tage. All diese Faktoren verlangsamen den Feedbackzyklus der Benutzer und erhöhen die Kosten für die Behebung von Mängeln.

Eine hohe Bereitstellungsfrequenz ist allerdings kein Zeichen für einen guten Allgemeinzustand, wenn sie mit häufigen Ausfällen oder Rollbacks einhergeht. Leistungsstarke Teams kombinieren eine hohe Bereitstellungsfrequenz mit robusten Qualitätssicherungsverfahren (mehrstufige automatisierte Tests, gestaffelte Bereitstellungen, Funktionskennzeichnungen und Echtzeit-Überwachungsverfahren), die Teams bei einer häufigen Bereitstellung unterstützen und gleichzeitig das Risiko für die Benutzer minimieren.

Aus Sicht des Managements können durch die Verfolgung der Bereitstellungsfrequenz im Zeitverlauf Engpässe in der Bereitstellungspipeline der Software aufgedeckt werden. Ein Rückgang der Bereitstellungsfrequenz nach der Einführung eines neuen Genehmigungsgremiums könnte beispielsweise ein Hinweis darauf sein, dass der Prozess zu aufwendig ist. Auf der anderen Seite ist eine stetige Steigerung der Bereitstellungsfrequenz – gepaart mit sich verbessernden Zuverlässigkeitskennzahlen – ein starkes Indiz dafür, dass sich Investitionen in CI/CD-Pipelines und DevOps-Praktiken auszahlen.

Die Vorlaufzeit für Änderungen (auch Änderungsvorlaufzeit genannt) misst die Zeitspanne, die benötigt wird, bis eine Codeänderung nach dem Commit der Änderung im Hauptzweig des Codes in einem Versionskontrollsystem die Bereitstellung erreicht und erfolgreich in der Live-Produktion ausgeführt werden kann.

Dieses durchgängige Zeitfenster erfasst die Zeit für die Entwicklung, Testausführung, Code-Review, Genehmigungen, Pipeline-Phasen und die eigentliche Bereitstellung. Es zeigt, wie schnell ein System eine Entscheidung in eine konkrete Veränderung für die Endnutzer umsetzen kann.

Bei einer kurzen Vorlaufzeit (unter einer Stunde) können Unternehmen auf Vorfälle nahezu in Echtzeit reagieren. Wenn zum Beispiel ein Sicherheitsteam eine Sicherheitslücke beanstandet, kann das Technikteam Korrekturen implementieren, diese durch automatisierte Überprüfungen validieren und in kürzester Zeit umsetzen. Durch diesen schnellen Feedback-Kreislauf wird die Entwicklungsarbeit direkt mit den Geschäftsergebnissen verknüpft, da die Teams die Auswirkungen von Änderungen schnell messen und entsprechend reagieren können.

Um die Vorlaufzeit für Änderungen zu reduzieren, müssen DevOps-Teams fast immer die Delivery Pipeline automatisieren und vereinfachen. Dieser Prozess beinhaltet meist Investitionen in kontinuierliche Integration (CI) Tools, damit jeder Commit schnell erstellt und getestet wird, sowie die Optimierung der Genehmigungsprozesse, damit Genehmigungen in Workflows integriert werden.  

Die Wiederherstellungszeit bei fehlgeschlagenen Bereitstellungen, auch als mittlere Wiederherstellungszeit (MTTR) bezeichnet, bewertet, wie lange es dauert, bis ein Dienst nach einem Ausfall im Zusammenhang mit der Bereitstellung wieder normal verfügbar ist.

Zur Fehlerbehebung des Dienstes müssen Entwickler möglicherweise eine fehlerhafte Änderung rückgängig machen, einen Hotfix bereitstellen oder die Auswirkungen des Problems anderweitig abmildern, damit die Benutzer das System wieder normal verwenden können.

Eine kurze Wiederherstellungszeit (nur wenige Minuten) bedeutet meist, dass mehrere DevOps-Komponenten effektiv zusammenarbeiten.

Observability macht einen großen Unterschied. Echtzeit-Telemetriedaten – Metriken, Logs und Traces – werden vollständig aggregiert und in Dashboards zentralisiert. Vorfälle werden schnell (oft automatisch) und ohne Wartezeit auf Beschwerden von Benutzern erkannt.

Die Alarmierung ist so abgestimmt, dass die Techniker umgehend benachrichtigt, aber nicht von zu vielen Meldungen überflutet werden.

DevOps-Teams verlassen sich auf Runbooks (taktische Schritt-für-Schritt-Anleitungen zur Durchführung technischer Aufgaben), Playbooks (strategische Leitfäden auf höherer Ebene, die beschreiben, wie Teams auf eine Situation reagieren sollten) und dokumentierte Rollback-Verfahren. Diese Frameworks verhindern eine Überforderung in Bezug darauf, was während eines Ausfalls zu tun ist.

Lange Wiederherstellungszeiten (Stunden oder sogar Tage) deuten oft auf mangelhafte Betriebsabläufe hin. Die Erkennung kann unzureichend sein, sodass Produktionsausfälle so lange unentdeckt bleiben, bis sie von Kunden gemeldet werden. Die Diagnose ist ein langsamer Prozess, weil die Datenerfassung verstreut ist, Fehlermeldungen unklar sind oder Teams sich nicht einig sind, wie sich das System im Fehlermodus verhält. In solchen Umgebungen wird jeder Vorfall zu einem stressintensiven und risikoreichen Ereignis anstatt zu einer unkomplizierten Problemlösungsübung mit einem klaren Lösungsprotokoll.

In Kombination mit den anderen DORA-Metriken helfen niedrige Wiederherstellungszeiten bei fehlgeschlagenen Bereitstellungen sicherzustellen, dass selbst bei gelegentlichen Ausfällen der Fehler begrenzt wird und die Reaktionszeiten kurz ausfallen.

Die Fehlerrate bei Änderungen (Change Failure Rate, CFR) ist eine Metrik zur „Qualität der Bereitstellung“, die DevOps-Teams darüber informiert, wie häufig Bereitstellungen in Live-Produktionsumgebungen fehlschlagen. Jede problematische Produktionsbereitstellung, die das Team zu einem sofortigen Eingreifen zwingt – anstatt bis zur nächsten geplanten Veröffentlichung zu warten, um das Problem zu beheben – wird als „fehlgeschlagene“ Bereitstellung betrachtet.

Die Nachverfolgung der CFR hilft Teams mit der Zeit zu verstehen, wie zuverlässig sie Änderungen umsetzen, und dient als Gegengewicht zu Durchsatzmetriken (Bereitstellungsfrequenz, Vorlaufzeit für Änderungen), bei denen es auf die Geschwindigkeit ankommt.

Die CFR wird in der Regel als Prozentsatz ausgedrückt und berechnet, indem die Anzahl der fehlgeschlagenen Bereitstellungen durch die Gesamtzahl der Bereitstellungen im gleichen Zeitraum dividiert und dann mit 100 multipliziert wird.

Eine niedrige Fehlerrate bei Änderungen deutet darauf hin, dass ein Team Änderungen bereitstellt die sich in der Produktion im Allgemeinen wie erwartet verhalten. Wenn die CFR niedrig und stabil ist, können Teams die Bereitstellungsfrequenz gefahrlos erhöhen und die Vorlaufzeit für Änderungen verkürzen, ohne dass die Erfahrung beeinträchtigt wird.

Eine hohe Fehlerrate bei Änderungen deutet jedoch darauf hin, dass zu viele Änderungen das System destabilisieren. Ursachen können unvollständige oder unzuverlässige Tests, Phasen- und Testumgebungen sein, die sich von den Produktionsumgebungen unterscheiden, oder Bereitstellungen, die zu groß sind oder die Überwachung und Alarmierung verlangsamen. Ein hoher CFR-Wert signalisiert, dass das Unternehmen kleinere, schrittweise Änderungen und sicherere Bereitstellungspraktiken (wie z. B. Canary-Releases, bei denen eine neue App oder Funktion zunächst einer kleinen Gruppe von Benutzern zur Verfügung gestellt wird, bevor sie für den größeren Teil freigegeben wird) priorisieren sollte, damit weniger Änderungen zu Produktionsvorfällen führen.

Die Nachbearbeitungsrate bei der Bereitstellung ist eine Stabilitätskennzahl, die misst, welcher Anteil der Bereitstellungen eines Teams Nacharbeiten erfordert. Mit „Nachbearbeitung“ ist jede Bereitstellung gemeint, die durch einen für den Benutzer sichtbaren Fehler oder Vorfall in der Produktion ausgelöst wird und nicht Teil des ursprünglich geplanten Release-Zyklus ist.

Die Nachbearbeitungsrate bei der Bereitstellung ergänzt die ursprünglichen vier DORA-Metriken, indem sie reaktive Arbeit sichtbar macht. Sie zeigt, wie viel Entwicklungsaufwand ein Team für die Behebung vergangener Fehler aufwendet, anstatt das Produkt weiterzuentwickeln.

Eine niedrige Nachbearbeitungsrate deutet im Allgemeinen darauf hin, dass DevOps-Teams die meisten Probleme erkennen, bevor sie die Endbenutzer erreichen, und den größten Teil ihrer Zeit mit wertschöpfenden Arbeiten (geplante Optimierungen und Refaktorierungen) verbringen. Eine hohe Nachbearbeitungsrate bedeutet, dass Teams zu viel Zeit mit dem Lösen akut auftretender Aufgaben verbringen.

Die Nachbearbeitungsrate bei der Bereitstellung ist besonders wertvoll, wenn sie mit anderen wichtigen Metriken kombiniert wird. Wenn ein Team beispielsweise eine hohe Bereitstellungsfrequenz und eine geringe Nachbearbeitungsrate aufweist, wird signalisiert, dass das Team neue Software-Iterationen schnell bereitstellt, ohne die Qualität zu beeinträchtigen. Wenn das Team jedoch eine hohe Bereitstellungsfrequenz bei gleichzeitig hoher Nachbearbeitungsrate aufweist, deutet das darauf hin, dass es viel Code liefert, aber auch viel Zeit mit der Fehlerbehebung verbringt.

Wichtig ist, dass eine Nachbearbeitungsrate ungleich Null normal (und oft sogar gesund) ist. Selbst die besten Entwicklungsteams können Fehler machen, und gut entwickelte Anwendungen benötigen im Laufe der Zeit Verbesserungen und Funktionsupdates. Das Ziel ist nicht, 0 % Nachbearbeitung zu erreichen, sondern den Nachbearbeitungsanteil auf einen kleinen, vorhersehbaren Prozentsatz aller Bereitstellungen zu begrenzen.

Für alle DORA-Metriken werden Teams in eine von vier Leistungstufen eingeteilt – Elite, hoch, mittel oder niedrig – wobei jede Stufe auf festgelegten Schwellenwerten für die Metriken basiert. Die Schwellenwerte sind:

Da die Nachbearbeitungsrate bei der Bereitstellung eine neuere Metrik ist, gibt es dafür noch keine festgelegten Schwellenwerte oder Leistungsstufen. Viele Unternehmen und DevOps-Teams verfolgen jedoch ihre eigenen Nachbearbeitungs-Baselines und streben eine Abwärtstendenz im Laufe der Zeit an. Durch die Verwendung von Daten zur Nachbearbeitungsrate zusammen mit der Änderungsfehlerrate und anderen Zuverlässigkeitsmetriken können Teams die Nachbearbeitungsraten bei der Bereitstellung verbessern, ohne auf der Grundlage einer einzigen Zahl Überkorrekturen vorzunehmen. 

DORA-Metriken unterstützen den umfassenderen DevOps-Ansatz für die Softwareentwicklung, der der kontinuierlichen Zusammenarbeit zwischen multidisziplinären Teams in den Bereichen App-Entwicklung und Betriebsfunktionen Priorität einräumt. DevOps-Umgebungen können nur so erfolgreich sein wie die Teams, aus denen sie bestehen.

DORA-Metriken ermöglichen es Unternehmen, die Leistung von Teams anhand von Kriterien zu quantifizieren, die eng mit den übergeordneten Wertschöpfungsketten und Geschäftsergebnissen verknüpft sind. Zum Beispiel erreichen High-Performer und Elite-Performer mit größerer Wahrscheinlichkeit ihre Ziele in Bezug auf Rentabilität, Markteinführungszeit und Kundenzufriedenheit.

DevOps-Kulturen zeichnen sich zudem durch das Bekenntnis zu freier Kommunikation und geteilter Verantwortung unter den Stakeholdern der Softwarebereitstellung aus, die gemeinsam daran arbeiten, eine hochwertige Software zu entwickeln und Innovationen zu beschleunigen. Daher nutzen viele Unternehmen DORA-Metriken als Feedback-Schleife zur kontinuierlichen Verbesserung. Die Metriken messen die Leistung jedes Teams. Die Teams können anhand der Messungen über Verbesserungsmöglichkeiten diskutieren, mit neuen Ansätzen experimentieren und die Leistung erneut messen, um zu sehen, welche Änderungen die Bereitstellungspraktiken tatsächlich verbessern.

Wichtig ist, dass DORA-Metriken diagnostisch und nicht strafend eingesetzt werden. Sie helfen dabei, systemische Muster in Entwicklungsprozessen aufzudecken, anstatt sich auf die Arbeit einzelner Entwickler zu konzentrieren.