Iskreno povedano, se je Ivan pogosto smejal jalovim prizadevanjem kolegov iz oddelka za spremljanje. Zelo so se trudili implementirati metrike, ki jim jih je naročilo vodstvo podjetja. Bili so tako zaposleni, da niso želeli, da bi kdo drug kaj naredil.
Vendar to ni bilo dovolj za vodstvo - nenehno so naročili nove in nove meritve in zelo hitro prenehali uporabljati tisto, kar je bilo storjeno prej.
Zadnje čase vsi govorijo o LeadTime - času za dostavo poslovnih funkcij. Meritev je pokazala noro številko – 200 dni za izvedbo ene naloge. Kako so vsi oihali in ahali ter dvigovali roke proti nebu!
Čez nekaj časa se je hrup postopoma zmanjšal in vodstvo je prejelo ukaz, naj ustvari drugo metriko.
Ivanu je bilo popolnoma jasno, da bo nova metrika tako tiho zamrla v temnem kotu.
Res, si je mislil Ivan, poznavanje številke nikomur ne pove čisto nič. 200 dni ali 2 dni - ni razlike, ker je nemogoče določiti razlog po številu in razumeti, ali je dobro ali slabo.
To je tipična past metrike: zdi se, da bo nova metrika povedala bistvo obstoja in pojasnila neko tajno skrivnost. Vsi tako zelo upajo na to, a se iz nekega razloga nič ne zgodi. Da, saj skrivnost ne bi smela iskati v meritvah!
Za Ivana je bila to prehojena faza. To je razumel za meritve, vse skrivnosti pa je treba iskati v , tj. je, da je ta metrika oblikovana.
Za spletno trgovino bodo predmet vpliva njene stranke, ki prinašajo denar, za DevOps pa bodo to ekipe, ki ustvarjajo in uvajajo distribucije s pomočjo cevovoda.
Nekega dne, ko je sedel v udobnem stolu v dvorani, se je Ivan odločil skrbno premisliti, kako želi videti meritve DevOps, ob upoštevanju dejstva, da so predmet vpliva ekipe.
Namen meritev DevOps
Jasno je, da si vsi želijo skrajšati čas dostave. 200 dni seveda ni dobro.
Toda kako, to je vprašanje?
Podjetje zaposluje na stotine ekip in na tisoče distribucij gre vsak dan skozi cevovod DevOps. Dejanski čas dostave bo prikazan kot distribucija. Vsaka ekipa bo imela svoj čas in svoje značilnosti. Kako najti kaj v tej zmešnjavi?
Odgovor se je pojavil sam po sebi - poiskati moramo problematične ekipe in ugotoviti, kaj se z njimi dogaja in zakaj tako dolgo traja, ter se od »dobrih« ekip naučiti, kako vse narediti hitro. Če želite to narediti, morate izmeriti čas, ki ga ekipe porabijo za vsako od stojnic DevOps:
»Namen sistema bo selekcija ekip glede na čas prehoda mimo tribun, tj. Kot rezultat bi morali dobiti seznam ukazov z izbranim časom in ne številko.
Če ugotovimo, koliko časa je bilo skupaj na tribuni in koliko časa je bilo zastojev med tribunami, lahko poiščemo ekipe, jih pokličemo in podrobneje razumemo razloge ter jih odpravimo,« je razmišljal Ivan.
Kako izračunati čas dostave za DevOps
Za izračun se je bilo treba poglobiti v proces DevOps in njegovo bistvo.
Podjetje uporablja omejeno število sistemov, informacije pa je mogoče pridobiti le pri njih in nikjer drugje.
Vse naloge v podjetju so bile registrirane v Jiri. Ko je bila naloga prevzeta, je bila zanjo ustvarjena veja, po implementaciji pa je bila opravljena obveza za BitBucket in Pull Request. Ko je bila PR (povlečna zahteva) sprejeta, je bila distribucija samodejno ustvarjena in shranjena v repozitoriju Nexusa.
Nato je bila distribucija uvedena na več stojalih z uporabo Jenkinsa za preverjanje pravilnosti uvajanja, samodejnega in ročnega testiranja:
Ivan je opisal, iz katerih sistemov je mogoče katere podatke vzeti za izračun časa na tribunah:
- Iz Nexusa – čas ustvarjanja distribucije in ime mape, ki je vsebovala kodo ukaza
- Od Jenkinsa – Začetni čas, trajanje in rezultat vsakega opravila, ime stojala (v parametrih opravila), stopnje (koraki opravila), povezava do distribucije v Nexusu.
- Ivan se je odločil, da Jire in BitBucketa ne bo vključil v pripravo, ker ... bili so bolj povezani s stopnjo razvoja in ne z uvajanjem končane distribucije na stojala.
Na podlagi razpoložljivih informacij je bil sestavljen naslednji diagram:
Če veste, koliko časa traja ustvarjanje distribucij in koliko časa se porabi za vsako od njih, lahko preprosto izračunate skupne stroške celotnega cevovoda DevOps (celoten cikel).
Tukaj so meritve DevOps, ki jih je Ivan na koncu dobil:
- Število ustvarjenih distribucij
- Delež distribucij, ki so "prišle" na stojnico in "prešle" stojnico
- Čas, porabljen na stojalu (cikel stojišča)
- Celoten cikel (skupni čas za vsa stojala)
- Trajanje dela
- Zastoji med tribunami
- Zastoji med zagonom opravil na istem stojalu
Po eni strani so metrike zelo dobro označile cevovod DevOps v smislu časa, po drugi strani pa so veljale za zelo preproste.
Zadovoljen z dobro opravljenim delom je Ivan naredil predstavitev in jo odšel predstavit vodstvu.
Vrnil se je mrk in s spuščenimi rokami.
"To je fiasko, brat," se je nasmehnil ironični kolega ...
Preberite več v članku “".
Vir: www.habr.com