Was sind DORA-Metriken und wie wirken sie sich auf den DevOps-Erfolg aus?

DORA-Metriken sind vier Schlüsseldimensionen, die Teamleitern helfen, die Effektivität ihrer DevOps-Praktiken zu verstehen. Das Team von DevOps Research and Evaluation (DORA) hat die Metriken nach sechs Jahren Forschung zur erfolgreichen Implementierung von DevOps entwickelt.

Das Messen von Daten ist der beste Weg, um die Auswirkungen von DevOps auf Ihr Unternehmen zu bewerten. Die Fokussierung auf die von DORA identifizierten Aspekte kann Möglichkeiten eröffnen, Ihre Prozesse zu rationalisieren und die Effizienz zu verbessern. In diesem Artikel erklären wir, wie jede der vier Metriken zum Erfolg von DevOps beiträgt.

Bereitstellungshäufigkeit

Die Bereitstellungshäufigkeit misst, wie oft Sie neuen Code in die Produktion übertragen. Da das Hauptziel von DevOps darin besteht, funktionierenden Code effizienter bereitzustellen, ist die Bereitstellungshäufigkeit ein guter Ausgangspunkt für die Erfolgsmessung.

Sie können diese Daten einfach sammeln, indem Sie analysieren, wie oft neuer Code in einem bestimmten Zeitraum bereitgestellt wurde. Sie können dann nach Möglichkeiten suchen, Ihre Freisetzungsrate zu erhöhen, ohne Zäune zu opfern, die Qualitätsstandards einhalten. Die Verwendung von Continuous Delivery zur automatischen Bereitstellung von Code beim Zusammenführen ist eine Möglichkeit, Ihren Workflow zu beschleunigen.

Die ideale Bereitstellungshäufigkeit hängt von der Art des Systems ab, das Sie aufbauen. Obwohl Webanwendungen heutzutage normalerweise mehrmals täglich bereitgestellt werden, ist diese Häufigkeit nicht für Spieleentwickler geeignet, die Multi-Gigabyte-Builds erstellen.

In manchen Situationen kann es hilfreich sein, diesen Unterschied zu erkennen, indem man etwas anders über die Bereitstellungshäufigkeit nachdenkt. Sie können es sich als die Häufigkeit vorstellen, mit der Sie Code bereitstellen könnten, wenn Sie die Veröffentlichung einer neuen Version zu einem bestimmten Zeitpunkt reduzieren möchten. Dies kann eine effizientere Methode zur Messung des Durchsatzes sein, wenn echte Continuous Delivery für Ihr Projekt nicht geeignet ist.

Vorlaufzeit ändern

Die Änderungsvorlaufzeit ist das Intervall zwischen dem Festschreiben einer Codeversion und deren Freigabe für die Produktion. Diese Metrik zeigt die Verzögerungen, die während Codeüberprüfungen und Iterationen auftreten, nachdem die Entwickler den ursprünglichen Sprint abgeschlossen haben.

Dieser Wert lässt sich leicht messen. Sie müssen den Zeitpunkt finden, zu dem der Entwickler die Änderung signiert hat, und dann den Zeitpunkt, zu dem der Code an die Benutzer übermittelt wurde. Die Ausführungszeit ist die Anzahl von Stunden und Minuten zwischen den beiden Werten.

Betrachten Sie als Beispiel eine einfache Änderung zum Senden einer Sicherheitswarn-E-Mail, nachdem sich Benutzer angemeldet haben. Der Entwickler schließt die Aufgabe um 11:00 Uhr ab und übergibt seine Arbeit an das ursprüngliche Repository. Um 12:00 Uhr liest der Prüfer den Code und übermittelt ihn an die QA. Um 14:00 Uhr bemerkte ein QA-Tester einen Tippfehler in der Kopie der E-Mail. Der Entwickler schreibt den Fix um 15:00 Uhr fest, und QA nimmt um 16:00 Uhr die endgültige Änderung an der Produktion vor. Die Zeit zum Abschließen dieser Änderung betrug 5 Stunden.

Die Laufzeit wird verwendet, um Ineffizienzen aufzudecken, wenn die Arbeit zwischen Elementen verschoben wird. Während die Standards je nach Branche und Organisation stark variieren, kann eine lange durchschnittliche Vorlaufzeit ein Hinweis auf interne Reibung und einen schlecht gestalteten Arbeitsablauf sein. Eine erhöhte Ausführungszeit kann auch durch eine schlechte Leistung von Entwicklern verursacht werden, die als erste Iteration einer Aufgabe qualitativ minderwertige Arbeit leisten.

Einige Organisationen verwenden unterschiedliche Vorlaufzeitmessungen. Viele entscheiden sich für die Zeit, die vergeht, bis ein Entwickler ein Feature startet und der endgültige Code in Produktion geht. Andere schauen vielleicht noch weiter und nehmen als Ausgangspunkt den Zeitpunkt, zu dem die Änderung vom Kunden, Kunden oder Produktmanager angefordert wurde.

Diese Methoden können Informationen liefern, die innerhalb des Unternehmens außerhalb von Ingenieurteams von größerem Nutzen sind. Das Interpretieren von DORA mithilfe von Commit-Zeitstempeln hat jedoch einen großen Vorteil: Die Daten werden automatisch von Ihrem Versionskontrolltool festgeschrieben, sodass Entwickler die Startzeit für jede neue Aufgabe nicht manuell aufzeichnen müssen.

Absprungrate ändern

