Gezielt besser werden mit DORA-Metriken und DORA-Core
Das "DevOps research und assessment program" hat wissenschaftlich herausgearbeitet wie DevOps Teams performant werden können. Wir zeigen, was DORA so besonders macht.
Was ist DORA und warum ist es so besonders?
DORA ist die Abkürzung für “DevOps Research and Assessment”, also Forschung zu und Bewertung von DevOps. Als eigenständiges Unternehmen von Gene Kim, Jez Humble und Dr. Nicole Forsgren gegründet, wurde es 2018 von Google übernommen und wird unter dieser Schirmherrschaft weiter betrieben. Die große Leistung von DORA ist es, Methoden aus der Forschung auf das Feld von DevOps zu übertragen. Auf der Grundlage von 8 Jahren Forschung und Daten von mehr als 33.000 Fachleuten weltweit haben Sie 4 Schlüsselmetriken identifiziert, die die Leistung eines DevOps-Teams anzeigen. Aber wie sind Sie vorgegangen ? In groß angelegten Umfragen wurden Fachleute aus Unternehmen aller Branchen nach Ihren DevOps-Prozessen und -techniken befragt, aber auch nach dem Unternehmenserfolg, z.B. gemessen an Profitabilität und Marktanteil. Danach wurden DevOps-Metriken mit dem Unternehmenserfolg korreliert, d.h. geschaut bei welchen DevOps-Metriken die erfolgreichen Unternehmen gut abschneiden. Die Schlussfolgerung ist, dass diese Metriken (bzw. Prozesse und Tools, die diese Metriken verbessern) sich positiv auf den Unternehmenserfolg auswirken.
In der Software-Branche ist diese Methode die fundierteste, die es gibt - In anderen Büchern oder Talks besprechen einzelne Personen ihre eigenen Erfahrungen und leiten daraus allgemeingültige Regeln ab. Da kann natürlich etwas dran sein, aber es ist doch sehr dünn gegenüber Befragungen von über 30.000 Personen!
Hier der Überblick über die vier Metriken, danach geht es in die Details.
Die DORA Metriken im Überblick. Wo steht dein Team? (Aus dem 2022 State of Devops Report)
Wichtig ist, dass erfolgreiche Unternehmen in allen vier Metriken Spitzenreiter sind. Es genügt also nicht, schnell Änderungen in Produktion bringen zu können (Vorlaufzeit), aber dabei eine hohe Fehlerquote in Kauf zu nehmen. Das ist irgendwie auch logisch - Die ersten beiden Metriken messen ja Geschwindigkeit, die letzten beiden Qualität. Nur wenn beides stimmt, funktioniert DevOps!
Bereitstellungshäufigkeit - Deployment Frequency
Die Bereitstellungshäufigkeit beschreibt, wie oft eine Änderung in die Produktionsumgebung eingebracht wird. Dabei ist die Art der Änderung irrelevant. Es kann sich um eine große neue Funktion, einen Bugfix oder auch das Beheben eine Tippfehlers in der Online-Dokumentation handeln. Wichtig: Wir zählen nur Änderungen, die wirklich das Produktionssystem erreichen - Was auf Test- oder Stagingsystemen läuft ist irrelevant.
Je nach Entwicklungsprozess ist die Bereitstellungshäufigkeit unterschiedlich.
Vorlaufzeit für Änderungen - Lead Time for Changes
Hier wird gemessen wir lange eine Änderung benötigt, bis sie in der Produktionsumgebung aktiv ist. Als Startzeitpunkt wird in der Regel der Zeitpunkt des Commits, also das Speicherns des Source-Codes im Versionskontrollsystems, festgelegt. Warum? Alles was vorher passiert (Designarbeit oder Problemanalyse) ist technisch nicht messbar. Das nennt man auch das ‘Fuzzy Frontend’-Problem.
Wie lange benötigt ein commit, bis er die Produktionsumgebung erreicht?
Warum brauche ich Bereitstellungshäufigkeit und Vorlaufzeit? Nun, die Häufigkeit hängt natürlich von der Teamgröße ab. Ein großes Team wird in der Regel auch öfter deployen. Die Vorlaufzeit kann aber auch bei kleinen Teams sehr hoch sein, wenn diese effizient arbeiten.
Zeit bis zur Dienstwiederherstellung - Mean Time to Recover
Das sollte klar sein - Wenn mein Dienst bzw. meine Anwendung einmal nicht verfügbar sein sollte (‘down’), dann ist das Lösen dieses Problems erste Priorität. Hier finde ich besonders verwunderlich, dass selbst mittelgute Teams über einen Tag benötigen, um bei einem Ausfall (im Mittel) den Dienst wiederherzustellen. Das erscheint mit sehr lange! Wann ist der Dienst wieder erreichbar?
Änderungsfehlerquote - Change Failure Rate
Diese Metrik zeigt an, wie oft eine Änderung zu einem gravierenden Fehler führt - Gravierend bedeutet hier, das außerordentliche Massnahmen in Gang gesetzt werden müssen, um ihn zu beheben. Das könnte ein Hotfix oder auch ein Rollback auf eine vorherige Version sein. Wichtig ist, das hier die Quote betrachtet wird, also das Verhältnis fehlerhafter Deployments zu allen. Wer also eine hohe Bereitstellungshäufigkeit an den Tag legt, der wird auch bei der vierten Metrik gut aussehen.
Änderungsfehlerquote und Bereitstellungshäufigkeit hängen zusammen.
Was nun?
Wir haben nun die vier Metriken kennen gelernt, aber was nun? Die Metriken an sich bieten ja noch keinen Mehrwert, sie schaffen nur Transparenz. Also:
- Der DORA Quick-Check ist ein kurzer Fragebogen für eine gute Orientierung. Noch besser, er bietet Vorschläge auf welchem Gebiet man investieren sollte um sich bei den Metriken zu verbessern. Das kann z.B. Automatisierung oder Testing sein, je nach dem, wie man geantwortet hat.
- Die Vorschläge aus dem Quick-Check verweisen immer auf einen Teil vom DORA-Core. Hier kann man nachlesen, welche Best-Practices von erfolgreichen Unternehmen angewandt werden, die sich positiv auf die DORA-Metriken auswerten:
DORA-Core
Zu jeder Capability gibt es eine sehr gute Beschreibung, Implementierungstipps und mögliche Stolpersteine. Extrem wertvoll.
Fazit
DORA Metriken und DORA-Core bieten alles um ein Entwicklungsteam auf dem Weg zur stetigen Verbesserung und letztlich zur High-Performance zu bringen. Es ist wissenschaftlich, umfassend und hat eine wachsende Community. Jeder, wirklich jeder, der im DevOps- oder Software-Engineering-Bereich arbeitet sollte sich damit einmal auseinander gesetzt haben. Falls du noch Fragen zu DORA hast oder Verbündete für eine Mögliche Implementierung suchst - Dafür sind wir da.
