{"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\/no\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps-metrikker \u2013 hvor skaffer man data for beregninger","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c6rlig talt lo Ivan ofte av kollegenes forgjeves anstrengelser fra overv\u00e5kingsavdelingen. De la ned store krefter for \u00e5 implementere metrikker bestilt av ledelsen i selskapet. De var s\u00e5 opptatt at de ikke ville gj\u00f8re noe annet. <\/p>\n

Og ledelsen var aldri forn\u00f8yd \u2013 de bestilte stadig flere og flere metrikker og sluttet raskt \u00e5 bruke det som allerede var gjort.<\/p>\n

N\u00e5 om dagen var det bare snakk om LeadTime \u2013 tiden det tok \u00e5 levere forretningsfunksjoner. Metrikken viste et vanvittig tallet \u2013 200 dager for \u00e5 levere \u00e9n oppgave. Hvordan folk sukka, gispte og l\u00f8ftet hendene mot himmelen!<\/p>\n

Etter en stund stilnet st\u00f8yen, og ledelsen ba om \u00e5 lage enda en metrik.<\/p>\n

Ivan forsto godt at den nye metrikken ogs\u00e5 ville d\u00f8 stille i et m\u00f8rkt hj\u00f8rne.<\/p>\n

Virkelig, tenkte Ivan, tallet forteller ingen noe som helst. 200 dager eller 2 dager \u2013 det er ingen forskjell, fordi man kan ikke utlede \u00e5rsaken eller avgj\u00f8re om det er bra eller d\u00e5rlig ut fra tallet.<\/p>\n

Dette er den typiske fellene med metrikker: det virker som om den nye metrikken vil avsl\u00f8re livets essens og forklare en skjult hemmelighet. Alle h\u00e5per s\u00e5 mye p\u00e5 dette, men ingenting skjer av en eller annen grunn. Fordi hemmeligheten ikke skal s\u00f8kes i metrikker!<\/p>\n

For Ivan var dette et tema han allerede hadde v\u00e6rt igjennom. Han visste at metrikker \u2013 det er bare en vanlig trelineal<\/a><\/noindex> for m\u00e5linger, og alle hemmelighetene m\u00e5 s\u00f8kes i p\u00e5virkningsobjektet<\/a><\/noindex>, det vil si det som former denne metrikken.<\/p>\n

For en nettbutikk vil p\u00e5virkningsobjektet v\u00e6re kundene som bringer inn penger, mens for DevOps vil det v\u00e6re teamene som lager og distribuerer pakker ved hjelp av r\u00f8rledningen.<\/p>\n

En dag, mens han slappet av i en komfortabel stol i hallen, bestemte Ivan seg for \u00e5 tenke grundig gjennom hvordan han \u00f8nsket \u00e5 se DevOps-metrikker med tanke p\u00e5 at p\u00e5virkningsobjektet er teamene.<\/p>\n

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

\nDet er klart at alle \u00f8nsker \u00e5 redusere leveringstiden. 200 dager \u2013 det er jo helt uholdbart. <\/p>\n

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

I selskapet jobber hundrevis av team, og tusenvis av pakker passerer gjennom DevOps-r\u00f8rledningen hver dag. Den reelle leveringstiden vil fremst\u00e5 som en fordeling. Hvert team vil ha sin egen tid og sine egne s\u00e6regenheter. Hvordan kan man finne noe som helst blant dette kaoset?<\/p>\n

Svaret kom av seg selv \u2013 man m\u00e5 finne de problematiske teamene og finne ut hva som skjer med dem og hvorfor det tar s\u00e5 lang tid, og av \u00abgode\u00bb team l\u00e6re hvordan alt gj\u00f8res raskt. For dette er det n\u00f8dvendig \u00e5 m\u00e5le tiden teamene bruker p\u00e5 hver av DevOps-standene:<\/p>\n

\"DevOps-metrikker
\n
\n\u00abM\u00e5let med systemet vil v\u00e6re \u00e5 velge team basert p\u00e5 tiden det tar \u00e5 gjennomf\u00f8re standene, det vil si at vi til slutt m\u00e5 f\u00e5 en liste over team med den valgte tiden, og ikke bare et tall.<\/p>\n

Hvis vi finner ut hvor mye tid som totalt er brukt p\u00e5 standen og hvor mye tid som er brukt p\u00e5 venting mellom standene, kan vi kontakte teamene, snakke med dem og f\u00e5 en mer detaljert forst\u00e5else av \u00e5rsakene og fjerne dem\u00bb, tenkte Ivan.<\/p>\n

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

Hvordan beregne leveringstid for DevOps<\/h2>\n

For \u00e5 kunne beregne dette m\u00e5tte vi g\u00e5 dypere inn i DevOps-prosessen og dens essens.<\/p>\n

I selskapet brukes et begrenset antall systemer, og informasjon kan bare hentes fra dem, ingen andre steder.<\/p>\n

Alle oppgaver i selskapet ble registrert i Jira. N\u00e5r en oppgave ble tatt til behandling, ble det opprettet en branch for den, og etter implementering ble det gjort et commit i BitBucket og en Pull Request. N\u00e5r PR (Pull Request) ble akseptert, ble det automatisk opprettet et distribusjonsregnskap og lagret i Nexus-lageret. <\/p>\n

\"DevOps-metrikker
\n
\nDeretter ble distribusjonen rullet ut p\u00e5 flere stander med hjelp av Jenkins for \u00e5 sjekke korrektheten av utrullingen, automatisk og manuell testing:<\/p>\n

\"DevOps-metrikker
\n
\nIvan beskrev fra hvilke systemer hvilken informasjon som kan hentes for \u00e5 beregne tiden p\u00e5 standene:<\/p>\n