{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps-Metriken \u2013 woher die Daten f\u00fcr Berechnungen nehmen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ehrlich gesagt, Ivan lachte oft \u00fcber die vergeblichen Bem\u00fchungen seiner Kollegen aus der \u00dcberwachungsabteilung. Sie machten enorme Anstrengungen, um die Kennzahlen, die das Management des Unternehmens bestellte, umzusetzen. Sie waren so besch\u00e4ftigt, dass sie nichts anderes mehr tun wollten. <\/p>\n

Und dem Management war das nicht genug \u2013 es bestellte st\u00e4ndig neue Kennzahlen und h\u00f6rte sehr schnell auf, die bereits erstellten zu nutzen.<\/p>\n

In letzter Zeit sprach jeder nur \u00fcber LeadTime \u2013 die Lieferzeit f\u00fcr Gesch\u00e4ftsfeatures. Die Kennzahl zeigte eine verr\u00fcckte Zahl \u2013 200 Tage f\u00fcr die Lieferung einer Aufgabe. Wie alle st\u00f6hnten, seufzten und ihre H\u00e4nde gen Himmel erhoben!<\/p>\n

Nach einiger Zeit verebbte der L\u00e4rm allm\u00e4hlich, und das Management gab einen Auftrag zur Erstellung einer weiteren Kennzahl.<\/p>\n

Ivan war vollkommen klar, dass auch die neue Kennzahl genau so still und leise im dunklen Winkel sterben w\u00fcrde.<\/p>\n

In der Tat dachte Ivan, die Kenntnis einer Zahl sagt niemandem etwas. 200 Tage oder 2 Tage \u2013 es gibt keinen Unterschied, weil man aus den Zahlen nicht die Ursache erkennen und verstehen kann, ob es gut oder schlecht ist.<\/p>\n

Das ist die typische Falle der Kennzahlen: Es scheint, als w\u00fcrde die neue Kennzahl das Wesen des Seins erz\u00e4hlen und irgendein geheimes Geheimnis erkl\u00e4ren. Alle hoffen darauf, aber aus irgendeinem Grund passiert nichts. Und das, weil das Geheimnis nicht in den Kennzahlen gesucht werden sollte!<\/p>\n

F\u00fcr Ivan war das ein durchlaufener Schritt. Er verstand, dass Kennzahlen einfach ein gew\u00f6hnliches Holzlineal sind<\/a><\/noindex> f\u00fcr Messungen, und alle Geheimnisse m\u00fcssen in dem Einflussobjekt<\/a><\/noindex>, d.h. dem, was diese Kennzahl formt, gesucht werden.<\/p>\n

F\u00fcr einen Online-Shop w\u00e4re das Einflussobjekt seine Kunden, die Geld bringen, und f\u00fcr DevOps \u2013 die Teams, die Distributionen mit Hilfe der Pipeline erstellen und bereitstellen.<\/p>\n

Eines Tages, als er sich in einer bequemen Sessel in der Lobby niederlie\u00df, entschloss sich Ivan, gr\u00fcndlich zu \u00fcberlegen, wie er die DevOps-Kennzahlen sehen m\u00f6chte, wobei das Einflussobjekt die Teams sind.<\/p>\n

Ziel der DevOps-Kennzahlen<\/h2>\n

\nEs ist klar, dass jeder die Lieferzeit reduzieren m\u00f6chte. 200 Tage sind nat\u00fcrlich nicht akzeptabel. <\/p>\n

Aber wie, darum geht es?<\/a><\/noindex><\/p>\n

Im Unternehmen arbeiten hunderte von Teams, und t\u00e4glich durchlaufen Tausende von Distributionen die DevOps-Pipeline. Die tats\u00e4chliche Lieferzeit wird als Verteilung aussehen. Jedes Team hat seine eigene Zeit und seine eigenen Besonderheiten. Wie kann man in diesem Durcheinander irgendetwas finden?<\/p>\n

Die Antwort kam von selbst \u2013 wir m\u00fcssen die problematischen Teams finden und herausfinden, was bei ihnen passiert und warum es so lange dauert, und von den \"guten\" Teams lernen, wie man alles schnell macht. Dazu m\u00fcssen wir die Zeit messen, die die Teams an jedem der DevOps-St\u00e4nde verbringen:<\/p>\n

\"DevOps-Metriken
\n
\n\u201eZiel des Systems wird die Auswahl der Teams nach der Zeit sein, die sie an den St\u00e4nden verbringen, d.h. letztendlich m\u00fcssen wir eine Liste von Teams mit der ausgew\u00e4hlten Zeit und nicht nur eine Zahl erhalten.<\/p>\n

Wenn wir erfahren, wie viel Zeit insgesamt f\u00fcr den Stand aufgewendet wurde und wie viel Zeit f\u00fcr die Stillst\u00e4nde zwischen den St\u00e4nden aufgewendet wurde, k\u00f6nnen wir die Teams finden, sie anrufen und genauer die Gr\u00fcnde verstehen und diese beseitigen\u201c, dachte Ivan.<\/p>\n

\"DevOps-Metriken
\n <\/p>\n

Wie man die Lieferzeit f\u00fcr DevOps berechnet<\/h2>\n

F\u00fcr die Berechnung war es notwendig, tiefer in den DevOps-Prozess und dessen Wesen einzutauchen.<\/p>\n

Im Unternehmen werden nur eine begrenzte Anzahl von Systemen verwendet, und Informationen k\u00f6nnen nur aus diesen bezogen werden und sonst von nirgendwo.<\/p>\n

Alle Aufgaben im Unternehmen wurden in Jira erfasst. Wenn eine Aufgabe in Arbeit genommen wurde, wurde ein Branch daf\u00fcr erstellt, und nach der Implementierung wurde ein Commit in BitBucket und ein Pull Request gemacht. Bei der Annahme des PR (Pull Request) wurde automatisch ein Paket erstellt und im Nexus gespeichert. <\/p>\n

\"DevOps-Metriken
\n
\nAnschlie\u00dfend wurde das Paket auf mehreren St\u00e4nden mit Hilfe von Jenkins ausgerollt, um die Richtigkeit des Rollouts, die automatische und manuelle Tests zu \u00fcberpr\u00fcfen:<\/p>\n

\"DevOps-Metriken
\n
\nIvan skizzierte aus welchen Systemen welche Informationen entnommen werden k\u00f6nnen, um die Zeit an den St\u00e4nden zu berechnen:<\/p>\n