{"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 man Daten f\u00fcr Berechnungen beziehen kann","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ehrlich gesagt, hat Ivan oft \u00fcber die vergeblichen Bem\u00fchungen seiner Kollegen aus der \u00dcberwachungsabteilung gelacht. Sie investierten unerm\u00fcdlich Zeit, um die Metriken zu implementieren, die das Management verlangte. Sie waren so besch\u00e4ftigt, dass sie nichts mehr f\u00fcr andere tun wollten. <\/p>\n

Aber das Management war nie zufrieden \u2013 es forderte st\u00e4ndig neue Metriken und h\u00f6rte sehr schnell auf, die bereits vorhandenen zu nutzen.<\/p>\n

In letzter Zeit wurde viel \u00fcber LeadTime gesprochen \u2013 die Zeit, die ben\u00f6tigt wird, um Gesch\u00e4ftsfunktionen bereitzustellen. Die Metrik zeigte eine verr\u00fcckte Zahl \u2013 200 Tage f\u00fcr die Bereitstellung einer einzigen Aufgabe. Wie alle dar\u00fcber entsetzt waren und ihre H\u00e4nde zum Himmel erhoben!<\/p>\n

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

Ivan war sich vollkommen sicher, dass auch die neue Metrik leise in einer dunklen Ecke sterben w\u00fcrde.<\/p>\n

In der Tat, dachte Ivan, sagt die Kenntnis der Zahl niemandem etwas. 200 Tage oder 2 Tage \u2013 es macht keinen Unterschied, denn an der Zahl l\u00e4sst sich weder der Grund erkennen noch verstehen, ob das gut oder schlecht ist.<\/p>\n

Dies ist eine typische Falle der Metriken: Es scheint, als w\u00fcrde eine neue Metrik das Wesen des Seins enth\u00fcllen und ein geheimes Geheimnis erkl\u00e4ren. Alle hoffen darauf, aber irgendwie passiert nichts. Denn das Geheimnis sollte man ganz woanders suchen \u2013 nicht in den Metriken!<\/p>\n

F\u00fcr Ivan war das ein bereits durchlaufener Prozess. Er verstand, dass Metriken lediglich ein gew\u00f6hnliches Ma\u00dfband<\/a><\/noindex> f\u00fcr Messungen sind, w\u00e4hrend alle Geheimnisse in dem Einflussobjekt<\/a><\/noindex>, d.h. in dem, was diese Metrik formt.<\/p>\n

F\u00fcr einen Online-Shop w\u00e4re das Einflussobjekt seine zahlenden Kunden, w\u00e4hrend es f\u00fcr DevOps die Teams sind, die Software-Pakete entwickeln und ausrollen, wobei sie Continuous Integration nutzen.<\/p>\n

Eines Tages, bequem in einem Stuhl in der Lobby sitzend, beschloss Ivan, sich Gedanken dar\u00fcber zu machen, wie er sich die DevOps-Metriken w\u00fcnscht, wobei das Einflussobjekt die Teams sind.<\/p>\n

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

\nIst klar, dass jeder die Lieferzeit reduzieren m\u00f6chte. 200 Tage \u2013 das ist nat\u00fcrlich inakzeptabel. <\/p>\n

Aber wie, das ist die Frage?<\/a><\/noindex><\/p>\n

In dem Unternehmen arbeiten Hunderte von Teams, und t\u00e4glich durchlaufen Tausende von Distributionen den DevOps-Pipeline. Die tats\u00e4chliche Lieferzeit wird als Verteilung erscheinen. Jedes Team wird seine eigene Zeit und spezielle Merkmale haben. Wie kann man in diesem Durcheinander \u00fcberhaupt etwas finden?<\/p>\n

Die Antwort lag auf der Hand \u2013 wir m\u00fcssen die problematischen Teams identifizieren und herausfinden, was bei ihnen vor sich geht und warum es so lange dauert, w\u00e4hrend wir bei den 'guten' Teams lernen, wie man alles schnell erledigt. Daf\u00fcr 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 es sein, Teams anhand der Zeit, die sie an den St\u00e4nden verbringen, auszuw\u00e4hlen, d.h. letztendlich sollten wir eine Liste von Teams mit den jeweiligen Zeiten erhalten, anstatt nur eine Zahl.<\/p>\n

Wenn wir herausfinden, wie viel Zeit insgesamt am Stand verbracht wurde und wie viel Zeit mit Wartezeiten zwischen den St\u00e4nden vergeudet wurde, k\u00f6nnen wir die Teams identifizieren, sie anrufen und die Ursachen im Detail analysieren und beseitigen\u201c, dachte Ivan.<\/p>\n

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

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

Um eine Berechnung durchzuf\u00fchren, war es erforderlich, tiefer in den DevOps-Prozess und seine Wesensz\u00fcge einzutauchen.<\/p>\n

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

Alle Aufgaben wurden im Unternehmen in Jira registriert. Wenn eine Aufgabe bearbeitet wurde, wurde ein Branch erstellt, und nach der Umsetzung wurde ein Commit in BitBucket durchgef\u00fchrt und ein Pull Request erstellt. Bei der Annahme des PR (Pull Request) wurde automatisch ein Distributionspaket erstellt und im Nexus-Repository gespeichert. <\/p>\n

\"DevOps-Metriken
\n
\nAnschlie\u00dfend wurde das Distributionspaket auf mehreren St\u00e4nden mit Hilfe von Jenkins ausgef\u00fchrt, um die Richtigkeit der Installation sowie automatisierte und manuelle Tests zu \u00fcberpr\u00fcfen:<\/p>\n

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