Wie Ivan DevOps-Metriken machte. Einflussfaktor

Eine Woche ist vergangen, seit Ivan zum ersten Mal über DevOps-Metriken nachgedacht hat und erkannt hat, dass er 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 mir das?“

Was bringt es wirklich, die Zeit zu wissen? Angenommen, die Lieferung dauert 5 Tage. Und was dann? Ist das gut oder schlecht? Selbst wenn es schlecht ist, muss ich diese Zeit irgendwie verkürzen. Aber wie?
Diese Gedanken ließen ihn nicht los, aber die Lösung wollte nicht kommen.

Ivan wusste, dass er zum Kern der Sache gekommen war. Die unzähligen Metrikdiagramme, die er zuvor gesehen hatte, hatten ihn längst überzeugt, dass der Standardansatz nicht funktionieren wird und dass es nichts bringen wird, einfach ein Diagramm zu erstellen (auch wenn es kohortenbasiert ist), bei dem keine Erkenntnisse gewonnen werden.

Was tun?…

Eine Metrik ist wie ein gewöhnliches Holzlineal. Die Messungen, die damit gemacht werden, sagen nicht, warum das messbare Objekt genau die Länge hat, die es zeigt. Das Lineal zeigt einfach seine Größe an, nicht mehr. Es ist kein philosophischer Stein, sondern nur ein Stück Holz zum Messen.

Der "Edelstahl-Rat" aus dem Lieblingsbuch seines Autors Harry Harrison sagte immer: Gedanken müssen das Gehirn bis zum Tiefpunkt erreichen und dort verweilen, deshalb beschloss Ivan nach ein paar fruchtlosen Tagen, sich einer anderen Aufgabe zu widmen...

Nach ein paar Tagen wurde Ivan beim Lesen eines Artikels über Online-Shops plötzlich klar, dass die Höhe der Einnahmen, die ein Online-Shop erzielt, davon abhängt, wie sich die Besucher der Webseite verhalten. Es sind eben diese Besucher/Kunden, die dem Geschäft ihr Geld geben und somit die Einnahmequelle darstellen. Die letztendliche Geldsumme, die der Shop erhält, wird von Veränderungen im Kundenverhalten beeinflusst, nicht von etwas anderem.

Es stellte sich heraus, dass, um die messbare Größe zu ändern, man Einfluss auf diejenigen ausüben musste, die diesen Wert formen. Um also die Einnahmen eines Online-Shops zu steigern, musste man das Verhalten der Kunden beeinflussen, und um die Lieferzeiten in DevOps zu verändern, musste man Einfluss auf die Teams nehmen, die diese Zeiten "erstellen", d.h. DevOps in ihrer Arbeit nutzen.

Ivan erkannte, dass DevOps-Metriken nicht einfach Grafiken darstellen sollten. Sie sollten vielmehr ein Werkzeug zur Suche sein. „herausragende“ Teams, die die endgültige Lieferzeit beeinflussen.

Keine Metrik wird je die Ursache zeigen, warum ein bestimmtes Team lange benötigt hat, um ein Distribution bereitzustellen, dachte Ivan, denn in Wirklichkeit kann es Millionen von Gründen geben, und viele davon sind möglicherweise nicht technischer, sondern organisatorischer Natur. Das heißt, das Höchste, was man von Metriken erwarten kann, ist eine Darstellung der Teams und ihrer Ergebnisse, und danach muss man trotzdem selbst zu diesen Teams gehen und herausfinden, was los war.

Auf der anderen Seite gab es in Ivans Firma einen Standard, der alle Teams verpflichtete, die Builds auf mehreren Ständen zu überprüfen. Ein Team konnte nicht zum nächsten Stand übergehen, bis der vorherige bestanden wurde. Man könnte sagen, wenn man den DevOps-Prozess als Abfolge von Ständen betrachtet, könnten die Metriken die Zeit anzeigen, die die Teams an diesen Ständen verbringen. Mit dem Wissen um den Stand und die Zeit des Teams könnte man konkreter mit ihnen über die Ursachen sprechen.

Nach kurzem Zögern nahm Ivan den Telefonhörer ab und wählte die Nummer einer Person, die sich bestens mit den Feinheiten von DevOps auskannte:

— Denis, sag mal, kann man irgendwie herausfinden, ob das Team einen bestimmten Stand erfolgreich absolviert hat?
— Natürlich. Unser Jenkins setzt eine Flagge, wenn der Build erfolgreich auf dem Stand deployt wurde (den Test bestanden hat).
— Super. Was ist eine Flagge?
— Das ist eine einfache Textdatei wie „stand_OK“ oder „stand_FAIL“, die angibt, ob der Build bestanden ist oder nicht. Hast du das verstanden?
— Prinzipiell ja. Wird sie im selben Ordner im Repository gespeichert, wo sich der Build befindet?
— Ja.
— Was passiert, wenn der Build den Stand nicht besteht? Muss ich einen neuen Build machen?
— Ja, genau.
— Alles klar, danke. Und noch eine Frage: Verstehe ich richtig, dass ich als Datum für das Bestehen des Standes das Erstellungsdatum der Flagge verwenden kann?
— Absolut!
— Super!

Ermutigt legte Ivan den Hörer auf und realisierte, dass alles sich an seinen Platz fügte. Aufgrund des Erstellungsdatums der Build-Datei und den Erstellungsdaten der Flaggen konnte er genau bis zur Sekunde berechnen, wie viel Zeit die Teams für jeden Stand aufwenden, und feststellen, wo sie die meiste Zeit verbringen.

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

Für morgen hat er sich die Aufgabe gesetzt, die Architektur des sich abzeichnenden Systems zu skizzieren.

Die Fortsetzung folgt…

Quelle: habr.com