Eines Tages wurde Ivan zu einem Meeting eingeladen, um die DevOps-Metriken zu besprechen.
Jeder Teilnehmer bereitete für das Treffen eine Liste bestimmter Kennzahlen vor, deren Implementierung seiner Meinung nach eine Implementierung wert wäre.
Ivan hörte sich die Berichte an und versuchte zu berechnen, wie viele Metriken vorgeschlagen wurden: 5.10, wieder 10 und etwa ein Dutzend weitere. Es stellte sich heraus, 30 mit etwas.
Aus irgendeinem Grund kam plötzlich die Idee, dass die versammelten Leute einfach googelten und die Namen aufschrieben, die ihnen interessant erschienen. Anscheinend hat niemand über die Essenz von Metriken nachgedacht.
Ivan sah von der Seite zu und stellte sich Fragen: Warum? Warum genau diese Metriken? Was werden sie dir geben? Plötzlich stellte sich heraus, dass das Treffen Menschen zusammenbrachte, die weit von einem wirklichen Verständnis der Natur der Metriken entfernt waren, und dass alles wie gewohnt enden würde, indem viel Zeit verloren und die Arbeit in den Müll geworfen wurde.
Es wurde traurig und beleidigend. Es ist eine Schande, dass die Zeit und das Geld des Unternehmens einfach nirgendwo hingehen, und es ist traurig, dass ein nützliches Geschäft nicht getätigt wird.
Ivan hat lange Zeit Metriken studiert und lange verstanden, dass das Thema sehr ernst und komplex ist und es auf jeden Fall unmöglich ist, es von der Beibootbucht aus zu erreichen.
An diesem Tag endete das Treffen mit allem und nichts - wir beschlossen, alles auf einmal umzusetzen (niemand wollte die Verantwortung für die Ablehnung übernehmen, weil ich nicht verstand, warum eine andere Person diese Metriken benötigte).
Ivan beschloss, seine Vision von DevOps-Metriken vorzubereiten und sicherzustellen, dass jede Metrik darin gerechtfertigt war, einen bestimmten Zweck hatte, nützlich und verständlich war.
Das hat er getan ...
Was möchten Sie verwalten?
Zunächst beschloss Ivan, über das Hauptziel nachzudenken, für das die Metriken erstellt wurden.
In den gut gelesenen Büchern Lean Analytics und The Practice of Tao Toyota wurde vorgeschlagen: Wählen Sie die Zahl, die Sie steuern möchten, als Hauptmetrik. Wählen Sie als Nächstes die Komponenten dieser Nummer aus, die Sie als Metriken beeinflussen können.
Das Ziel von DevOps beim letzten Treffen war „Softwarequalität“, aber das Konzept der Qualität war sehr vage. Was ist Qualität? Wie drücke ich es in einer Zahl aus? Welche Komponenten beeinflussen es?
Leider kann die Softwarequalität nicht in einer einzigen Zahl ausgedrückt werden.
Wie auch immer, ist der Zweck der Verwendung von DevOps wirklich Qualität?
Vor ein paar Jahren arbeitete Ivan als IT-Direktor für ein kleines Unternehmen, das seine eigene Software produzierte, und dort startete und verwendete er erfolgreich DevOps. Und der Zweck dieses DevOps war überhaupt nicht wirklich Qualität. Eher auch Qualität. Das Haupt- und einzige Ziel war es, manuelle Arbeit während des Einsatzes im Abschlussball zu eliminieren.
Durch das Entfernen von Handarbeit erreichte er dann eine solche Beschleunigung und Verringerung der Anzahl von Fehlern, dass es möglich wurde, Verbesserungen mindestens einmal pro Minute freizugeben.
So stellte sich heraus, dass sich als
TARGET METRIC DevOps von selbst anbietet
Lieferzeit
Es ist genau seine Abnahme oder Zunahme, die die Wirkung der getroffenen Managemententscheidungen zeigen würde.
Die Lieferzeit (Time To Market, TTM) hat sich erhöht - schlecht. Verringert - ausgezeichnet.
Die Lieferzeit hängt jedoch vom Umfang der Aufgabe und von der Testdauer sowie von vielen anderen Faktoren ab! Ja Richtig.
Aus diesem Grund hat Ivan bewusst beschlossen, den Countdown nicht ab dem Zeitpunkt der Codierung und Analyse zu starten, sondern ab dem Zeitpunkt, an dem die Baugruppe (Verteilung) bereits erstellt und eingelagert wurde. Sie müssen lediglich eine Reihe von Überprüfungen durchführen und in einer industriellen Umgebung (der sogenannten) bereitstellen Kontinuierliche Lieferung, CDL).
Hier ist es wichtig, zuerst ein Prinzip, ein Konzept, zu entwickeln, dachte Ivan, und es auf andere unerreichte Bereiche auszudehnen, da Codierung, Montage und alle anderen Entwicklungsschritte ebenso wie die CDL-Phase die Lieferzeit beeinflussen. Lass es uns in einem machen - wir werden es in dem anderen machen.
In der großen Firma, in der Ivan arbeitete, waren Metriken von entscheidender Bedeutung. Tausende Entwickler haben den Code gesägt und täglich Hunderte von Baugruppen erstellt, aber niemand, niemand im Unternehmen wusste, wie viel Zeit Teams tatsächlich für DevOps aufwenden.
Von allen Seiten gingen Beschwerden ein: DevOps-Bullshit, es funktioniert nicht, es hat sich schrecklich verlangsamt, es macht keinen Sinn. Aber niemand hatte echte Zahlen zur Hand, und es war einfach unmöglich, die Aussagen der Teams zu beweisen oder zu widerlegen.
Dieses Ziel hat sich Ivan gesetzt - die Zeit zu berechnen, die Teams für DevOps und insbesondere für die Auslieferungsphase der Versammlung aufwenden.
Das kann nicht sein, dachte Ivan, wenn ich einmal DevOps gestartet habe und es einen sofortigen Effekt hatte, warum ist es dann nicht hier?
Die Schaffung eines Metriksystems wurde für Ivan zur Ehrensache.
Steuern Sie, was Sie steuern können
Wie verwalte ich die Lieferzeit? Ist es möglich? - fragte Ivan.
Wenn wir die Lieferzeit als Zahl betrachten, wird klar, dass es Stellen im DevOps-Prozess gibt, die diese Zahl erheblich beeinflussen.
Iwans Firma hatte einen Standard: Jede Baugruppe vor dem Abschlussball sollte drei Prüfstände bestehen, auf denen verschiedene Aspekte der Software getestet wurden.
Natürlich sind die Baugruppen auf ihnen aufgrund von Fehlern „abgefallen“, und stattdessen wurden neue erstellt.
Es stellte sich heraus, dass die Stände die Schlüsselelemente der gesamten Lieferzeit sind, und sie beeinflussen die Gesamtzeit und erhöhen sie.
Lieferzeit = Zeit am Stand 1 + Zeit am Stand 2 + Zeit am Stand 3Durch die Beeinflussung der Zeit, die die Teams an jedem Stand verbringen, kann die endgültige Lieferzeit beeinflusst werden.
Es blieben zwei einfache Fragen:
- wie man die Kosten von Teams auf Ständen physisch berechnet und
- Was tun mit Ausfallzeiten zwischen den Ständen (Ausfallzeiten sind auch Bestandteile der Lieferzeit)?
Ivan hatte keine andere Wahl, als in den Dschungel von Jenkins und Nexus (in der CDL verwendete Software) einzutauchen.
Jenkins und Nexus helfen
Die "Rollen" -Montage auf dem Ständer wurde unter Verwendung von Jenkins durchgeführt. In der Tat ist Jenkins ein normaler Schuppen, wie Crontab, aber mit erweiterten Funktionen.
Jenkins weiß, wie die Protokolle aller ausgeführten Jobs (Aufgaben zum Rollen der Baugruppe auf dem Stand) in Form von RSS angezeigt werden. Außerdem gibt es eine Start-, Endzeit und einen Link zu einer bestimmten Baugruppe.
Es stellte sich heraus, dass Ivan zur Verfügung stand, Daten über den genauen Zeitpunkt des Beginns und des Endes der Montagearbeiten zu erhalten, d. H. Es war möglich, die Nettozeit, die Teams auf Ständen verbrachten, einfach und genau zu berechnen.
Und wenn die Daten von allen Ständen in einer Datenbank gespeichert wurden, war es möglich, die Ausfallzeit zwischen den Ständen zu berechnen. Das war toll!
Vom Nexus (Netzwerkdateispeicher) wollte Ivan das Erstellungsdatum der Assembly selbst erhalten und so weiter. Bestimmen Sie den Zeitpunkt seines Auftretens und den Bezugspunkt.
Alles passte zusammen. Fast.
- Und wie geht das, dachte Ivan?
Fortsetzung folgt. Gegenstand des Einflusses