Sinqer, Ivan shpesh qeshte me përpjekjet e kota të kolegëve nga departamenti i monitorimit. Ata bënin përpjekje të mëdha për realizimin e metrikeve që u porosite nga drejtuesit e kompanisë. Ishin aq të zënë sa nuk donin të bënin asgjë tjetër.
Dhe drejtuesit gjithmonĂ« kĂ«rkonin mĂ« shumĂ« â ata vazhdimisht u porositeshin metrike tĂ« reja, duke harxhuar shumĂ« shpejt interesin pĂ«r ato qĂ« ishin bĂ«rĂ« mĂ« parĂ«.
Kohet e fundit, tĂ« gjithĂ« flisnin vetĂ«m pĂ«r LeadTime â koha e dĂ«rgimit tĂ« funksioneve tĂ« biznesit. Metrika tregon njĂ« numĂ«r tĂ« çmendur â 200 ditĂ« pĂ«r dĂ«rgimin e njĂ« detyre. Si gjithĂ« ata çudianin, lartĂ«suan duar tĂ« tyre drejt qiellit!
Pas një kohe, zhurma filloi të qetësohej dhe dirigjenti dha një porosi për krijimin e një metri të ri.
Iu bë e qartë Ivanit se edhe metrikën e re do ta zbehet qetë në një qoshe të errët.
NĂ« tĂ« vĂ«rtetĂ«, mendoi Ivan, njohja e numrit nuk i thotĂ« askujt asgjĂ«. 200 ditĂ« ose 2 ditĂ« â nuk ka ndonjĂ« diferencĂ«, sepse numri nuk tregon arsyen dhe nuk e kupton nĂ«se Ă«shtĂ« mirĂ« apo keq.
Kjo është 'kurthi' tipik i metrikeve: duke iu dukur se një metrikë e re do të tregojë thelbin e qenies dhe do të shpjegojë ndonjë 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, ky ishte një hap i kaluar. Ai kuptonte se për matje, dhe të gjitha sekretet duhen kërkuar në , dmth, në atë që formon këtë metrikë.
PĂ«r njĂ« dyqan nĂ« internet, objekti i ndikimit do tĂ« ishin klientĂ«t e tij qĂ« sjellin para, ndĂ«rsa pĂ«r DevOps â ekipet qĂ« krijojnĂ« dhe publikojnĂ« distribucione duke pĂ«rdorur njĂ« konvej.
Një herë, duke u ulur në një karrige të rehatshme në holl, Ivan vendosi të mendonte mirë se si do të donte të shihte metrikat DevOps duke marrë parasysh se objekti i ndikimit ishin ekipet.
QĂ«llimi i metrikeve DevOps
ĂshtĂ« e qartĂ« se tĂ« gjithĂ«ve u kĂ«rkohet tĂ« zvogĂ«lojnĂ« kohĂ«n e dĂ«rgimit. 200 ditĂ« â sigurisht, kjo nuk Ă«shtĂ« e pranueshme.
Por si, kjo është pyetja?
NĂ« kompaninĂ« punojnĂ« qindra ekipe, dhe çdo ditĂ« kalojnĂ« mijĂ«ra distribucione pĂ«rmes konvej DevOps. Koha reale e dĂ«rgimit do tĂ« dukej si njĂ« shpĂ«rndarje. Ădo ekip do tĂ« ketĂ« kohĂ«n e vet dhe veçoritĂ« e veta. Si midis kĂ«tij kaosi mund tĂ« gjeni diçka?
PĂ«rgjigjja erdhi vetĂ« â duhej tĂ« gjenit ekipet me probleme dhe tĂ« kuptonit se çfarĂ« ndodhte me ta dhe pse e gjithĂ« kjo merrte kaq shumĂ« kohĂ«, dhe nga ekipet 'tĂ« mira' tĂ« mĂ«sojnĂ« si tĂ« bĂ«jnĂ« gjithçka shpejt. Dhe pĂ«r kĂ«tĂ« duhet tĂ« matet koha e kaluar nga ekipet nĂ« çdo fazĂ« tĂ« DevOps:
Qëllimi i sistemit do të ishte seleksioni i ekipeve sipas kohës që kalojnë përmes fazave, dmth, në fund ne duhet të fitojmë një listë ekipesh me kohën e zgjedhur, jo thjesht një numër.
Nëse ne zbulojmë se sa kohë është shpenzuar gjithsej për një fazë dhe sa kohë ka kaluar në pezullime midis fazave, atëherë mund të gjejmë ekipet, t'u telefonojmë, dhe të kuptojmë më në detaje arsyet dhe t'i eliminojmë', mendoi Ivan.
Si të llogarisim kohën e dërgimit për DevOps
Për llogaritjen e nevojitet të thellohemi në procesin DevOps dhe qeniet e tij.
Në kompani përdoren një numër i kufizuar sistemesh, dhe informacioni mund të merret vetëm nga ato dhe asnjë vend tjetër.
Të gjithë detyrat në kompani regjistroheshin në Jira. Kur një detyrë merrej në punë, krijohej një degë për të, dhe pas realizimit bëhej një komit në BitBucket dhe një Pull Request. Pas miratimit të PR (Pull Request), automatikisht krijohej një distribuim dhe ruhej në depo Nexus.
Më pas distribuimi publikohej në disa faza me ndihmën e Jenkins për të verifikuar saktësinë e përputhjes, testimin automatik dhe manual:
Ivan përshkroi se nga cilat sisteme mund të merret informacioni për të llogaritur kohën në faza:
- Nga Nexus â Koha e krijimit tĂ« distribucionit dhe emri i folderit qĂ« pĂ«rmbante kodin e ekipit
- Nga Jenkins â Koha e nisjes, kohĂ«zgjatja dhe rezultati nga çdo punĂ«, emri i fazĂ«s (nĂ« parametrat e punĂ«s), etapat (hapat e punĂ«s), lidhja me distribucionin nĂ« Nexus.
- Ivan vendosi që Jira dhe BitBucket të mos e përfshinin në konvej, pasi ato i përkasin më shumë fazës së zhvillimit se sa publikimit të një distribucioni të gatshëm për fazat.
Në bazë të informacionit të disponueshëm, skicohej një plan i tillë:
Duke ditur sa kohë kërkohet për të krijuar distribucione dhe sa kohë shpenzohet për secilin prej tyre, mund të llogaritet lehtësisht shpenzimi total për kalimin e të gjithë konvej DevOps (cikli i plotë).
Këto janë metrikat DevOps që Ivan përfundoi:
- Numri i distribucioneve të krijuara
- Pjesa e distribucioneve që 'hyjnë' në fazë dhe 'kalojnë' fazën
- Koha e kaluar në fazë (cikli i fazës)
- Cikli i plotë (koha totale për të gjitha stendat)
- Kohëzgjatja e punëve
- Pushimi ndërmjet stendave
- Pushimi ndërmjet nisjeve të punëve në një stendë të vetme
Nga njĂ«ra anĂ«, metrikat karakterizonin shumĂ« mirĂ« rrjedhĂ«n DevOps nĂ« aspektin e kohĂ«s, nga ana tjetĂ«r â ishin tĂ« konsideruara shumĂ« tĂ« thjeshta.
I dashuruar pas punës së kryer me sukses, Ivan përgatiti një prezantim dhe shkoi për ta paraqitur atë menaxhmentit.
Ai doli i mërzitur dhe me duar të ulura.
â Kjo Ă«shtĂ« njĂ« fiasko, vĂ«lla â u qesh kolegu me ironi...
Vijoni të lexoni në artikullin '».
Burimi: habr.com
