Ivan arbeitete in einer großen Organisation in einer Abteilung, die mit DevOps zu tun hatte. Täglich verwendeten Tausende von Mitarbeitern DevOps-Tools, um ihre Software zu erstellen, zu testen und zu implementieren.
Tausende Verteilungen pro Tag, die über das Fließband gingen, waren eine normale Situation.
Wo es große Macht gibt, gibt es auch große Verantwortung. Die unvermeidlichen Schwierigkeiten der Teams führten zu Hunderten von technischen Supportanrufen pro Tag.
Natürlich mochten viele DevOps-Tools nicht. Jemand sagte, dass sie zu fehlerhaft sind, während andere glaubten, dass man überhaupt auf sie verzichten kann, und es wird viel schneller sein.
Die Unternehmensleitung verstand, dass nicht alle 100% der Teams mit DevOps zufrieden sein konnten, es gab jedoch keine genauen Daten. Es wäre schön, die Probleme am Fließband zu sehen, aber selbst die übliche Anzahl von Verteilungen pro Tag war nicht bekannt. Was können wir über seriöse Metriken sagen?
Die Frage nach DevOps-Metriken wurde ständig gestellt - jeder brauchte sie sehr.
Ivan war als Mitarbeiter, der Kennzahlen kennt und die DevOps-Technologie kennt, eng an der Vorbereitung des Projekts beteiligt.
Zusammen mit DevOps-Administratoren erarbeitete er eine mögliche Lösungsarchitektur und studierte außerdem eine große Menge an Literatur zu DevOps-Metriken. Es gab keinen einzigen Artikel im Internet und kein einziges Buch zu diesem Thema, das er nicht lesen würde.
Als Ergebnis wurde eine komplette technische Lösung geboren, die Ivan dem Management vorstellte.
Alles ist weg
Die Reaktion des Managements war unerwartet - es wurde keine Entscheidung über die Implementierung getroffen.
"Das ist ein Fiasko, Bruder", sagte der gute Kollege mit einem Grinsen und ließ Ivan von der Besprechung zurück.
Trotz der Ironie hatte er recht. Wenn die Entscheidung nicht getroffen wird, gab es eine Art Abschreckung, die Ivan nicht sah und nicht berücksichtigte.
Das Management war von der technischen Machbarkeit der Implementierung von DevOps-Metriken überzeugt, bezweifelte dies jedoch weiterhin.
Dies wurde aus einem sehr einfachen Grund verursacht: Die technische Lösung zeigte, dass die Implementierung, obwohl möglich, eine große Anzahl von personellen und technischen Ressourcen erfordern würde, d. H. wird lieb sein. Ob sich daraus jedoch ein wirklich nützliches Ergebnis ergibt, ist eine große Frage.
Wenn es um ein teures Projekt geht, dann:
- Präsentationen sind nicht beeindruckend
- Bildschirmlayouts sind nicht beeindruckend
- Die Beispiele sind nicht beeindruckend.
Im Allgemeinen wurde der Start des Projekts auf unbestimmte Zeit verschoben. Die Aufgabe schien Ivan völlig unlösbar.
Schicksalhafter Fall
Alles wurde zufällig entschieden. Einmal kam ein Brief bei der Post an, der besagte, dass zwei Studenten für ein Praktikum in die Abteilung gebracht wurden. Einer der Schüler war bereit, kleine Arbeiten zu erledigen.
Ivan dachte, dass es möglich sein könnte, zumindest etwas anhand von Metriken zu tun - und schickte dem Studenten eine technische Aufgabe für einen Teil des Projekts, der auf Unmöglichkeit reduziert wurde.
Alles, was da war, war, auf einfachste Weise Daten von Jenkins und Nexus abzurufen.
Stellen Sie sich Iwans Überraschung vor, als ihn nur ein paar Tage später ein Student einlud, sich das Arbeitssystem anzusehen. Auf die Frage "Wie habe ich eine so hohe Priorität verdient?" gefolgt von der Antwort: "Sie hatten nur normale TK."
Wie dem auch sei, aber das System hat funktioniert. Sie zog Daten von Jenkins und Nexus und legte sie in ihre eigene Datenbank.
Ivan wurde klar, dass er den Rest so schnell wie möglich erledigen musste. Er verwendete die kostenlose Version von QlikView, um Berichte aus Rohdaten zu generieren, und am Abend war die erste Version der DevOps-Metriken fertig.
Der folgende Montag war ein Durchbruch. Als der Leiter von Ivan die Arbeitsmetriken sah, rief er aus: "Dies sind die nützlichsten Daten, die ich in letzter Zeit gesehen habe!"
Das Problem der Ressourcen wurde sofort behoben, und in den nächsten Tagen wurde das Projekt mit Metriken in vollem Umfang gestartet.
Ivan handelte korrekt und ohne es zu merken, lieferte es „schnelle Ergebnisse“ - ein funktionierendes System mit der am meisten verkürzten Funktionalität, das echte Vorteile bietet.
„Schnelle Ergebnisse“ funktionieren, denn bei einem großen, teuren System treten zwangsläufig viele Unklarheiten auf. Bei hohen Kosten ist das Ergebnis nicht immer offensichtlich.
Daher verzögert sich der Arbeitsbeginn ständig oder das System wird komplett aufgegeben.
Schnelle Ergebnisse helfen dabei, die Hypothese mit minimalen Mitteln zu testen. Die Hauptsache ist, zu versuchen, einen Prototyp herzustellen, ohne zusätzliche Ressourcen anzuziehen, und damit er gleichzeitig Wert und Nutzen bringt.
Einige Erkenntnisse, die Ivan aus dem Projekt erhalten hat:
Stellen Sie sich zunächst vor, welches Endergebnis Sie benötigen
Ivan wusste genau, welche Metriken er benötigen würde, bis hin zu den Bildschirmlayouts. Dies ermöglichte es ihm, unnötige Funktionen schnell zu verwerfen und nur das zu belassen, ohne das die Metriken ihre Bedeutung vollständig verloren hätten.
Von den zehn zur Implementierung vorgeschlagenen DevOps-Metriken ließ Ivan nur eine übrig und beschränkte sie auf einen Stand und ein Team. Tatsächlich war dies einerseits der konzentrierteste Druck und andererseits praktische reale Daten.
Eine solche abgespeckte Version ermöglichte es, ein völlig praktisches Problem zu lösen - das reale Team zu analysieren und zu verstehen, ob die darauf enthaltenen Metriken das von ihnen erwartete Ergebnis liefern würden.
Ein einfaches Architekturdiagramm erleichtert die Arbeit erheblich
Das einfachste Bereitstellungsschema mit Informationsflüssen und Daten half Ivan sehr gut zu verstehen, wo was liegt und wie einfacher es ist, es zu bekommen.
Jenkins: Jobs. Was ist für Metriken in Jobs erforderlich? Wie ziehe ich es heraus? Welche Protokolle, von welchen Adressen?
Nexus: Distributionen. Was benötigt Nexus für Metriken? Wie bekomme ich es?
Hilfesysteme: fallen lassen weil Sie werden für Metriken nicht benötigt.
Wie kombiniere ich Daten? Wo ist es am einfachsten, dies so schnell wie möglich zu tun?
Wenn möglich, verzichten Sie auf Codierung. Ganz
Wenn Sie vorgefertigte Uploads auf XLS oder CSV durchführen können, ist es besser, dies zu tun und überhaupt nicht zu codieren.
Manchmal können Sie nicht auf Codierung verzichten, müssen jedoch die einfachste Option auswählen.
Beispielsweise füttert Jenkins Daten in RSS und JSON. Wählen Sie die Option, die einfacher zu implementieren ist.
Nexus gibt nur XML zurück? Nun, es gibt nichts zu tun, Sie müssen codieren.
Hänge nicht zu viel. Alles reinigen
Für schnelle Ergebnisse ist keine Superautomatisierung erforderlich. Sie können Befehlscodes anstelle ihrer Namen verwenden. Sie sollten keine zusätzlichen Systeme nur zur Anreicherung von Daten anschließen. Dies sind nur Blumen und Schönheitsanleitungen - es ist besser, auf sie zu verzichten und Zeit zu sparen.
Anstatt in die Datenbank zu schreiben, können Sie in eine normale Textdatei oder CSV schreiben, wenn dies schneller geht.
Wo Sie manuell starten können - starten Sie, verschwenden Sie keine Zeit mit dem Schuppen.
Wenn es einfacher ist, in einer leichten Skriptsprache wie Python oder PHP zu schreiben, schreiben Sie. Wie auch immer, Sie tun das Minimum, sodass Sie nicht viel umschreiben müssen.
Verwenden Sie Tools, mit denen Sie schnell Ergebnisse erzielen können, z. B. QlikView oder Tablue für Metriken. Sie erleichtern das Laden und Kombinieren von Daten sowie das Erstellen aller erforderlichen Diagramme.
Ivan nahm die „schnellen Ergebnisse“ in Betrieb und versuchte in den folgenden Projekten immer, zuerst ein minimal funktionierendes System zu schaffen, das Nützlichkeit bietet, und erst dann den Rest aufzugreifen. Und es hat immer funktioniert.
Wenn Ihnen die Geschichte von Ivan nützlich erschien, werde ich mich sehr darüber freuen.
Bitte schreiben Sie in die Kommentare Ihren Fall, wenn schnelle Ergebnisse Wirkung gezeigt haben.