Verdire, Ivano ofte ridis pri la vanaj klopodoj de siaj kolegoj el la monitora fako. Ili faris grandajn klopodojn por efektivigi la metrikojn kiujn la administrado de la firmao ordonis al ili atingi. Ili estis tiel okupataj, ke ili ne volis, ke iu alia faru ion ajn.
Sed ne sufiĉis por la administrado - ili konstante mendis pli kaj pli da novaj metrikoj, tre rapide ĉesante uzi tion, kio estis farita antaŭe.
Lastatempe ĉiuj parolis pri LeadTime - la tempo por livero de komercaj funkcioj. La metriko montris frenezan nombron - 200 tagoj por liveri unu taskon. Kiel ĉiuj aŭdadis kaj ahekis kaj levis la manojn al la ĉielo!
Post iom da tempo, la bruo iom post iom malpliiĝis kaj administrado ricevis ordon krei alian metrikon.
Al Ivan estis tute klare, ke la nova metriko same trankvile mortos en malhela angulo.
Efektive, pensis Ivano, sciante la numeron nenion diras al iu ajn. 200 tagoj aŭ 2 tagoj - ne estas diferenco, ĉar estas neeble determini la kialon per la nombro kaj kompreni ĉu ĝi estas bona aŭ malbona.
Ĉi tio estas tipa kaptilo de metriko: ŝajnas, ke nova metriko rakontos la esencon de ekzisto kaj klarigos iun sekretan sekreton. Ĉiuj esperas tiom pri tio, sed ial nenio okazas. Jes, ĉar la sekreto ne troveblas en metriko!
Por Ivan, ĉi tio estis pasinta etapo. Li komprenis tion por mezuradoj, kaj ĉiuj sekretoj devas esti serĉataj , t.e. estas ke ĉi tiu metriko estas formita.
Por interreta vendejo, la celo de influo estos ĝiaj klientoj, kiuj alportas monon, kaj por DevOps, estos la teamoj, kiuj kreas kaj disvolvas distribuojn per dukto.
Iun tagon, sidiĝante en komforta seĝo en la halo, Ivan decidis zorge pripensi kiel li volis vidi DevOps-metrikojn, konsiderante la fakton, ke la celo de influo estas teamoj.
Celo de DevOps-Metrikoj
Estas klare, ke ĉiuj volas redukti livertempon. 200 tagoj estas, kompreneble, ne bona.
Sed kiel, tio estas la demando?
La kompanio dungas centojn da teamoj, kaj miloj da distribuoj trairas la dukton DevOps ĉiutage. La reala livertempo aperos kiel distribuo. Ĉiu teamo havos sian propran tempon kaj siajn proprajn karakterizaĵojn. Kiel vi povas trovi ion inter ĉi tiu malordo?
La respondo aperis nature - ni devas trovi la problemajn teamojn kaj ekscii, kio okazas kun ili kaj kial tio daŭras tiel longe, kaj lerni de la "bonaj" teamoj kiel fari ĉion rapide. Kaj por fari tion, vi devas mezuri la tempon pasigitan de teamoj ĉe ĉiu el la DevOps-standoj:
"La celo de la sistemo estos elekti teamojn surbaze de la tempo kiam ili preterpasas la standojn, t.e. Kiel rezulto, ni devus ricevi liston de komandoj kun la elektita tempo, kaj ne nombro.
Se ni ekscios kiom da tempo estis pasigita sur la stando entute kaj kiom da tempo estis pasigita por malfunkcio inter standoj, ni povas trovi la teamojn, voki ilin kaj kompreni la kialojn pli detale kaj forigi ilin,” pensis Ivano.
Kiel Kalkuli Livertempon por DevOps
Por kalkuli ĝin, necesis enprofundiĝi en la procezon DevOps kaj ĝian esencon.
La firmao uzas limigitan nombron da sistemoj, kaj informoj nur povas esti akiritaj de ili kaj nenie aliloke.
Ĉiuj taskoj en la firmao estis registritaj en Jira. Kiam tasko estis prenita, branĉo estis kreita por ĝi, kaj post efektivigo, kompromiso estis farita al BitBucket kaj Pull Request. Kiam PR (Pull Request) estis akceptita, distribuo estis aŭtomate kreita kaj stokita en la Nexus-deponejo.
Poste, la distribuo estis disvastigita sur pluraj standoj uzante Jenkins por kontroli la ĝustecon de la lanĉo, aŭtomata kaj mana testado:
Ivan priskribis el kiuj sistemoj kiaj informoj povas esti prenitaj por kalkuli la tempon ĉe la standoj:
- De Nexus - Disdona krea tempo kaj nomo de la dosierujo, kiu enhavis la komandan kodon
- De Jenkins - Komenca tempo, daŭro kaj rezulto de ĉiu laboro, standnomo (en la laborparametroj), etapoj (laborpaŝoj), ligo al la distribuo en Nexus.
- Ivan decidis ne inkludi Jira kaj BitBucket en la dukto, ĉar... ili estis pli rilataj al la evolufazo, kaj ne al disvolvado de la preta distribuo sur standoj.
Surbaze de la disponeblaj informoj, la sekva diagramo estis desegnita:
Sciante kiom da tempo necesas por krei distribuojn kaj kiom da tempo estas pasigita por ĉiu el ili, vi povas facile kalkuli la totalajn kostojn trairi la tutan DevOps-dukton (plena ciklo).
Jen la DevOps-metrikoj kun kiuj Ivan finis:
- Nombro de distribuoj kreitaj
- Parto de distribuoj kiuj "venis" al la stando kaj "pasis" la standon
- Tempo pasigita sur la stando (standciklo)
- Plena ciklo (tuta tempo por ĉiuj standoj)
- Labordaŭro
- Malfunkcio inter standoj
- Malfunkcio inter laborlanĉoj sur la sama stando
Unuflanke, la metrikoj karakterizis la DevOps-dukton tre bone laŭ tempo, aliflanke, ili estis konsideritaj tre simplaj.
Kontenta pri la bone farita laboro, Ivan faris prezenton kaj iris prezenti ĝin al la administrado.
Li revenis morna kaj kun la manoj malsupren.
"Ĉi tio estas fiasko, frato," la ironia kolego ridetis...
Legu pli en la artikolo "".
fonto: www.habr.com