Kuwa mkweli, Ivan mara nyingi alicheka juhudi zisizo na maana za wenzake kutoka idara ya ufuatiliaji. Walifanya juhudi kubwa kutekeleza vipimo ambavyo wasimamizi wa kampuni waliwaamuru kuafiki. Walikuwa na shughuli nyingi sana hivi kwamba hawakutaka mtu mwingine yeyote afanye chochote.
Lakini haikutosha kwa wasimamizi - waliagiza kila mara vipimo vipya zaidi na zaidi, na kuacha haraka sana kutumia yale ambayo yalikuwa yamefanywa hapo awali.
Hivi majuzi, kila mtu amekuwa akizungumza kuhusu LeadTime - wakati wa utoaji wa vipengele vya biashara. Kipimo kilionyesha nambari ya kichaa - siku 200 kuwasilisha kazi moja. Jinsi kila mtu alishtuka na kuinua mikono yake mbinguni!
Baada ya muda, kelele ilipungua polepole na wasimamizi walipokea agizo la kuunda kipimo kingine.
Ilikuwa wazi kabisa kwa Ivan kwamba metriki mpya ingekufa kimya kimya kwenye kona ya giza.
Hakika, Ivan alifikiria, kujua nambari hiyo haiambii mtu yeyote chochote. Siku 200 au siku 2 - hakuna tofauti, kwa sababu haiwezekani kuamua sababu kwa idadi na kuelewa ikiwa ni nzuri au mbaya.
Huu ni mtego wa kawaida wa vipimo: inaonekana kwamba kipimo kipya kitaeleza kiini cha kuwepo na kueleza siri fulani ya siri. Kila mtu anatarajia sana kwa hili, lakini kwa sababu fulani hakuna kinachotokea. Ndiyo, kwa sababu siri haipaswi kupatikana katika metriki!
Kwa Ivan, hii ilikuwa hatua iliyopitishwa. Alielewa hilo kwa vipimo, na siri zote lazima zitafutwe , i.e. ni kwamba kipimo hiki kimeundwa.
Kwa duka la mtandaoni, kitu cha ushawishi kitakuwa wateja wake wanaoleta pesa, na kwa DevOps, itakuwa timu zinazounda na kusambaza usambazaji kwa kutumia bomba.
Siku moja, akiwa ameketi kwenye kiti cha starehe kwenye ukumbi, Ivan aliamua kufikiria kwa uangalifu jinsi alitaka kuona metriki za DevOps, akizingatia ukweli kwamba kitu cha ushawishi ni timu.
Madhumuni ya Vipimo vya DevOps
Ni wazi kwamba kila mtu anataka kupunguza muda wa kujifungua. Siku 200, kwa kweli, sio nzuri.
Lakini jinsi gani, hilo ni swali?
Kampuni inaajiri mamia ya timu, na maelfu ya usambazaji hupitia bomba la DevOps kila siku. Wakati halisi wa utoaji utaonekana kama usambazaji. Kila timu itakuwa na wakati wake na sifa zake. Unawezaje kupata chochote kati ya fujo hii?
Jibu liliibuka kawaida - tunahitaji kupata timu za shida na kujua nini kinaendelea nazo na kwa nini inachukua muda mrefu, na kujifunza kutoka kwa timu "nzuri" jinsi ya kufanya kila kitu haraka. Na ili kufanya hivyo, unahitaji kupima muda unaotumiwa na timu katika kila stendi za DevOps:
“Madhumuni ya mfumo huo yatakuwa ni kuchagua timu kulingana na muda wa kupita viwanjani, i.e. Kama matokeo, tunapaswa kupata orodha ya amri na wakati uliochaguliwa, na sio nambari.
Ikiwa tutagundua ni muda gani uliotumika kwenye stendi kwa jumla na ni muda gani uliotumika kwa mapumziko kati ya stendi, tunaweza kupata timu, kuziita na kuelewa sababu kwa undani zaidi na kuziondoa, "alifikiria Ivan.
Jinsi ya Kuhesabu Wakati wa Uwasilishaji kwa DevOps
Ili kuihesabu, ilikuwa ni lazima kuingia kwenye mchakato wa DevOps na kiini chake.
Kampuni hutumia idadi ndogo ya mifumo, na habari inaweza kupatikana tu kutoka kwao na mahali pengine popote.
Kazi zote katika kampuni zilisajiliwa huko Jira. Wakati kazi ilichukuliwa, tawi liliundwa kwa ajili yake, na baada ya utekelezaji, ahadi ilifanywa kwa BitBucket na Ombi la Kuvuta. Wakati PR (Ombi la Kuvuta) lilikubaliwa, usambazaji uliundwa kiotomatiki na kuhifadhiwa kwenye hazina ya Nexus.
Kisha, usambazaji ulizinduliwa kwenye vituo kadhaa kwa kutumia Jenkins kuangalia usahihi wa uchapishaji, upimaji otomatiki na wa mwongozo:
Ivan alielezea kutoka kwa mifumo gani ni habari gani inaweza kuchukuliwa kuhesabu wakati kwenye vituo:
- Kutoka kwa Nexus - Wakati wa kuunda usambazaji na jina la folda ambayo ilikuwa na msimbo wa amri
- Kutoka kwa Jenkins - Muda wa kuanza, muda na matokeo ya kila kazi, jina la kusimama (katika vigezo vya kazi), hatua (hatua za kazi), kiungo kwa usambazaji katika Nexus.
- Ivan aliamua kutojumuisha Jira na BitBucket kwenye bomba, kwa sababu ... zilihusiana zaidi na hatua ya maendeleo, na sio kusambaza usambazaji uliomalizika kwenye stendi.
Kulingana na habari inayopatikana, mchoro ufuatao ulichorwa:
Kujua inachukua muda gani kuunda usambazaji na ni muda gani unaotumika kwa kila mmoja wao, unaweza kuhesabu kwa urahisi gharama zote za kupitia bomba zima la DevOps (mzunguko kamili).
Hapa kuna vipimo vya DevOps ambavyo Ivan alimalizia:
- Idadi ya usambazaji iliyoundwa
- Sehemu ya usambazaji ambao "ulikuja" kwenye msimamo na "kupitisha" msimamo
- Muda uliotumika kwenye stendi (mzunguko wa kusimama)
- Mzunguko kamili (jumla ya muda kwa stendi zote)
- Muda wa kazi
- Muda wa kupumzika kati ya vituo
- Muda wa kupumzika kati ya uzinduzi wa kazi kwenye stendi moja
Kwa upande mmoja, vipimo vilibainisha bomba la DevOps vizuri sana kwa suala la wakati, kwa upande mwingine, zilizingatiwa kuwa rahisi sana.
Kwa kuridhika na kazi iliyofanywa vizuri, Ivan alitoa mada na kwenda kuiwasilisha kwa usimamizi.
Alirudi akiwa mwenye huzuni na mikono yake ikiwa chini.
"Hii ni fiasco, kaka," mfanyikazi huyo mwenye kejeli alitabasamu ...
Soma zaidi katika makala "'.
Chanzo: mapenzi.com