Tiesą sakant, Ivanas dažnai juokėsi iš bergždžių savo kolegų iš stebėjimo skyriaus pastangų. Jie dėjo dideles pastangas, kad įgyvendintų metriką, kurią įpareigojo įmonės vadovybė. Jie buvo tokie užsiėmę, kad nenorėjo, kad kas nors kitas nieko darytų.
Tačiau vadovybei to nepakako – jie nuolat užsakydavo vis daugiau naujų metrikų, labai greitai nustodami naudoti tai, kas buvo daroma anksčiau.
Pastaruoju metu visi kalba apie LeadTime – verslo funkcijų pristatymo laiką. Metrika rodė beprotišką skaičių – 200 dienų atlikti vieną užduotį. Kaip visi ūpavo, aadėjo ir pakėlė rankas į dangų!
Po kurio laiko triukšmas pamažu nurimo ir vadovybė gavo nurodymą sukurti kitą metriką.
Ivanui buvo visiškai aišku, kad nauja metrika taip pat tyliai mirs tamsiame kampe.
Iš tiesų, pagalvojo Ivanas, numerio žinojimas niekam nieko nesako. 200 dienų ar 2 dienos – jokio skirtumo, nes pagal skaičių neįmanoma nustatyti priežasties ir suprasti, ar tai gerai, ar blogai.
Tai tipiški metrikų spąstai: atrodo, kad nauja metrika pasakys egzistencijos esmę ir paaiškins kokią nors slaptą paslaptį. Visi to labai tikisi, bet kažkodėl nieko neįvyksta. Taip, nes paslapties nereikėtų rasti metrikoje!
Ivanui tai buvo praėjęs etapas. Jis tai suprato dėl išmatavimų ir visų paslapčių reikia ieškoti , t.y. yra tai, kad ši metrika yra suformuota.
Internetinei parduotuvei įtakos turės klientai, kurie atneša pinigų, o „DevOps“ – komandos, kurios kuria ir išleidžia paskirstymus naudodamos konvejerį.
Vieną dieną, atsisėdęs į patogią kėdę salėje, Ivanas nusprendė gerai apgalvoti, kaip nori matyti DevOps metriką, atsižvelgdamas į tai, kad įtakos objektas yra komandos.
„DevOps“ metrikos paskirtis
Akivaizdu, kad visi nori sutrumpinti pristatymo laiką. 200 dienų, žinoma, nieko gero.
Bet kaip, tai klausimas?
Įmonėje dirba šimtai komandų, o tūkstančiai platinimų kasdien eina per „DevOps“ dujotiekį. Faktinis pristatymo laikas bus rodomas kaip paskirstymas. Kiekviena komanda turės savo laiką ir savo ypatybes. Kaip galite rasti ką nors tarp šios netvarkos?
Atsakymas atsirado natūraliai – reikia surasti problemines komandas ir išsiaiškinti, kas su jomis vyksta ir kodėl tai užtrunka, o iš „gerų“ komandų pasimokyti, kaip viską padaryti greitai. Norėdami tai padaryti, turite išmatuoti laiką, kurį komandos praleidžia prie kiekvieno „DevOps“ stendo:
„Sistemos tikslas bus atrinkti komandas pagal laiką, kada jos pravažiuoja tribūnas, t.y. Dėl to turėtume gauti komandų sąrašą su pasirinktu laiku, o ne skaičiumi.
Jei išsiaiškinsime, kiek iš viso buvo praleista laiko stende, o kiek prastovos tarp tribūnų, galėsime surasti komandas, paskambinti ir išsamiau suprasti priežastis bei jas pašalinti“, – svarstė Ivanas. .
Kaip apskaičiuoti „DevOps“ pristatymo laiką
Norint jį apskaičiuoti, reikėjo įsigilinti į DevOps procesą ir jo esmę.
Įmonė naudoja ribotą skaičių sistemų, informacijos galima gauti tik iš jų ir niekur kitur.
Visos užduotys įmonėje buvo įregistruotos Jira. Kai buvo imtasi užduoties, jai buvo sukurtas filialas, o po įgyvendinimo – įsipareigojimas BitBucket ir Pull Request. Kai buvo priimtas PR (ištraukimo užklausa), platinimas buvo automatiškai sukurtas ir saugomas „Nexus“ saugykloje.
Tada paskirstymas buvo išleistas keliuose stenduose, naudojant Jenkins, kad būtų patikrintas išleidimo teisingumas, automatinis ir rankinis testavimas:
Ivanas apibūdino, iš kokių sistemų, kokią informaciją galima paimti skaičiuojant laiką prie stendų:
- Iš Nexus – paskirstymo sukūrimo laikas ir aplanko, kuriame buvo komandos kodas, pavadinimas
- Iš Jenkins – kiekvieno darbo pradžios laikas, trukmė ir rezultatas, stendo pavadinimas (darbo parametruose), etapai (darbo žingsniai), nuoroda į platinimą Nexus.
- Ivanas nusprendė neįtraukti Jira ir BitBucket į planą, nes... jie buvo labiau susiję su kūrimo etapu, o ne su paruošto platinimo išriedėjimu ant stendų.
Remiantis turima informacija, buvo sudaryta tokia schema:
Žinodami, kiek laiko užtrunka paskirstymų kūrimas ir kiek laiko praleidžiama kiekvienam iš jų, galite lengvai apskaičiuoti bendras viso DevOps konvejerio (viso ciklo) išlaidas.
Štai „DevOps“ metrika, su kuria Ivanas baigėsi:
- Sukurtų paskirstymų skaičius
- Dalis paskirstymų, kurie „atėjo“ į stendą ir „praėjo“ stendą
- Laikas, praleistas stove (stovo ciklas)
- Visas ciklas (bendras laikas visiems stendams)
- Darbo trukmė
- Prastovos tarp stovų
- Prastovos tarp darbų paleidimo tame pačiame stende
Viena vertus, metrikos labai gerai apibūdino „DevOps“ dujotiekį laiko atžvilgiu, kita vertus, jie buvo laikomi labai paprastais.
Patenkintas gerai atliktu darbu, Ivanas padarė pristatymą ir nuėjo pristatyti vadovybei.
Jis grįžo niūrus ir nuleidęs rankas.
„Tai yra fiasko, brolau“, – ironiškas kolega nusišypsojo...
Daugiau skaitykite straipsnyje "".
Šaltinis: www.habr.com