DevOps-Metriken – Woher man Daten für Berechnungen beziehen kann

Ehrlich gesagt, hat Ivan oft über die vergeblichen Bemühungen seiner Kollegen aus der Überwachungsabteilung gelacht. Sie investierten unermüdlich Zeit, um die Metriken zu implementieren, die das Management verlangte. Sie waren so beschäftigt, dass sie nichts mehr für andere tun wollten.

Aber das Management war nie zufrieden – es forderte ständig neue Metriken und hörte sehr schnell auf, die bereits vorhandenen zu nutzen.

In letzter Zeit wurde viel über LeadTime gesprochen – die Zeit, die benötigt wird, um Geschäftsfunktionen bereitzustellen. Die Metrik zeigte eine verrückte Zahl – 200 Tage für die Bereitstellung einer einzigen Aufgabe. Wie alle darüber entsetzt waren und ihre Hände zum Himmel erhoben!

Nach einiger Zeit verklang der Lärm allmählich, und das Management gab den Auftrag zur Erstellung einer weiteren Metrik.

Ivan war sich vollkommen sicher, dass auch die neue Metrik leise in einer dunklen Ecke sterben würde.

In der Tat, dachte Ivan, sagt die Kenntnis der Zahl niemandem etwas. 200 Tage oder 2 Tage – es macht keinen Unterschied, denn an der Zahl lässt sich weder der Grund erkennen noch verstehen, ob das gut oder schlecht ist.

Dies ist eine typische Falle der Metriken: Es scheint, als würde eine neue Metrik das Wesen des Seins enthüllen und ein geheimes Geheimnis erklären. Alle hoffen darauf, aber irgendwie passiert nichts. Denn das Geheimnis sollte man ganz woanders suchen – nicht in den Metriken!

Für Ivan war das ein bereits durchlaufener Prozess. Er verstand, dass Metriken lediglich ein gewöhnliches Maßband für Messungen sind, während alle Geheimnisse in dem Einflussobjekt, d.h. in dem, was diese Metrik formt.

Für einen Online-Shop wäre das Einflussobjekt seine zahlenden Kunden, während es für DevOps die Teams sind, die Software-Pakete entwickeln und ausrollen, wobei sie Continuous Integration nutzen.

Eines Tages, bequem in einem Stuhl in der Lobby sitzend, beschloss Ivan, sich Gedanken darüber zu machen, wie er sich die DevOps-Metriken wünscht, wobei das Einflussobjekt die Teams sind.

Ziel der DevOps-Metriken

Ist klar, dass jeder die Lieferzeit reduzieren möchte. 200 Tage – das ist natürlich inakzeptabel.

Aber wie, das ist die Frage?

In dem Unternehmen arbeiten Hunderte von Teams, und täglich durchlaufen Tausende von Distributionen den DevOps-Pipeline. Die tatsächliche Lieferzeit wird als Verteilung erscheinen. Jedes Team wird seine eigene Zeit und spezielle Merkmale haben. Wie kann man in diesem Durcheinander überhaupt etwas finden?

Die Antwort lag auf der Hand – wir müssen die problematischen Teams identifizieren und herausfinden, was bei ihnen vor sich geht und warum es so lange dauert, während wir bei den 'guten' Teams lernen, wie man alles schnell erledigt. Dafür müssen wir die Zeit messen, die die Teams an jedem der DevOps-Stände verbringen:

„Ziel des Systems wird es sein, Teams anhand der Zeit, die sie an den Ständen verbringen, auszuwählen, d.h. letztendlich sollten wir eine Liste von Teams mit den jeweiligen Zeiten erhalten, anstatt nur eine Zahl.

Wenn wir herausfinden, wie viel Zeit insgesamt am Stand verbracht wurde und wie viel Zeit mit Wartezeiten zwischen den Ständen vergeudet wurde, können wir die Teams identifizieren, sie anrufen und die Ursachen im Detail analysieren und beseitigen“, dachte Ivan.

Wie man die Lieferzeit für DevOps berechnet

Um eine Berechnung durchzuführen, war es erforderlich, tiefer in den DevOps-Prozess und seine Wesenszüge einzutauchen.

Im Unternehmen werden eine begrenzte Anzahl von Systemen verwendet, und Informationen können nur aus diesen und sonst nirgendwoher gewonnen werden.

Alle Aufgaben wurden im Unternehmen in Jira registriert. Wenn eine Aufgabe bearbeitet wurde, wurde ein Branch erstellt, und nach der Umsetzung wurde ein Commit in BitBucket durchgeführt und ein Pull Request erstellt. Bei der Annahme des PR (Pull Request) wurde automatisch ein Distributionspaket erstellt und im Nexus-Repository gespeichert.

Anschließend wurde das Distributionspaket auf mehreren Ständen mit Hilfe von Jenkins ausgeführt, um die Richtigkeit der Installation sowie automatisierte und manuelle Tests zu überprüfen:

Ivan hat aufgeschlüsselt, aus welchen Systemen welche Informationen entnommen werden können, um die Zeit auf den Ständen zu berechnen:

• Aus Nexus – Zeit der Erstellung des Distributionspakets und der Name des Ordners, in dem der Code des Teams enthalten war.
• Aus Jenkins – Startzeit, Dauer und Ergebnis der Ausführung jedes Jobs, Name des Stands (in den Jobparametern), Stages (Schritte des Jobs), Link zum Distributionspaket in Nexus.
• Ivan entschied sich, Jira und BitBucket nicht in die Pipeline einzubeziehen, da sie mehr mit der Entwicklungsphase zu tun hatten und nicht mit der Bereitstellung des fertigen Distributionspakets auf den Ständen.

Basierend auf den verfügbaren Informationen wurde folgendes Schema erstellt:

Angesichts der Zeit, die zur Erstellung von Distributionen benötigt wird, und der Zeit, die für jede einzelne aufgewendet wird, lassen sich die Gesamtkosten für den gesamten DevOps-Prozess (voller Zyklus) leicht berechnen.

Das sind die DevOps-Kennzahlen, die Ivan letztendlich erhalten hat:

• Anzahl der erstellten Distributionen
• Anteil der Distributionen, die auf die Standorte gelangt und die dort erfolgreich getestet wurden
• Zeit, die am Standort verbracht wurde (Standzeiten-Zyklus)
• Voller Zyklus (Gesamtzeit für alle Stände)
• Dauer der Jobs
• Stillstand zwischen den Ständen
• Stillstand zwischen den Ausführungen von Jobs an einem Stand

Einerseits charakterisierten die Kennzahlen den DevOps-Prozess sehr gut hinsichtlich der Zeit; andererseits waren sie sehr einfach zu erfassen.

Zufrieden mit seiner guten Arbeit stellte Ivan eine Präsentation zusammen und ging, um sie der Geschäftsführung vorzustellen.

Auf dem Rückweg war er jedoch mit besorgter Miene und hängenden Händen unterwegs.

— Das ist ein Fiasko, Kumpel, — lächelte ein ironischer Kollege…

Fortsetzung lesen Sie im Artikel „Wie schnelle Ergebnisse Ivan geholfen haben».

Quelle: habr.com