Ehrlich gesagt lachte Ivan oft über die vergeblichen Bemühungen von Kollegen aus der Überwachungsabteilung. Sie haben große Anstrengungen unternommen, um die von der Unternehmensleitung angeordneten Kennzahlen umzusetzen. Sie waren so beschäftigt, dass sie nichts anderes tun wollten.
Und das Management war nicht genug - es bestellte ständig mehr und mehr Metriken und hörte sehr schnell auf, das zu verwenden, was früher getan wurde.
Vor kurzem haben alle über LeadTime gesprochen - die Lieferzeit von Geschäftsfunktionen. Die Metrik zeigte eine verrückte Zahl - 200 Tage, um eine Aufgabe zu erledigen. Wie haben alle gestöhnt, gestöhnt und ihre Hände zum Himmel erhoben!
Nach einiger Zeit beruhigte sich das Rauschen allmählich und das Management befahl, eine weitere Metrik zu erstellen.
Ivan war völlig klar, dass die neue Metrik auch in einer dunklen Ecke leise sterben würde.
In der Tat, überlegte Ivan und wusste, dass die Nummer niemandem etwas sagt. 200 Tage oder 2 Tage - es gibt keinen Unterschied, denn anhand der Anzahl ist es unmöglich, den Grund zu bestimmen und zu verstehen, ob es gut oder schlecht ist.
Dies ist eine typische Metrikfalle: Es scheint, dass die neue Metrik die Essenz des Seins aufzeigt und ein geheimes Geheimnis erklärt. Jeder hofft es, aber aus irgendeinem Grund passiert nichts. Ja, denn das Geheimnis darf nicht in Metriken gesucht werden!
Für Ivan war dies eine vorübergehende Etappe. Er verstand, dass
Metriken nur ein gewöhnliches Holzlineal für Messungen sind und alle Geheimnisse im
Objekt des Einflusses gesucht werden müssen, d. H. , dass sich diese Metrik bildet.
Für einen Online-Shop sind die Kunden, die Geld einbringen, und für DevOps die Teams, die mithilfe der Pipeline Distributionen erstellen und ausrollen, das Einflussfeld.
Nachdem Ivan sich in einem bequemen Sessel in der Lobby niedergelassen hatte, überlegte er genau, wie er die DevOps-Metriken sehen möchte, und berücksichtigte dabei die Tatsache, dass Teams Gegenstand des Einflusses sind.
Ziel DevOps Metrics
Es ist klar, dass jeder die Lieferzeit reduzieren möchte. 200 Tage sind natürlich umsonst.
Aber wie, das ist die Frage?
Das Unternehmen hat Hunderte von Teams und Tausende von Distributionen durchlaufen täglich die DevOps-Pipeline. Die tatsächliche Lieferzeit sieht nach Verteilung aus. Jedes Team hat seine eigene Zeit und seine eigenen Eigenschaften. Wie können Sie wenigstens etwas in diesem Durcheinander finden?
Die Antwort ergab sich natürlich: Sie müssen problematische Teams finden und herausfinden, was mit ihnen los ist und warum so lange, und lernen, wie man mit „guten“ Teams alles schnell macht. Und dafür müssen Sie die Zeit messen, die die Teams an jedem der DevOps-Stände verbringen:
„Der Zweck des Systems wird die Auswahl von Teams nach dem Zeitpunkt des Durchgangs der Stände sein, d. H. Am Ende sollten wir eine Liste der Teams mit der ausgewählten Zeit und keine Nummer erhalten.
Wenn wir herausfinden, wie viel Zeit insgesamt auf dem Stand verbracht wurde und wie viel Zeit für Ausfallzeiten zwischen den Ständen aufgewendet wurde, können wir Teams finden, sie anrufen und die Gründe genauer verstehen und sie beseitigen “, dachte Ivan.
So berechnen Sie die Lieferzeit für DevOps
Um zu zählen, war es notwendig, sich mit dem DevOps-Prozess und seiner Essenz zu befassen.
Das Unternehmen verwendet 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. Als die Aufgabe ausgeführt wurde, wurde ein Brunch für sie erstellt, und nach der Implementierung wurde ein Commit für BitBucket und Pull Request durchgeführt. Bei der Annahme von PR (Pull Request) wurde automatisch ein Distributionskit erstellt und im Nexus-Repository gespeichert.
Ferner wurde die Verteilung auf mehreren Ständen unter Verwendung von Jenkins ausgerollt, um die Richtigkeit der Walz-, automatischen und manuellen Tests zu überprüfen:
Ivan malte aus welchen Systemen welche Informationen entnommen werden können, um die Zeit an den Ständen zu berechnen:
- Von Nexus - Erstellungszeit der Distribution und Name des Ordners, in dem der Befehlscode enthalten war
- Von Jenkins - Startzeit, Dauer und Ergebnis der Ausarbeitung jedes Jobs, Name des Standes (in den Jobparametern), Phasen (Schritte des Jobs), 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 darauf, die fertige Distribution um die Stände zu rollen.
Basierend auf den verfügbaren Informationen wurde das folgende Schema erstellt:
Wenn Sie wissen, wie viel Zeitverteilungen erstellt werden und wie viel Zeit für jede dieser Verteilungen aufgewendet wird, können Sie auf einfache Weise die Gesamtkosten für das Durchlaufen der gesamten DevOps-Pipeline (vollständiger Zyklus) berechnen.
Hier sind die DevOps-Metriken von Ivan als Ergebnis:
- Anzahl der erstellten Distributionen
- Der Anteil der Distributionen, die am Stand „angemeldet“ und am Stand „vorbei“ sind
- Zeit am Stand verbracht (Standzyklus)
- Voller Zyklus (Gesamtzeit für alle Stände)
- Arbeitsdauer
- Einfach zwischen Ständen
- Einfach zwischen Jobstarts an einem Stand
Einerseits charakterisierten Metriken die DevOps-Pipeline sehr gut in Bezug auf die Zeit, andererseits wurden sie als sehr einfach angesehen.
Ivan war mit der gut gemachten Arbeit zufrieden, hielt eine Präsentation und präsentierte sie dem Management.
Er kehrte stirnrunzelnd und mit gesenkten Händen zurück.
"Das ist ein Fiasko, Bruder", lächelte der ironische Kollege.
Lesen Sie weiter den Artikel " Wie schnell Ergebnisse Ivan geholfen haben ."