{"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\/da\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps metrikker \u2013 hvor f\u00e5r man data til beregningerne fra","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c6rligt talt grinede Ivan ofte af sine kollegers forg\u00e6ves bestr\u00e6belser i overv\u00e5gningsafdelingen. De gjorde en stor indsats for at implementere de metrikker, som virksomhedens ledelse bestilte. De var s\u00e5 optaget, at de ikke havde lyst til at lave noget som helst for andre. <\/p>\n

Men ledelsen var aldrig tilfreds \u2013 de bestilte konstant nye og nye metrikker, og de stoppede hurtigt med at bruge dem, der allerede var lavet.<\/p>\n

Den seneste tid talte alle kun om LeadTime \u2013 leveringstiden for forretningsfunktioner. Metrikken viste et vanvittigt tal \u2013 200 dage for at levere \u00e9n opgave. Hvordan de alle udbr\u00f8d og r\u00e6kkede h\u00e6nderne mod himlen!<\/p>\n

Efter noget tid tog st\u00f8jen gradvist af, og ledelsen bestilte endnu en metrik.<\/p>\n

Ivan vidste helt klart, at den nye metrik ogs\u00e5 ville d\u00f8 stille og roligt i et m\u00f8rkt hj\u00f8rne.<\/p>\n

Faktisk t\u00e6nkte Ivan, at antallet overhovedet ikke siger noget til nogen. 200 dage eller 2 dage \u2013 der er ingen forskel, fordi man ikke kan bestemme \u00e5rsagen ud fra tallene og forst\u00e5, om det er godt eller d\u00e5rligt.<\/p>\n

Dette er den typiske faldgrube med metrikker: Det virker som om, den nye metrik vil afsl\u00f8re livets essens og forklare en hemmelighed. Alle h\u00e5ber p\u00e5 det, men af en eller anden grund sker der ingenting. Fordi hemmeligheden skal ikke findes i metrikkerne!<\/p>\n

For Ivan var det et afsluttet kapitel. Han forstod, at metrikker er bare en almindelig tr\u00e6lineal<\/a><\/noindex> til m\u00e5linger, og alle hemmeligheder skal findes i p\u00e5virkningsobjektet<\/a><\/noindex>, dvs. det, der former denne metrik.<\/p>\n

For en webshop vil p\u00e5virkningsobjektet v\u00e6re dens kunder, der bringer penge, mens det for DevOps er de teams, der skaber og ruller distributioner ud ved hj\u00e6lp af et pipeline.<\/p>\n

En dag, da han satte sig komfortabelt i en stol i lobbyen, besluttede Ivan at t\u00e6nke grundigt over, hvordan han gerne ville se DevOps-metrikker, under hensyntagen til at p\u00e5virkningsobjektet er teams.<\/p>\n

M\u00e5let med DevOps-metrikker<\/h2>\n

\nDet er klart, at alle \u00f8nsker at reducere leveringstiden. 200 dage er selvf\u00f8lgelig ikke acceptabelt. <\/p>\n

Men hvordan, det er sp\u00f8rgsm\u00e5let?<\/a><\/noindex><\/p>\n

I virksomheden arbejder der hundreder af teams, og der passerer tusinder af distributioner gennem DevOps-pipelinen hver dag. Den reelle leveringstid vil se ud som en fordeling. Hver af teams vil have sin egen tid og sine egne s\u00e6regenheder. Hvordan kan man finde noget som helst blandt dette kaos?<\/p>\n

Svaret kom af sig selv \u2013 vi skal finde de problematiske teams og forst\u00e5, hvad der sker, og hvorfor det tager s\u00e5 lang tid, og fra de \"gode\" teams l\u00e6re, hvordan man g\u00f8r det hele hurtigt. Og for at g\u00f8re dette er det n\u00f8dvendigt at m\u00e5le den tid, som holdene bruger p\u00e5 hver af DevOps-standene:<\/p>\n

\"DevOps
\n
\n\"Systemets m\u00e5l vil v\u00e6re at udv\u00e6lge teams baseret p\u00e5 den tid, de bruger p\u00e5 standene, dvs. vi skal i sidste ende have en liste over teams med den valgte tid, ikke et tal.<\/p>\n

Hvis vi f\u00e5r indsigt i, hvor meget tid der samlet set er brugt p\u00e5 standen, og hvor meget tid der er brugt p\u00e5 spildtid mellem standene, kan vi finde holdene, ringe til dem og f\u00e5 en mere detaljeret forst\u00e5else af \u00e5rsagerne og fjerne dem,\" t\u00e6nkte Ivan.<\/p>\n

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

Hvordan man beregner leveringstiden for DevOps<\/h2>\n

For at beregne dette var det n\u00f8dvendigt at dykke dybere ned i DevOps-processen og dens entiteter.<\/p>\n

Virksomheden bruger et begr\u00e6nset antal systemer, og oplysninger kan kun f\u00e5s fra dem og ikke andre steder.<\/p>\n

Alle opgaver i virksomheden blev registreret i Jira. N\u00e5r en opgave blev taget til behandling, blev der oprettet en branch, og efter implementeringen blev der lavet et commit i BitBucket og Pull Request. Ved godkendelse af PR (Pull Request) blev der automatisk oprettet en distribution og gemt i Nexus-lageret. <\/p>\n

\"DevOps
\n
\nDerefter blev distributionen rullet ud p\u00e5 flere stande ved hj\u00e6lp af Jenkins til at kontrollere korrektheden af \u200b\u200binstallation, automatisk og manuel testning:<\/p>\n

\"DevOps
\n
\nIvan skitserede, fra hvilke systemer der kan hentes information for at beregne tiden p\u00e5 standene:<\/p>\n