Wie Ivan DevOps-Metriken gemacht hat. Einflussobjekt

Eine Woche ist vergangen, seit Ivan zum ersten Mal über DevOps-Metriken nachgedacht hat und erkannt hat, dass man mit ihrer Hilfe die Lieferzeit des Produkts steuern muss. (Time-To-Market).

Selbst am Wochenende dachte er über die Metriken nach: „Und was bringt es, wenn ich die Zeit messe? Was bringt es mir?“

Wirklich, was bringt das Wissen um die Zeit? Angenommen, die Lieferung dauert 5 Tage. Und was dann? Ist das gut oder schlecht? Selbst wenn es schlecht ist, muss man diese Zeit ja irgendwie reduzieren. Aber wie?
Diese Gedanken ließen ihn keine Ruhe, aber die Lösung kam nicht.

Ivan verstand, dass er zum Wesentlichen durchgedrungen war. Die unzähligen Metrikdiagramme, die er zuvor gesehen hatte, hatten ihn längst überzeugt, dass der Standardansatz nicht funktionieren würde und dass, selbst wenn man ein Diagramm erstellt (selbst wenn es ein kohortenspezifisches ist), es keinen Nutzen bringen würde.

Was nun?…

Eine Metrik ist wie ein gewöhnliches Holzlineal. Die Messungen, die damit vorgenommen werden, sagen nicht die Ursache, warum das gemessene Objekt genau die Länge hat, die es zeigt. Das Lineal zeigt einfach nur seine Größe an, und nicht mehr. Es ist kein Philosophstein, sondern einfach ein Holzbrett, mit dem man misst.

„Die rostfreie Ratte“ des Lieblingsautors von ihm, Harry Harrison, sagte immer: Der Gedanke muss den Boden des Gehirns erreichen und dort ausruhen, daher beschloss Ivan, nach ein paar Tagen des fruchtlosen Nachdenkens eine andere Aufgabe zu übernehmen…

Nach ein paar Tagen, beim Lesen eines Artikels über Online-Shops, erkannte Ivan plötzlich, dass die Geldmenge, die ein Online-Shop erhält, davon abhängt, wie sich die Besucher der Website verhalten. Es sind gerade diese Besucher/Kunden, die dem Shop ihr Geld geben und dessen Quelle sind. Die endgültige Höhe der finanziellen Mittel, die der Shop erhält, wird durch Veränderungen im Kundenverhalten beeinflusst, nicht durch etwas anderes.

Es stellte sich heraus, dass man, um die gemessene Größe zu ändern, auf die einwirken musste, die diese Größe formen, d.h. um die Geldmenge des Online-Shops zu ändern, musste man das Verhalten der Kunden dieses Shops beeinflussen, und um die Lieferzeit in DevOps zu ändern, musste man die Teams beeinflussen, die diese Zeit „schaffen“, d.h. DevOps in ihrer Arbeit nutzen.

Ivan erkannte, dass DevOps-Metriken ganz und gar keine Diagramme darstellen sollten. Sie sollten vielmehr sein ein Werkzeug zur Suche nach „herausragenden“ Teams, die die endgültige Lieferzeit beeinflussen.

Keine Metrik wird jemals den Grund zeigen, warum ein Team so lange für die Bereitstellung eines Distributionspakets gebraucht hat, dachte Ivan, denn in der Realität kann es Millionen von Gründen geben, und sie können durchaus organisatorischer Natur sein, nicht technischer. Das bedeutet, dass das Maximum, das man von den Metriken erwarten kann, die Leistung der Teams und ihrer Ergebnisse ist, und man muss trotzdem zu diesen Teams gehen und herausfinden, was passiert ist.

Auf der anderen Seite gab es in Ivans Unternehmen einen Standard, der alle Teams verpflichtete, Builds auf mehreren Ständen zu überprüfen. Das Team konnte nicht zum nächsten Stand wechseln, bis der vorherige erfolgreich abgeschlossen war. Das bedeutete, dass, wenn man den DevOps-Prozess als eine Abfolge von Ständen betrachtet, die Metriken die Zeit anzeigen könnten, die die Teams an diesen Ständen verbringen. Mit dem Kenntnis des Stands und der Zeit des Teams konnte man konkreter über die Gründe sprechen.

Ohne lang nachzudenken, hob Ivan den Hörer ab und wählte die Nummer eines Menschen, der sich gut mit den Inneren von DevOps auskannte:

— Denis, kannst du mir bitte sagen, ob es eine Möglichkeit gibt zu verstehen, dass das Team diesen oder jenen Stand durchlaufen hat?
— Natürlich. Unser Jenkins setzt ein Flag, wenn der Build erfolgreich auf dem Stand durchgeführt wurde (den Test bestanden hat).
— Super. Was ist ein Flag?
— Das ist eine ganz normale Textdatei wie 'stand_OK' oder 'stand_FAIL', die sagt, ob der Build den Stand bestanden hat oder nicht. Verstehst du das?
— Im Prinzip ja. Wird es im selben Ordner im Speicher geschrieben, in dem der Build liegt?
— Ja
— Was passiert, wenn der Build den Stand nicht besteht? Muss man einen neuen Build machen?
— Aha
— Na gut, danke. Und noch eine Frage: Verstehe ich richtig, dass ich als Datum für das Durchlaufen des Stands das Datum der Erstellung des Flags verwenden kann?
— Absolut!
— Super!

Ermutigt legte Ivan den Hörer auf und stellte fest, dass alles an seinen Platz gefallen war. Mit dem Datum der Erstellung der Build-Datei und den Daten der Erstellung der Flags konnte genau bis zur Sekunde berechnet werden, wie viel Zeit die Teams an jedem Stand verbringen und wo sie am meisten Zeit verlieren.

„Wenn wir verstehen, wo die meiste Zeit verloren geht, werden wir gezielt die Teams finden, zu ihnen gehen und das Problem ausgraben.“ Ivan lächelte.

Für morgen hatte er sich vorgenommen, die Architektur des sich abzeichnenden Systems zu skizzieren.

Fortsetzung folgt…

Quelle: habr.com