Ehrlich gesagt lachte Ivan oft über die vergeblichen Bemühungen seiner Kollegen aus der Überwachungsabteilung. Sie haben große Anstrengungen unternommen, um die von der Unternehmensleitung vorgegebenen Maßstäbe umzusetzen. Sie waren so beschäftigt, dass sie nicht wollten, dass jemand anderes etwas tat.
Aber das reichte dem Management nicht – sie ordneten ständig neue und neue Kennzahlen an und hörten sehr schnell auf, die bisherigen Maßnahmen zu nutzen.
In letzter Zeit ist LeadTime in aller Munde – die Zeit für die Bereitstellung von Geschäftsfunktionen. Die Metrik zeigte eine verrückte Zahl – 200 Tage für die Erledigung einer Aufgabe. Wie alle ooh und aah und ihre Hände zum Himmel hoben!
Nach einiger Zeit ließ der Lärm allmählich nach und das Management erhielt den Auftrag, eine weitere Metrik zu erstellen.
Für Ivan war völlig klar, dass die neue Metrik genauso leise in einer dunklen Ecke sterben würde.
In der Tat, dachte Ivan, sagt Ivan überhaupt nichts, wenn man die Nummer kennt. 200 Tage oder 2 Tage – es gibt keinen Unterschied, da es unmöglich ist, anhand der Zahl den Grund zu bestimmen und zu verstehen, ob er gut oder schlecht ist.
Dies ist eine typische Metrikfalle: Es scheint, dass eine neue Metrik das Wesen der Existenz verrät und ein geheimes Geheimnis erklärt. Alle hoffen so sehr darauf, aber aus irgendeinem Grund passiert nichts. Ja, denn das Geheimnis sollte nicht in Kennzahlen liegen!
Für Ivan war dies eine überstandene Etappe. Er hat das verstanden für Messungen, und alle Geheimnisse müssen erforscht werden , d.h. ist, dass diese Metrik gebildet wird.
Bei einem Online-Shop sind es seine Kunden, die Geld einbringen, und bei DevOps sind es die Teams, die mithilfe einer Pipeline Distributionen erstellen und ausrollen.
Eines Tages setzte sich Ivan in einen bequemen Stuhl im Flur und beschloss, sorgfältig darüber nachzudenken, wie er DevOps-Metriken sehen wollte, und berücksichtigte dabei die Tatsache, dass das Objekt des Einflusses Teams sind.
Zweck von DevOps-Metriken
Es ist klar, dass jeder die Lieferzeit verkürzen möchte. 200 Tage sind natürlich nicht gut.
Aber wie, das ist hier die Frage?
Das Unternehmen beschäftigt Hunderte von Teams und täglich durchlaufen Tausende von Distributionen die DevOps-Pipeline. Die tatsächliche Lieferzeit wird als Verteilung angezeigt. Jedes Team wird seine eigene Zeit und seine eigenen Eigenschaften haben. Wie kann man in diesem Durcheinander etwas finden?
Die Antwort ergab sich ganz natürlich: Wir müssen die Problemteams finden und herausfinden, was mit ihnen los ist und warum es so lange dauert, und von den „guten“ Teams lernen, wie wir alles schnell erledigen können. Und dazu müssen Sie die Zeit messen, die die Teams an jedem der DevOps-Stände verbringen:
„Der Zweck des Systems besteht darin, Mannschaften anhand der Zeit auszuwählen, die sie die Tribünen passieren, d. h. Als Ergebnis sollten wir eine Liste von Befehlen mit der ausgewählten Zeit und nicht eine Zahl erhalten.
Wenn wir herausfinden, wie viel Zeit insgesamt am Stand verbracht wurde und wie viel Zeit mit Ausfallzeiten zwischen den Ständen verbracht wurde, können wir die Teams finden, sie anrufen, die Gründe genauer verstehen und sie beseitigen“, dachte Ivan.
So berechnen Sie die Lieferzeit für DevOps
Um es zu berechnen, war es notwendig, sich mit dem DevOps-Prozess und seinem Wesen zu befassen.
Das Unternehmen nutzt eine begrenzte Anzahl von Systemen und Informationen können nur von diesen und nirgendwo anders bezogen werden.
Alle Aufgaben im Unternehmen wurden in Jira registriert. Wenn eine Aufgabe übernommen wurde, wurde ein Zweig dafür erstellt und nach der Implementierung ein Commit an BitBucket und Pull Request durchgeführt. Wenn ein PR (Pull Request) angenommen wurde, wurde automatisch eine Distribution erstellt und im Nexus-Repository gespeichert.
Als nächstes wurde die Verteilung auf mehreren Ständen mit Jenkins ausgerollt, um die Richtigkeit des Rollouts sowie automatische und manuelle Tests zu überprüfen:
Ivan beschrieb, aus welchen Systemen welche Informationen zur Berechnung der Zeit an den Ständen entnommen werden können:
- Von Nexus – Erstellungszeit der Distribution und Name des Ordners, der den Befehlscode enthielt
- Von Jenkins – Startzeit, Dauer und Ergebnis jedes Jobs, Standname (in den Job-Parametern), Stages (Job-Schritte), Link zur Verteilung in Nexus.
- Ivan hat beschlossen, Jira und BitBucket nicht in die Pipeline aufzunehmen, weil... Sie bezogen sich eher auf die Entwicklungsphase und nicht auf die Auslieferung der fertigen Distribution an den Ständen.
Basierend auf den verfügbaren Informationen wurde das folgende Diagramm erstellt:
Wenn Sie wissen, wie lange es dauert, Verteilungen zu erstellen und wie viel Zeit für jede einzelne davon aufgewendet wird, können Sie leicht die Gesamtkosten für den Durchlauf der gesamten DevOps-Pipeline (vollständiger Zyklus) berechnen.
Hier sind die DevOps-Kennzahlen, die Ivan letztendlich ermittelt hat:
- Anzahl der erstellten Verteilungen
- Anteil der Ausschüttungen, die zum Stand „kamen“ und am Stand „vorbeikamen“.
- Verweildauer am Stand (Standzyklus)
- Voller Zyklus (Gesamtzeit für alle Stände)
- Arbeitsdauer
- Ausfallzeit zwischen den Ständen
- Ausfallzeit zwischen Jobstarts am selben Stand
Einerseits charakterisierten die Metriken die DevOps-Pipeline zeitlich sehr gut, andererseits galten sie als sehr einfach.
Zufrieden mit der gut gemachten Arbeit hielt Ivan eine Präsentation und ging, um sie dem Management vorzustellen.
Er kam düster und mit gesenkten Händen zurück.
„Das ist ein Fiasko, Bruder“, lächelte der ironische Kollege ...
Lesen Sie mehr im Artikel „".
Source: habr.com