Wie Ivan DevOps-Metriken erstellt hat. Objekt des Einflusses

Eine Woche ist vergangen, seit Ivan zum ersten Mal über DevOps-Metriken nachgedacht und erkannt hat, dass es mit ihrer Hilfe notwendig ist, die Produktlieferzeit zu verwalten (Time-to-Market).

Sogar am Wochenende dachte er über Kennzahlen nach: „Was wäre, wenn ich die Zeit messe? Was wird es mir geben?

Was wird das Wissen über die Zeit tatsächlich bringen? Nehmen wir an, die Lieferung dauert 5 Tage. Und was dann? Ist das gut oder schlecht? Auch wenn das schlecht ist, müssen Sie diese Zeit irgendwie verkürzen. Aber wie?
Diese Gedanken verfolgten ihn, aber es kam keine Lösung.

Ivan verstand, dass er zum Wesentlichen gekommen war. Die zahllosen Diagramme der Metriken, die er zuvor gesehen hatte, hatten ihn schon vor langer Zeit davon überzeugt, dass der Standardansatz nicht funktionieren würde und dass, wenn er einfach nur zeichnen würde (auch wenn es eine Kohorte ist), wird es keinen Nutzen haben.

Wie sein?…

Eine Metrik ist wie ein gewöhnliches Holzlineal. Mit seiner Hilfe durchgeführte Messungen geben keinen Aufschluss über den Grund. warum Das gemessene Objekt hat genau die Länge, die sie angezeigt hat. Das Lineal zeigt lediglich seine Größe an und nichts weiter. Sie ist nicht der Stein der Weisen, sondern lediglich ein Holzbrett zum Messen.

Die „Ratte aus rostfreiem Stahl“ seines Lieblingsschriftstellers Harry Harrison sagte immer: Ein Gedanke muss bis zum Grund des Gehirns vordringen und dort bleiben. Nachdem Ivan mehrere Tage lang erfolglos gelitten hatte, beschloss er, sich einer anderen Aufgabe zu widmen ...

Ein paar Tage später, als Ivan einen Artikel über Online-Shops las, wurde ihm plötzlich klar, dass der Geldbetrag, den ein Online-Shop erhält, vom Verhalten der Website-Besucher abhängt. Sie, die Besucher/Kunden, geben dem Geschäft ihr Geld und sind dessen Quelle. Das Endergebnis der Bargeldeinnahmen, die ein Geschäft erhält, wird durch Veränderungen im Kundenverhalten beeinflusst, nicht durch irgendetwas anderes.

Es stellte sich heraus, dass es zur Veränderung des Messwertes notwendig war, Einfluss auf diejenigen zu nehmen, die diesen Wert bilden, d.h. Um den Geldbetrag eines Online-Shops zu ändern, war es notwendig, das Verhalten der Kunden dieses Shops zu beeinflussen, und um die Lieferzeit in DevOps zu ändern, war es notwendig, Einfluss auf die Teams zu nehmen, die diese Zeit „erschaffen“, d. h. nutzen DevOps bei ihrer Arbeit.

Ivan erkannte, dass DevOps-Metriken überhaupt nicht durch Diagramme dargestellt werden sollten. Sie müssen sich selbst repräsentieren Suchwerkzeug „hervorragende“ Teams, die die endgültige Lieferzeit bestimmen.

Keine Kennzahl wird jemals den Grund aufzeigen, warum dieses oder jenes Team so lange brauchte, um eine Verteilung zu liefern, dachte Ivan, denn in Wirklichkeit könnte es eine Million und einen kleinen Wagen geben, und diese sind möglicherweise nicht technischer, sondern organisatorischer Natur. Diese. Das Beste, was Sie von Metriken erwarten können, ist, Teams und ihre Ergebnisse zu zeigen, und dann müssen Sie diesen Teams immer noch mit den Füßen folgen und herausfinden, was mit ihnen nicht stimmt.

Andererseits hatte Ivans Unternehmen einen Standard, der von allen Teams verlangte, Baugruppen auf mehreren Prüfständen zu testen. Das Team konnte nicht zum nächsten Stand wechseln, bis der vorherige fertig war. Es stellte sich heraus, dass, wenn wir uns den DevOps-Prozess als eine Abfolge von Durchgängen durch Stände vorstellen, die Metriken die Zeit anzeigen könnten, die Teams an diesen Ständen verbracht haben. Da man den Stand und die Zeit des Teams kannte, war es möglich, mit ihm konkreter über die Gründe zu sprechen.

Ohne zu zögern griff Ivan zum Telefonhörer und wählte die Nummer einer Person, die sich mit den Besonderheiten von DevOps bestens auskennt:

— Denis, sag mir bitte, ist es irgendwie möglich zu verstehen, dass die Mannschaft diesen oder jenen Stand bestanden hat?
- Sicherlich. Unser Jenkins verwirft die Flagge, wenn der Build erfolgreich auf der Bank eingeführt (den Test bestanden) wurde.
- Super. Was ist eine Flagge?
– Dies ist eine normale Textdatei wie „stand_OK“ oder „stand_FAIL“, die besagt, dass die Baugruppe den Test bestanden oder nicht bestanden hat. Na ja, du verstehst, oder?
- Ich denke ja. Wird es in denselben Ordner im Repository geschrieben, in dem sich die Assembly befindet?
- Ja
— Was passiert, wenn die Baugruppe den Prüfstand nicht besteht? Muss ich einen Neubau durchführen?
- Ja
- Na gut, danke. Und noch eine Frage: Verstehe ich richtig, dass ich das Erstellungsdatum der Flagge als Datum des Standes verwenden kann?
- Absolut!
- Super!

Inspiriert legte Ivan auf und stellte fest, dass alles seinen Platz gefunden hatte. Durch die Kenntnis des Erstellungsdatums der Build-Datei und des Erstellungsdatums der Flags war es möglich, sekundengenau zu berechnen, wie viel Zeit die Teams an jedem Stand verbringen und zu verstehen, wo sie die meiste Zeit verbringen.

„Da wir wissen, wo die meiste Zeit aufgewendet wird, können wir Teams identifizieren, zu ihnen gehen und uns mit dem Problem befassen.“ Ivan lächelte.

Für morgen stellte er sich die Aufgabe, die Architektur des zu zeichnenden Systems zu skizzieren.

To be continued ...

Source: habr.com