Verbesserte Prozesse und schnelle, stabile Bereitstellung — das ist es, was Sie erhalten, wenn Sie beginnen, die Leistung Ihres Teams mit DORA-Metriken zu messen. Erfahren Sie, wie die einzelnen Kennzahlen funktionieren, und legen Sie den Weg fest, um die Leistung Ihres Teams und die Geschäftsergebnisse zu steigern.
A QUICK SUMMARY – FOR THE BUSY ONES
Die vier DORA-Metriken sind wird von DevOps-Teams verwendet, um ihre Leistung zu visualisieren und zu messen. Sie stehen für die Geschwindigkeit und Stabilität des Einsatzes. Die Kennzahlen ermöglichen es den Teamleitern, Maßnahmen zur Optimierung der Prozesse und zur Steigerung des Produktwerts zu ergreifen.
TABLE OF CONTENTS
DORA-Metriken geben eine Überblick über die Leistung eines Teams, sodass beurteilt werden kann, wie gut das Team Geschwindigkeit und Stabilität ausbalanciert, und Bereiche mit Verbesserungspotenzial identifiziert werden.
Dies ermöglicht es führenden Ingenieuren, Prozesse kontinuierlich zu rationalisieren und die Geschwindigkeit zu erhöhen, mit der Kundennutzen erzielt wird. Dies ist entscheidend, damit ein Produkt wettbewerbsfähig bleibt.
Lassen Sie uns diese Metriken aufschlüsseln und analysieren, wie Sie sie einfach implementieren können.
DORA-Metriken sind vier Indikatoren, die verwendet werden, um die Effizienz des DevOps-Teams berechnen. Sie messen die Leistung eines Teams und bieten einen Bezugspunkt für Verbesserungen. Sie helfen auch dabei, datengestützte Entscheidungen zu treffen.
Die Metriken wurden von einer von Google zusammengestellten Organisation namens DevOps Research and Assessment (DORA) erfunden. Sie befragten Tausende von Entwicklungsteams aus verschiedenen Branchen, um zu verstehen, was ein leistungsstarkes Team von den anderen unterscheidet. Die Festlegung von DORA-Metriken ist das Ergebnis dieser Forschung.
Die DORA-Metriken wurden zum ersten Mal im Bericht der DORA-Organisation erklärt Beschleunigt: Stand von DevOps 2018. Der Bericht wird regelmäßig veröffentlicht die neueste Version wurde 2021 veröffentlicht.
<span class="colorbox1" fs-test-element="box1"><p>Wichtiger Imbiss:</p><p>DORA-Metriken zeigen welches Leistungsniveau ist erforderlich, um die gewünschten Geschäftsziele zu erreichen</p></span>.
Die Kennzahlen spiegeln wichtige Bereiche wider, die die Leistung beeinflussen, und geben Ingenieuren detaillierte Einblicke.
Durch die Messung der Entwicklungsgeschwindigkeit und der Stabilität der Bereitstellung und des Produkts selbst werden die Teams motiviert, ihre Ergebnisse in nachfolgenden Iterationen zu verbessern. Und sie zu verbessern führt zu besseren Geschäftsergebnissen.
DORA verwendet seine Metriken, um Elite-, High-, Medium- und Low-Performance-Teams zu identifizieren. Sie behaupten, dass Elite-Teams mit doppelt so hoher Wahrscheinlichkeit die Leistungsziele der Organisation erreichen oder übertreffen.
DORA-Metriken machen den Prozess der Softwarebereitstellung transparenter und verständlicher und zerlegen ihn in Teile.
DORA-Metriken helfen Teams dabei:
<span class="colorbox1" fs-test-element="box1"><p>Hinweis:</p>Die <p>Implementierung der DORA-Metriken und der gesamten DevOps-Kultur ist auch einer der Indikatoren für die besten Devshops. Achten Sie währenddessen auf diesen Aspekt Auswahl eines externen Softwareentwicklungsunternehmens um damit zu arbeiten.</p></span>
Auf der höchsten Ebene messen Bereitstellungshäufigkeit und Vorlaufzeit für Änderungen die Geschwindigkeit, während die Änderungsausfallrate und die Zeit bis zur Wiederherstellung des Service die Stabilität messen.
Die Metrik „Bereitstellungshäufigkeit“ bezieht sich auf die Häufigkeit erfolgreicher Softwareveröffentlichungen. Sie misst wie oft ein Unternehmen erfolgreich Code in der Produktion einsetzt für eine bestimmte Anwendung.
Häufigkeit der Bereitstellung zeigt die Konsistenz und Geschwindigkeit der Softwarebereitstellung. Es bestimmt, ob ein Team die Ziele einer kontinuierlichen Bereitstellung erreicht.
Kleinere und häufigere Bereitstellungen sind das Ziel, aber die effektivste Anzahl von Bereitstellungen ist von Produkt zu Produkt unterschiedlich. Um den Code schnell an die Produktion zu liefern, müssen Sie ihn so oft wie möglich versenden und gleichzeitig die Chargengröße so ändern, dass sie so klein wie möglich ist.
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtigstes Fazit:</strong></p> <p>Durch den häufigen Einsatz kann das Team das Produkt ständig verbessernund Probleme leichter erkennen.</p></span>
Verschiedene Tools messen die Bereitstellungshäufigkeit, indem sie berechnen, wie oft ein Team eine Bereitstellung für die Produktion abschließt und Code für Endbenutzer freigibt.
Um die Häufigkeit zu messen, berechnen Sie die durchschnittliche Anzahl der Tage pro Woche mit mindestens einer erfolgreichen Bereitstellung.
Die Bereitstellungshäufigkeit zeigt, wie gut Ihr aktueller Prozess funktioniert.
von Erkennung bestimmter Zeiträume, in denen sich die Bereitstellung verzögert, können Sie Probleme in einem Arbeitsablauf, unnötige Schritte oder Probleme mit Tools identifizieren. Sie können auch Probleme wie Personalmangel oder die Notwendigkeit längerer Testzeiten erkennen.
Die Bereitstellungshäufigkeit ermöglicht es auch, die Bereitstellungsgeschwindigkeit im Laufe der Zeit zu vergleichen und die Liefergeschwindigkeit Ihres Teams abzubilden.
Für eine niedrige Bereitstellungshäufigkeit kann es mehrere Gründe geben, die häufig mit dem Prozess und den Tools zusammenhängen:
Um die Lieferfähigkeit Ihres Teams zu verbessern, versuchen Sie:
Die Vorlaufzeit für Änderungen zeigt an wie lange es dauert, vom festgeschriebenen Code zum Code zu gelangen, der erfolgreich in der Produktion ausgeführt wird. Zusammen mit der Bereitstellungshäufigkeit misst es die Geschwindigkeit der Softwarebereitstellung.
Lead Time for Changes ermöglicht es uns zu verstehen, wie die Zykluszeit des DevOps-Teams aussieht und wie das Team mit einer erhöhten Anzahl von Anfragen umgeht.
Das Team sollte sich um die niedrige Vorlaufzeit für Änderungen bemühen je niedriger es ist, desto effizienter kann ein Team Code bereitstellen. Das bedeutet, dass ein Team schneller auf Feedback reagieren und den Kurs schnell korrigieren kann. Fehler werden höchstwahrscheinlich schnell behoben.
Um die Vorlaufzeit für Änderungen zu messen, benötigen Sie zwei Daten:
Verwenden Sie dann die durchschnittliche Zeit als Indikator für die Gesamtleistung. Die Vorlaufzeit für Änderungen ist ein Näherungswert.
Die Vorlaufzeit für Änderungen ist ein Indikator für wie schnell ein Team auf Bedürfnisse und Lösungen reagiert. Es steht für die Effizienz des Prozesses, die Komplexität des Codes und die Kapazität des Teams.
Die Metrik hilft zu verstehen, wie lange es dauert, bis Änderungen an der Produktion vorgenommen werden. Wenn die Vorlaufzeit für Änderungen zu hoch ist, zeigt dies Ineffizienzen und Engpässe im Prozess. Ein niedriger Wert zeigt, dass ein Team schnell auf Feedback reagiert und sich Änderungen schnell vollzieht
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtigste Erkenntnis:</strong></p> <p>Das Ziel des Teams sollte es sein, die Vorlaufzeit für Änderungen zu verkürzen und rechtzeitig auf Probleme zu reagieren</p>.</span>
Diese Kennzahl ist auch bei der Arbeit mit Kunden unerlässlich, die es vorziehen, mit einem Team zusammenzuarbeiten, das innerhalb weniger Stunden auf dringende Bugfixes reagiert. Wenn Sie schnell Änderungen vornehmen, sind die Kunden zufrieden.
Eine hohe Vorlaufzeit für Änderungen wird meistens durch ineffiziente Prozesse und die Einführung zu großer Änderungen in der Produktion verursacht. Andere Gründe sind:
Um die Vorlaufzeit für Änderungen zu reduzieren, versuchen Sie:
Mittlere Zeit bis zur Wiederherstellung, Zeit bis zur Wiederherstellung oder Zeit bis zur Wiederherstellung des Dienstes. Diese Metrik hat viele Namen. Aber was am wichtigsten ist, sie misst wie lange es in der Regel dauert, den Service wiederherzustellen, wenn ein Servicefall oder ein Defekt auftritt, der sich auf die Benutzer auswirkt.
Einfach ausgedrückt ist es die Zeit, die ein Dienst benötigt, um nach einem Ausfall wieder auf die Beine zu kommen.
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtiges Fazit:</strong></p> <p>Misserfolge können also nicht vermieden werden Was einen Unterschied macht, ist, wie schnell ein System wiederhergestellt oder wiederhergestellt werden kann</p></span>.
Die Zeit bis zur Wiederherstellung wird berechnet, indem die durchschnittliche Zeit zwischen einem Fehlerbericht und dem Zeitpunkt, an dem der Fix bereitgestellt wird, aufgezeichnet wird.
Die Formel dafür könnte so aussehen:
durchschnittlicher Zeitstempel (Vorfall wurde behoben) ﹣ durch den Vorfall wurde ein Zeitstempel erstellt).
Zeit für die Wiederherstellung des Dienstes gibt die Reaktionszeit und Effizienz des Entwicklungsprozesses eines Teams an.
Wenn der Time to Restore Service zu hoch ist, kann dies auf einen ineffizienten Prozess, einen Mangel an Mitarbeitern oder eine unzureichende Teamstruktur hinweisen. Wenn sie niedrig ist, zeigt das, dass ein Team schnell reagiert und Probleme löst. Der Low Time to Restore Service gewährleistet die Verfügbarkeit und das korrekte Funktionieren der Software.
Das Ziel des Teams sollte es sein, die Zeit bis zur Erholung zu reduzieren. Wenn es dann zu einem Vorfall kommt, kann ein Team ihn rechtzeitig beheben, sodass Die Verfügbarkeit der Software wird nicht beeinträchtigt.
Es gibt verschiedene Aspekte, die die Zeit bis zur Wiederherstellung des Dienstes verlängern können:
Gehen Sie wie folgt vor, um die Zeit bis zur Wiederherstellung des Dienstes zu verkürzen:
Kennzahlen zur Ausfallrate ändern der Prozentsatz der Bereitstellungen, die zu Produktionsausfällen führen der Code, der dann zu Vorfällen, Rollbacks oder anderen Fehlern geführt hat.
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtigste Erkenntnis:</strong></p> Die <p>Änderungsausfallrate ist ein Maß für die Stabilität und Qualität der Softwarebereitstellung</p>.</span>
Change in Failure Rate ist von den Lean-Prinzipien inspiriert. Im Laufe der Zeit bietet die Metrik Einblicke darüber, wie viel Zeit für die Behebung von Fehlern im Vergleich zur Bereitstellung von neuem Code aufgewendet wird.
Die Änderung der Ausfallrate wird berechnet, indem die Anzahl der Bereitstellungsfehler gezählt und durch die Gesamtzahl der Bereitstellungen geteilt wird.
Die Ausfallrate ändern wird angezeigt wie gut ein Team die Sicherheit der am Code vorgenommenen Änderungen garantiert und wie es Bereitstellungen verwaltet. Es ist ein Indikator für die Fähigkeiten und die Prozesseffizienz eines Teams.
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtiges Fazit:</strong></p> <p>Die Metrik zeigt auch wie viel Entwickler-Zeit für Aufgaben aufgewendet wird, die nicht zum Geschäftswert beitragen</p></span>.
Eine hohe Änderungsfehlerrate weist auf Probleme im Entwicklungsprozess oder auf fehlende Tests vor der Bereitstellung hin.
Eine niedrige Change Failure Rate zeigt, dass ein Team Infrastrukturfehler und Bugs identifiziert, bevor der Code bereitgestellt wird. Dies ist ein Zeichen für einen soliden Bereitstellungsprozess und die Bereitstellung qualitativ hochwertiger Software.
Das Ziel des DevOps-Teams sollte es sein, die Change Failure Rate zu reduzieren stellen Sie die Verfügbarkeit und das korrekte Funktionieren der Software sicher.
Hinter der hohen Change Failure Rate stehen oft Ineffizienzen beim Testen. Sie wird auch verursacht durch:
Wenn Ihre Änderungsfehlerrate hoch ist, stellen Sie Folgendes sicher:
<span class="colorbox1" fs-test-element="box1"><p>Zu viele Berechtigungen? Entdecken wie die CASL-Bibliothek die Rechteverwaltung Ihrer Webanwendung vereinfachen kann mit seinem intuitiven und flexiblen Ansatz.</p></span>
<span class="colorbox1" fs-test-element="box1"><p><strong>Wichtiger Imbiss:</strong></p> <p>Die Verbesserung der Kennzahlen sollte nicht das Ziel an sich sein. Das ultimative Ziel, auf das sich die Teams konzentrieren müssen, ist die Verbesserung der Art und Weise, wie sie ein Produkt liefern, um seinen Wert schneller und stabiler zu steigern.</p></span>
Es gibt verschiedene Tools, die bei der Implementierung von DORA-Metriken helfen:
Um Teams bei der Generierung dieser Kennzahlen zu unterstützen, DORA schuf die Vier Schlüssel Open-Source-Projekt. Es richtet automatisch eine Datenaufnahme-Pipeline ein und ruft Daten aus den Github- oder Gitlab-Repositorys der Teams über Google Cloud und Google Data Studio ab.
Das Four Keys-Projekt aggregiert Daten und fasst sie anhand von vier Schlüsselkennzahlen in einem Dashboard zusammen. Sie können den Fortschritt im Laufe der Zeit verfolgen, ohne zusätzliche Tools verwenden oder selbst Lösungen erstellen zu müssen.
Für einige Unternehmen werden DORA-Metriken zu einem Ausgangspunkt werden, der dann an ihr Projekt angepasst werden muss.
Achten Sie bei der Implementierung auf:
Eines der größten Probleme ist auch das Verhältnis zwischen Geschwindigkeit und Stabilität der Bewertung. Um Fehler zu vermeiden, müssen Sie einzelne Kennzahlen immer in einen Kontext stellen. Eine hohe Bereitstellungshäufigkeit sagt nichts über die Qualität eines Produkts aus. Um die Qualität zu beurteilen, ist eine Change Failure Rate ein guter Indikator.
Es geht nicht nur darum, ein Elite-Performer zu werden. Es geht darum, schneller einen besseren Geschäftswert zu erzielen.
Durch das Messen und Verfolgen von DORA-Metriken und -Trends können Teams bessere, fundiertere Entscheidungen darüber treffen, was verbessert werden kann, und verstehen, wie das geht. Wenn sich die DORA-Metriken verbessern, kann ein Team sicher, dass sie gute Entscheidungen treffen und mehr Wert bieten für Kunden und Nutzer eines Produkts.
Als technische Führungskraft müssen Sie Ihr Team mit Tools ausstatten, um dies zu erreichen.
DORA-Metriken können Ihnen helfen, Ihre DevOps-Leistung zu steigern, indem sie Geschwindigkeit und Stabilität erhöhen, aber Ihr Team kann noch bessere Produkte entwickeln nach der Implementierung des BizDevOps-Ansatz. BizDevOps durchbricht nicht nur die Grenzen zwischen Entwicklern und Operations, sondern auch zwischen Unternehmen. Es ermöglicht Teams, fundiertere Entscheidungen zu treffen, beschleunigt die Feedback-Schleife und führt dazu, dass Produkte entwickelt werden, die die Geschäftsanforderungen effizienter erfüllen.
<span class="colorbox1" fs-test-element="box1"><p><strong>Brauchen Sie Hilfe?</strong></p> <p>Sie müssen nicht alles selbst herausfinden. Lass uns chatten über die Implementierung von DORA-Metriken und beschleunigen Sie gemeinsam Ihr Wachstum.</p></span>
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Enthusiast für Softwareentwicklung mit 8 Jahren Berufserfahrung in der Technologiebranche. Erfahrung im Outsourcing von Marktanalysen, mit besonderem Schwerpunkt auf Nearshoring. In der Zwischenzeit unser Experte darin, technische, geschäftliche und digitale Themen auf verständliche Weise zu erklären. Autor und Übersetzer nach Feierabend.
Enthusiast für Softwareentwicklung mit 8 Jahren Berufserfahrung in der Technologiebranche. Erfahrung im Outsourcing von Marktanalysen, mit besonderem Schwerpunkt auf Nearshoring. In der Zwischenzeit unser Experte darin, technische, geschäftliche und digitale Themen auf verständliche Weise zu erklären. Autor und Übersetzer nach Feierabend.
Read next
Popular this month
previous article in this collection
It's the first one.
