Sinqerisht, Ivan shpesh qeshte në përpjekjet e kota të kolegëve nga departamenti i monitorimit. Ata bënin përpjekje të mëdha për të realizuar metrikat që menaxhmenti i kompanisë u kërkonte. Ishin aq të zënë, saqë nuk donin të bënin asgjë tjetër për askënd.
Por menaxhmentit gjithmonĂ« i dukej pak â ata vazhdimisht kĂ«rkonin metrika tĂ« reja, duke u ndalur shumĂ« shpejt sĂ« pĂ«rdoruri ato qĂ« ishin krijuar mĂ« parĂ«.
Kohet e fundit, tĂ« gjithĂ« flisnin vetĂ«m pĂ«r LeadTime â koha e dĂ«rgimit tĂ« veçorive tĂ« biznesit. Metrika tregoi njĂ« numĂ«r tĂ« çmendur â 200 ditĂ« pĂ«r tĂ« dorĂ«zuar njĂ« detyrĂ«. Sa shumĂ« shpĂ«rthyen tĂ« gjithĂ« nĂ« çudi dhe ngritĂ«n duart lart!
Pas një kohe, zhurma gradualisht qetësohej dhe nga menaxhmenti erdhi një porosi për krijimin e një metrike tjetër.
Ishte krejt e qartë për Ivanin, se metrika e re do të vdiste gjithashtu qetësisht në një kënd të errët.
VĂ«rtet, mendoi Ivan, njohja e numrit nuk ka asnjĂ« kuptim pĂ«r askĂ«nd. 200 ditĂ« ose 2 ditĂ« â nuk ka asnjĂ« ndryshim, sepse nga numri nuk Ă«shtĂ« e mundur tĂ« pĂ«rcaktohet shkaku dhe tĂ« kuptohet nĂ«se Ă«shtĂ« mirĂ« apo keq.
Kjo është një kurth tipike metrikash: duket se metrika e re do të tregojë thelbin e ekzistencës dhe do të shpjegojë një sekret të fshehtë. Të gjithë shpresojnë për këtë, por ndonjëherë nuk ndodh asgjë. Sepse sekreti nuk duhet kërkuar në metrika!
Për Ivanin, kjo ishte një fazë e kaluar. Ai e dinte se për matje, dhe të gjitha sekretet duhet të kërkohen në , dmth., në atë që e formon këtë metrikë.
PĂ«r njĂ« dyqan online, objekti i ndikimit do tĂ« jenĂ« klientĂ«t e tij qĂ« sjellin para, ndĂ«rsa pĂ«r DevOps â ekipet qĂ« krijojnĂ« dhe qĂ« zbatojnĂ« distribucionet duke pĂ«rdorur konvejimin.
Një herë, duke u ulur në holl në një karrige të rehatshme, Ivan vendosi të mendojë si do të donte të shihte metrike DevOps, duke marrë parasysh se objekti i ndikimit janë ekipet.
QĂ«llimi i metrikave DevOps
ĂshtĂ« e qartĂ« se tĂ« gjithĂ« duan ta pakĂ«sojnĂ« kohĂ«n e dĂ«rgimit. 200 ditĂ« â sigurisht, nuk do tĂ« bĂ«jnĂ« fare.
Por si, kjo është çështja?
NĂ« kompani punojnĂ« qindra ekipe, dhe çdo ditĂ« nĂ«pĂ«r konvejimin DevOps kalojnĂ« mijĂ«ra distribucione. Koha e vĂ«rtetĂ« e dĂ«rgimit do tĂ« duket si njĂ« shpĂ«rndarje. Ădo ekip do tĂ« ketĂ« kohĂ«n e vet dhe veçoritĂ« e tij. Si midis kĂ«tij kaosi mund tĂ« gjejmĂ« ndonjĂ« gjĂ«?
PĂ«rgjigjja erdhi natyrshĂ«m â duhet tĂ« gjejmĂ« ekipet problematike dhe tĂ« kuptojmĂ« se çfarĂ« po ndodh me to dhe pse shkojnĂ« kaq ngadalĂ«, ndĂ«rsa nga ekipet "tĂ« mira" tĂ« mĂ«sojmĂ« si tĂ« bĂ«jmĂ« gjithçka shpejt. PĂ«r kĂ«tĂ« kĂ«rkohet tĂ« matet koha e kaluar nga ekipet nĂ« çdo nga stendat e DevOps:
Qëllimi i sistemit do të jetë përzgjedhja e ekipeve sipas kohës së kalimit në stenda, dmth në fund duhet të marrim një listë ekipesh me kohën e zgjedhur, dhe jo një numër.
Nëse ne zbulojmë sa kohë është shpenzuar gjithsej në një stend dhe sa kohë është kaluar në pezullime midis stendave, atëherë mund të gjejmë ekipet, t'u telefonojmë atyre dhe të kuptojmë më në detaje arsyet e për të eliminuar ato", mendoi Ivan.
Si të llogarisim kohën e dorëzimit për DevOps
Për llogaritjen ishte e nevojshme të thellohej në procesin e DevOps dhe natyrën e tij.
Në kompani përdoren një numër i kufizuar sistemesh, dhe informacioni mund të merret vetëm nga ato dhe askund tjetër.
Të gjitha detyrat në kompani regjistroheshin në Jira. Kur një detyrë merrte në punë, krijohej një branxhë për të, dhe pas realizimit bëhej një commit në BitBucket dhe Pull Request. Pasi PR (Pull Request) miratohej, automatikisht krijohej një distribuim dhe ruhej në depo Nexus.
Më pas distribuimi instalohej në disa stenda me ndihmën e Jenkins për të kontrolluar saktësinë e instalimit, testimit automatik dhe manual:
Ivan përshkroi se nga cilat sisteme mund të merret informacioni për të llogaritur kohën në stenda:
- Nga Nexus â Koha e krijimit tĂ« distribuimit dhe emri i dosjes, nĂ« tĂ« cilĂ«n ndodhej kodi i skuadrĂ«s
- Nga Jenkins â Koha e fillimit, e zgjatjes dhe rezultati i punĂ«s sĂ« çdo pune, emri i stendĂ«s (nĂ« parametrat e punĂ«s), fazat (hapet e punĂ«s), lidhja pĂ«r distribuimin nĂ« Nexus.
- Ivan vendosi që Jira dhe BitBucket të mos përfshihen në proces, pasi ato ishin më shumë të lidhura me fazën e zhvillimit, e jo me instalimin e distribuimit të gatshëm në stenda.
Në bazë të informacionit që kishte në dispozicion, u elaborua një skemë e tillë:
Duke ditur se sa kohë shpenzohet për krijimin e distribuimeve dhe sa kohë shpenzohet për secilën prej tyre, mund të llogaritet lehtësisht shpenzimi total për kalimin e gjithë linjës së DevOps (cikli i plotë).
Ja cilat DevOps-metrika i dolën Ivanit në përfundim:
- Numri i distribuimeve të krijuara
- Shkalla e distribuimeve, që "kanë kaluar" në stend dhe "kanë përfunduar" stendën
- Koha e kaluar në stend (cikli i stendës)
- Cikli i plotë (koha totale për të gjitha stendat)
- Kohëzgjatja e punëve
- Pauza ndërmjet stendave
- Pauza ndërmjet fillimeve të punëve në një stendë
Në një anë, metrikat e karakterizonin shumë mirë linjën DevOps në lidhje me kohën, nga ana tjetër - konsideroheshin shumë të thjeshta.
I gëzuar për punën e mirë të bërë, Ivan përgatiti një prezantim dhe shkoi ta paraqiste atë për drejtuesit.
Të kthyer, ai doli i mërzitur dhe me duar të varura.
â Kjo Ă«shtĂ« njĂ« dĂ«shtim, vĂ«llai â qeshi kolegu i ironishĂ«mâŠ
Vijoni të lexoni në artikullin "».
Burimi: habr.com
