{"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\/sv\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps-m\u00e4tningar \u2013 varifr\u00e5n man tar data f\u00f6r ber\u00e4kningar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c4rligt talat skrattade Ivan ofta \u00e5t sina kollegers meningsl\u00f6sa anstr\u00e4ngningar i \u00f6vervakningsavdelningen. De gjorde enorma insatser f\u00f6r att genomf\u00f6ra de m\u00e4tetal som f\u00f6retagsledningen best\u00e4llde. De var s\u00e5 upptagna att de inte ville g\u00f6ra n\u00e5gonting mer f\u00f6r n\u00e5gon annan. <\/p>\n

Men ledningen var alltid missn\u00f6jd \u2013 de best\u00e4llde st\u00e4ndigt nya och nya m\u00e4tetal, och slutade snabbt att anv\u00e4nda de som redan hade gjorts.<\/p>\n

P\u00e5 senare tid pratade alla bara om LeadTime \u2013 tiden f\u00f6r att leverera aff\u00e4rsfunktioner. M\u00e4tetalet visade ett galet nummer \u2013 200 dagar f\u00f6r att leverera en uppgift. Hur alla gnodde, klagade och lyfte h\u00e4nderna mot himlen!<\/p>\n

Efter ett tag tystnade oljudet och ledningen kom med en best\u00e4llning p\u00e5 att skapa ytterligare ett m\u00e4tetal.<\/p>\n

Det var helt klart f\u00f6r Ivan att det nya m\u00e4tetalet ocks\u00e5 skulle d\u00f6 stillsamt i ett m\u00f6rkt h\u00f6rn.<\/p>\n

Verkligen, funderade Ivan, att k\u00e4nna till siffran s\u00e4ger ingenting f\u00f6r n\u00e5gon. 200 dagar eller 2 dagar \u2013 det spelar ingen roll, eftersom man inte kan avg\u00f6ra orsaken och f\u00f6rst\u00e5 om det \u00e4r bra eller d\u00e5ligt baserat p\u00e5 siffran.<\/p>\n

Det \u00e4r den typiska f\u00e4llan med m\u00e4tetal: det verkar som om det nya m\u00e4tetalet kommer att f\u00f6rklara livets essens och avsl\u00f6ja en hemlighet. Alla har s\u00e5 stora f\u00f6rhoppningar, men ingenting h\u00e4nder av n\u00e5gon anledning. F\u00f6r hemligheten finns inte i m\u00e4tetalen!<\/p>\n

F\u00f6r Ivan var detta ett f\u00f6rflutet stadium. Han f\u00f6rstod att m\u00e4tetal bara \u00e4r en vanlig tr\u00e4linjal<\/a><\/noindex> f\u00f6r m\u00e4tningar, medan alla hemligheter m\u00e5ste s\u00f6kas i p\u00e5verkanens objekt<\/a><\/noindex>, dvs. det som formar detta m\u00e4tetal.<\/p>\n

F\u00f6r en webbshop kommer p\u00e5verkanens objekt att vara dess kunder som genererar int\u00e4kter, medan f\u00f6r DevOps kommer det att vara teamen som skapar och distribuerar distributioner med hj\u00e4lp av en pipeline.<\/p>\n

En g\u00e5ng, n\u00e4r han satte sig i en bekv\u00e4m stol i lobbyn, best\u00e4mde Ivan sig f\u00f6r att noggrant t\u00e4nka p\u00e5 hur han skulle vilja se DevOps-m\u00e4tetalen med tanke p\u00e5 att p\u00e5verkanens objekt \u00e4r teamen.<\/p>\n

Syftet med DevOps-m\u00e4tetal<\/h2>\n

\nDet \u00e4r uppenbart att alla vill minska leveranstiden. 200 dagar \u2013 det g\u00e5r f\u00f6rst\u00e5s inte. <\/p>\n

Men hur? Det \u00e4r fr\u00e5gan.<\/a><\/noindex><\/p>\n

Det arbetar hundratals team i f\u00f6retaget, och tusentals distributioner passerar genom DevOps-pipelinen varje dag. Den verkliga leveranstiden kommer att se ut som en f\u00f6rdelning. Varje team kommer att ha sin egen tid och sina egna karakteristika. Hur kan man hitta n\u00e5got i detta kaos?<\/p>\n

Svaret kom av sig sj\u00e4lv \u2013 vi m\u00e5ste hitta problematiska team och f\u00f6rst\u00e5 vad som h\u00e4nder med dem och varf\u00f6r det tar s\u00e5 l\u00e5ng tid, och l\u00e4ra oss av de \"bra\" teamen hur man g\u00f6r allt snabbt. F\u00f6r detta kr\u00e4vs det att vi m\u00e4ter tiden som teamen tillbringar p\u00e5 varje DevOps-st\u00e4ll.<\/p>\n

\"DevOps-m\u00e4tningar
\n
\nM\u00e5let f\u00f6r systemet kommer att vara att v\u00e4lja team baserat p\u00e5 tiden de tar att genomg\u00e5 st\u00e4llena, d.v.s. vi ska i slut\u00e4ndan f\u00e5 en lista \u00f6ver team med valda tider ist\u00e4llet f\u00f6r siffror.<\/p>\n

Om vi f\u00e5r reda p\u00e5 hur mycket tid som totalt har spenderats p\u00e5 varje st\u00e4ll och hur mycket tid som har g\u00e5tt till spillo mellan st\u00e4llen, kan vi hitta teamen, kontakta dem och unders\u00f6ka orsakerna mer ing\u00e5ende f\u00f6r att \u00e5tg\u00e4rda dem,\u201d t\u00e4nkte Ivan.<\/p>\n

\"DevOps-m\u00e4tningar
\n <\/p>\n

Hur man ber\u00e4knar ledtider f\u00f6r DevOps<\/h2>\n

F\u00f6r att g\u00f6ra ber\u00e4kningarna beh\u00f6vde vi f\u00f6rdjupa oss i DevOps-processen och dess k\u00e4rna.<\/p>\n

F\u00f6retaget anv\u00e4nder ett begr\u00e4nsat antal system, och informationen kan endast erh\u00e5llas fr\u00e5n dem och ingen annanstans.<\/p>\n

Alla uppgifter i f\u00f6retaget registrerades i Jira. N\u00e4r en uppgift togs i arbete skapades en branch f\u00f6r den, och efter genomf\u00f6randet gjordes en commit i BitBucket och en Pull Request. Vid godk\u00e4nnande av PR (Pull Request) skapades automatiskt en distribution och sparades i Nexus-lagringen. <\/p>\n

\"DevOps-m\u00e4tningar
\n
\nD\u00e4refter rullades distributionen ut p\u00e5 flera st\u00e4llen med hj\u00e4lp av Jenkins f\u00f6r att kontrollera korrektheten av installationen, inklusive automatiserade och manuella tester:<\/p>\n

\"DevOps-m\u00e4tningar
\n
\nIvan listade vilka system som kan ge vilken information f\u00f6r att ber\u00e4kna tiden p\u00e5 st\u00e4llena:<\/p>\n