Për të qenë i sinqertë, Ivani shpesh qeshte me përpjekjet e kota të kolegëve të tij nga departamenti i monitorimit. Ata bënë përpjekje të mëdha për të zbatuar metrikat që menaxhmenti i kompanisë i urdhëroi të arrinin. Ata ishin aq të zënë sa nuk donin që dikush tjetër të bënte asgjë.
Por nuk ishte e mjaftueshme për menaxhmentin - ata vazhdimisht porositën gjithnjë e më shumë metrika të reja, shumë shpejt duke pushuar së përdoruri atë që ishte bërë më parë.
Kohët e fundit, të gjithë kanë folur për LeadTime - koha për ofrimin e veçorive të biznesit. Metrika tregoi një numër të çmendur - 200 ditë për të kryer një detyrë. Sa u hodhën dhe aahed të gjithë dhe ngritën duart drejt qiellit!
Pas ca kohësh, zhurma u shua gradualisht dhe menaxhmenti mori një urdhër për të krijuar një metrikë tjetër.
Ishte plotësisht e qartë për Ivanin se metrika e re do të vdiste po aq në heshtje në një cep të errët.
Në të vërtetë, mendoi Ivan, duke ditur se numri nuk i tregon askujt asgjë fare. 200 ditë ose 2 ditë - nuk ka dallim, sepse është e pamundur të përcaktohet arsyeja nga numri dhe të kuptohet nëse është e mirë apo e keqe.
Ky është një kurth tipik i metrikës: duket se një metrikë e re do të tregojë thelbin e ekzistencës dhe do të shpjegojë një sekret sekret. Të gjithë shpresojnë kaq shumë për këtë, por për disa arsye asgjë nuk ndodh. Po, sepse sekreti nuk duhet gjetur në metrikë!
Për Ivanin, kjo ishte një fazë e kaluar. Ai e kuptoi atë për matjet, dhe të gjitha sekretet duhet të kërkohen , d.m.th. është se është formuar kjo metrikë.
Për një dyqan online, objekti i ndikimit do të jenë klientët e tij që sjellin para, dhe për DevOps, do të jenë ekipet që krijojnë dhe nxjerrin shpërndarjet duke përdorur një tubacion.
Një ditë, i ulur në një karrige të rehatshme në sallë, Ivan vendosi të mendojë me kujdes se si donte të shihte metrikat e DevOps, duke marrë parasysh faktin se objekti i ndikimit janë ekipet.
Qëllimi i Metrikës DevOps
Është e qartë se të gjithë duan të zvogëlojnë kohën e dorëzimit. 200 ditë, natyrisht, nuk janë të mira.
Por si, kjo është pyetja?
Kompania punëson qindra ekipe dhe mijëra shpërndarje kalojnë përmes tubacionit DevOps çdo ditë. Koha aktuale e dorëzimit do të shfaqet si shpërndarje. Çdo ekip do të ketë kohën e vet dhe karakteristikat e veta. Si mund të gjesh diçka mes kësaj rrëmuje?
Përgjigja doli natyrshëm - ne duhet të gjejmë ekipet problematike dhe të kuptojmë se çfarë po ndodh me ta dhe pse po zgjat kaq shumë, dhe të mësojmë nga ekipet "e mira" se si të bëjmë gjithçka shpejt. Dhe për ta bërë këtë, ju duhet të matni kohën e shpenzuar nga ekipet në secilën prej stendave të DevOps:
“Qëllimi i sistemit do të jetë përzgjedhja e ekipeve në bazë të kohës që kalojnë në tribuna, d.m.th. Si rezultat, ne duhet të marrim një listë komandash me kohën e zgjedhur, dhe jo një numër.
Nëse zbulojmë se sa kohë është harxhuar në tribunë në total dhe sa kohë është harxhuar për pushime ndërmjet tribunave, mund t'i gjejmë skuadrat, t'i thërrasim dhe të kuptojmë më në detaje arsyet dhe t'i eliminojmë ato”, mendoi Ivan.
Si të llogarisni kohën e dorëzimit për DevOps
Për ta llogaritur atë, ishte e nevojshme të thellohej në procesin DevOps dhe thelbin e tij.
Kompania përdor një numër të kufizuar sistemesh dhe informacioni mund të merret vetëm prej tyre dhe askund tjetër.
Të gjitha detyrat në kompani u regjistruan në Jira. Kur një detyrë u mor përsipër, u krijua një degë për të dhe pas zbatimit, u bë një angazhim për BitBucket dhe Kërkesë Pull. Kur u pranua një PR (Kërkesë tërheqjeje), një shpërndarje u krijua automatikisht dhe u ruajt në depon e Nexus.
Më pas, shpërndarja u shpërnda në disa stenda duke përdorur Jenkins për të kontrolluar korrektësinë e paraqitjes, testimit automatik dhe manual:
Ivan përshkroi nga cilat sisteme çfarë informacioni mund të merret për të llogaritur kohën në tribuna:
- Nga Nexus – Koha e krijimit të shpërndarjes dhe emri i dosjes që përmban kodin e komandës
- Nga Jenkins – Koha e fillimit, kohëzgjatja dhe rezultati i çdo pune, emri i stendës (në parametrat e punës), fazat (hapat e punës), lidhja me shpërndarjen në Nexus.
- Ivan vendosi të mos përfshijë Jira dhe BitBucket në tubacion, sepse... ato ishin më të lidhura me fazën e zhvillimit dhe jo me shpërndarjen e përfunduar në tribuna.
Bazuar në informacionin e disponueshëm, është hartuar diagrami i mëposhtëm:
Duke ditur se sa kohë duhet për të krijuar shpërndarje dhe sa kohë shpenzohet për secilën prej tyre, mund të llogaritni lehtësisht kostot totale të kalimit nëpër të gjithë tubacionin DevOps (cikli i plotë).
Këtu janë matjet e DevOps me të cilat përfundoi Ivan:
- Numri i shpërndarjeve të krijuara
- Pjesa e shpërndarjeve që "erdhën" në tribunë dhe "kaluan" stendën
- Koha e kaluar në stendë (cikli i qëndrimit)
- Cikli i plotë (koha totale për të gjitha tribunat)
- Kohëzgjatja e punës
- Koha e ndërprerjes ndërmjet tribunëve
- Koha e ndërprerjes ndërmjet nisjeve të punës në të njëjtin stendë
Nga njëra anë, metrikat karakterizuan shumë mirë tubacionin DevOps për sa i përket kohës, nga ana tjetër, ato konsideroheshin shumë të thjeshta.
I kënaqur me punën e bërë mirë, Ivan bëri një prezantim dhe shkoi ta prezantojë atë te menaxhmenti.
U kthye i zymtë dhe me duart ulur.
“Kjo është një fiasko o vëlla”, buzëqeshi kolegu ironik...
Lexoni më shumë në artikullin "'.
Burimi: www.habr.com