Die Änderungsfehlerrate ist der Prozentsatz der Produktionsbereitstellungen, die einen Vorfall verursacht haben. Ein Vorfall ist jeder Fehler oder jedes unerwartete Verhalten, das zum Absturz oder Ausfall von Clients führt. Entwickler und Betreiber müssen Zeit aufwenden, um das Problem zu lösen.

Sie können den Prozentsatz der fehlgeschlagenen Änderungen berechnen, indem Sie die Anzahl der von Ihnen durchgeführten Bereitstellungen durch die Anzahl der fehlgeschlagenen Änderungen dividieren. Die letztere Bedeutung wird normalerweise erreicht, indem Fehlerberichte in Ihrer Deployment-Projektmanagementsoftware mit demjenigen markiert werden, der sie eingereicht hat.

Es kann manchmal schwierig sein, Vorfälle genau der Änderung zuzuordnen, die sie verursacht hat, insbesondere wenn Sie eine hohe Bereitstellungshäufigkeit haben, aber in vielen Fällen können Entwickler und Triage-Teams den wahrscheinlichsten Auslöser bestimmen. Ein weiteres Problem könnte darin bestehen, sich darauf zu einigen, was einen Fehler ausmacht: Sollten geringfügige Fehler die Fehlerhäufigkeit erhöhen, oder interessieren Sie sich nur für größere Fehler? Beide Arten von Problemen wirken sich darauf aus, wie Kunden Ihren Service wahrnehmen, daher kann es sinnvoll sein, mehrere unterschiedliche Werte für diese Metrik beizubehalten, die sich jeweils auf unterschiedliche Klassen von Problemen beziehen.

Sie sollten stets danach streben, die Ausfallrate so gering wie möglich zu halten. Der Einsatz automatisierter Tests, statischer Analysen und kontinuierlicher Integration kann dazu beitragen, dass fehlerhafter Code nicht in die Produktion gelangt. Schützen Sie Ihre Prozesse mit neuen Tools und Verfahren, um Ausfälle im Laufe der Zeit schrittweise zu reduzieren.

Zeit, den Dienst wiederherzustellen

Leider ist es unmöglich, Ausfälle vollständig auszumerzen. Irgendwann werden Sie auf ein Problem stoßen, das Ihren Kunden schaden wird. Die vierte DORA-Metrik, Time to Restore Service, analysiert, wie effektiv Sie auf diese Ereignisse reagieren können.

Wie bei sich ändernden Vorlaufzeiten kann die gemessene Vorlaufzeit je nach Organisation variieren. Einige Befehle verwenden die Zeit, zu der der Fehler bereitgestellt wurde, andere stammen aus dem ersten Clientbericht, und einige verwenden möglicherweise die Zeit, zu der das Incident-Response-Team an die Seite gesendet wurde. Welchen Triggerpunkt Sie auch wählen, Sie müssen ihn konsequent verwenden und weiter messen, bis der Vorfall als behoben markiert ist.

Eine hohe MTTR ist ein Signal dafür, dass Ihre Incident-Response-Prozesse fein abgestimmt werden müssen. Eine wirksame Reaktion hängt davon ab, ob die richtigen Mitarbeiter das Problem identifizieren, eine Lösung entwickeln und mit den betroffenen Kunden kommunizieren. Sie können die Wiederherstellungszeit verkürzen, indem Sie konsistente Reaktionsverfahren entwickeln, den Zugriff auf wichtige Informationen in Ihrer gesamten Organisation zentralisieren und eine automatisierte Überwachung implementieren, um Sie bei Problemen zu warnen, sobald diese auftreten.

Die Optimierung dieser Metrik wird oft vernachlässigt, da zu viele Teams davon ausgehen, dass es nie zu einem größeren Ausfall kommen wird. Sie haben möglicherweise auch relativ wenige Datenpunkte, mit denen Sie arbeiten können, wenn Ihr Dienst im Allgemeinen stabil ist. Die Durchführung von Proben zur Reaktion auf Vorfälle mit Methoden wie Chaostests kann aussagekräftigere Daten liefern, die Ihre aktuelle Wiederherstellungszeit widerspiegeln.

Zusammenfassung

Die vier DORA-Metriken liefern DevOps-Teamleitern Daten, die Verbesserungsmöglichkeiten aufzeigen. Die regelmäßige Messung und Analyse der Bereitstellungshäufigkeit, Änderungsvorlaufzeit, Änderungsfehlerrate und Dienstwiederherstellungszeit hilft Ihnen, Ihre Leistung zu verstehen und fundierte Entscheidungen zur Verbesserung zu treffen.

DORA-Metriken können anhand der Informationen in Ihrem Projektmanagementsystem manuell berechnet werden. Es gibt auch Tools wie „ Four Keys “ von Google Cloud, die sie basierend auf Commit-Informationen automatisch generieren. Einige Ökosystem-Tools, wie GitLab , beginnen auch mit integrierter Unterstützung.

Die besten DevOps-Implementierungen fördern schnelle Änderungen und regelmäßige Rollouts, die sehr selten zu neuen Fehlern führen. Alle auftretenden Regressionen werden schnell behoben, wodurch Ausfallzeiten minimiert werden, damit Kunden die bestmögliche Erfahrung mit Ihrem Service haben. Durch das Verfolgen von DORA-Trends im Laufe der Zeit können Sie überprüfen, ob Sie diese Ideale erreichen, und so die besten Chancen auf einen DevOps-Erfolg haben.