Kuidas Ivan DevOps meetrikat tegi. Mõjuala objekt

Nädal on möödas sellest, kui Ivan esmakordselt mõtles DevOpsi mõõdikutele ja mõistis, et nende abil tuleb hallata toote tarnimise aega. (Aega turule).

Ieven mõtles isegi nädalavahetusel mõõdikute peale: „Mis sellest, et ma mõõdan aega? Mida see mulle annab?“

Tõepoolest, mida annab teadmine ajast? Oletame, et tarnimine kestab 5 päeva. Ja siis? Kas see on hea või halb? Isegi kui see on halb, tuleb seda aega ju kuidagi vähendada. Aga kuidas?
Need mõtted ei andnud talle rahu, kuid lahendus ei tulnud.

Ivan mõistis, et ta on lähenenud tuumale. Lõputud mõõdikute graafikud, mida ta varem näinud oli, olid juba ammu veennud teda, et standardne lähenemine ei tööta ja et kui lihtsalt joonistada graafik (olgu see siis rühmagraafik), ei ole sellest mingit tolku.

Kuidas edasi minna?…

Mõõdik on nagu tavaline puidust joonlaud. Tema abil tehtud mõõtmised ei ütle põhjuseid, miks mõõdetav objekt on täpselt sellise pikkusega, nagu ta näitas. Joonlaud lihtsalt näitab tema suurust, ei midagi enamat. See ei ole filosoofia kivi, vaid lihtsalt puidust tükk, millega mõõdetakse.

„Roostevabast terasest hiir“ tema lemmikautorilt Harry Harrison ütles alati: mõte peab jõudma ajus põhjani ja seal puhkama, seetõttu, pärast mõne päeva jõhkrat vaeva, otsustas Ivan teise ülesande kallale asuda…

Mõne päeva pärast, lugedes artiklit Interneti-poodide kohta, mõistis Ivan äkki, et summa raha, mida Interneti-pood teenib, sõltub sellest, kuidas käituvad veebisaidi külastajad. Just nemad, külastajad/kliendid, annavad poodidele oma raha ja on nende allikas. Lõpptulemuslikule rahasummale, mida pood teenib, mõjuvad kliendi käitumise muutused, mitte midagi muud.

Tundub, et mõõdetava suuruse muutmiseks pidi mõjutama neid, kes seda väärtust moodustavad, st Interneti-poe raha muutmiseks pidid nad mõjutama selle poe klientide käitumist, ning tarnimise aja muutmiseks DevOpsis pidid nad mõjutama meeskondi, kes seda aega „loovad“, st kasutavad DevOpsi oma töös.

Ivan mõistis, et DevOpsi mõõdikud ei peaks esindama absoluutselt mitte graafikuid. Need peaksid olema otsimise tööriist „silmapaistvate“ meeskondade leidmiseks, kes määravad lõpliku tarnimise aja.

Ükski mõõdik ei näita kunagi tegelikku põhjust, miks mõni meeskond pikka aega jaotust tarnis, mõtles Ivan, sest tegelikult võib põhjuseid olla miljard ja väike vanker ning need võivad olla täiesti mitte tehnilised, vaid organisatoorsed. See tähendab, et maksimum, mida mõõdikutelt oodata, on meeskondade ja nende tulemuste näitamine, kuid siis tuleb ikkagi nende juurde minna jalgadega ja uurida, mis nendega oli.

Teiselt poolt oli Ivani firmas olemas standard, mis kohustas kõiki meeskondi testima versioone mitmel stendis. Meeskond ei saanud minna järgmisele stendile, enne kui eelmine ei olnud läbitud. Tekkis olukord, kus kui kujutada DevOpsi protsessi stendide järjestikuse läbimise järjestusena, siis mõõdikud võiksid näidata aega, mida meeskonnad nendel stendidel kulutasid. Teades stendi ja meeskonna aega, võiks rääkida konkreetselt selle kohta, mis põhjustas viivitusi.

Mõtlemise peale võttis Ivan telefoni ja helistas inimesele, kes mõistis DevOpi siseelusid hästi:

— Denis, palun ütle, kas on võimalik kuidagi aru saada, et meeskond on läbinud selle või tolle stendi?
— Muidugi. Meie Jenkins loobib lipu, kui versioon on edukalt stendile rakendatud (läbinud kontrolli).
— Lahe. Ja mis on lipp?
— See on tavaline tekstifail, nagu „stend_OK” või „stend_FAIL”, mis ütleb, kas versioon läks stendi läbi või ei läinud. No, sa said aru, eks?
— Põhimõtteliselt jah. Kas see kirjutatakse sama kausta, kus versioon asub?
— Jah.
— Mis juhtub, kui versioon ei läbinud stendi? Kas tuleb teha uus versioon?
— Jah.
— No ok, aitäh. Ja veel küsimus: kas ma saan stendi läbimise kuupäevana kasutada lipu loomise kuupäeva?
— Absoluutselt!
— Lahe!

Inspireerituna pani Ivan toru ära ja mõistis, et kõik langes omale kohale. Teades versiooni loomise kuupäeva ja lipu loomise kuupäevi, sai täpselt sekundini arvutada, kui palju aega meeskonnad iga stendi peale kulutavad ja mõista, kus nad kõige rohkem aega kulutavad.

„Mõistes, kuhu kõige rohkem aega kulub, leiame sihikul olevad meeskonnad, läheme nende juurde ja uurime probleemi.“ Ivan naeratas.

Hommikuks seadis ta endale eesmärgi joonistada välja kavandatava süsteemi arhitektuur.

Jätkub…

Allikas: habr.com