(Time-To-Market).
Isegi nädalavahetustel mõtles ta mõõdikutele: „Mis siis, kui ma mõõdan aega? Mida see mulle annab?
Tõepoolest, mida annab aja tundmine? Oletame, et kohaletoimetamine võtab aega 5 päeva. Mis saab edasi? Kas see on hea või halb? Isegi kui see on halb, peate seda aega kuidagi vähendama. Aga kuidas?
Need mõtted kummitasid teda, kuid lahendust ei tulnud.
Ivan sai aru, et oli jõudnud olemuseni. Lugematud mõõdikute graafikud, mida ta oli varem näinud, olid teda juba ammu veennud, et standardne lähenemine ei tööta ja et kui ta lihtsalt joonistaks (), pole sellest kasu.
Kuidas olla?…
Mõõdik on nagu tavaline puidust joonlaud. Selle abil tehtud mõõtmised ei näita põhjust, miks mõõdetav objekt on täpselt selle pikkusega, mida ta näitas. Joonlaud näitab lihtsalt oma suurust ja ei midagi enamat. Ta pole filosoofi kivi, vaid lihtsalt puidust tahvel, millega mõõta.
Tema lemmikkirjaniku Harry Harrisoni "roostevabast terasest rott" ütles alati: mõte peab jõudma aju põhja ja seal lebama, nii et pärast mitu päeva tulutult kannatamist otsustas Ivan võtta uue ülesande...
Paar päeva hiljem sai Ivan veebipoode käsitlevat artiklit lugedes ühtäkki aru, et veebipoodi laekuva rahasumma oleneb saidi külastajate käitumisest. Just nemad, külastajad/kliendid, annavad poele oma raha ja on selle allikas. Kaupluses saadava sularaha suurust mõjutavad muutused klientide käitumises, mitte miski muu.
Selgus, et mõõdetud väärtuse muutmiseks oli vaja mõjutada neid, kes selle väärtuse moodustavad, s.o. veebipoe rahasumma muutmiseks oli vaja mõjutada selle poe klientide käitumist ning DevOpsis tarneaja muutmiseks oli vaja mõjutada meeskondi, kes seekord “loovad”, s.t. kasutavad oma töös DevOpsi.
Ivan mõistis, et DevOpsi mõõdikuid ei tohiks üldse graafikutega esitada. Nad peavad ennast esindama otsingutööriist "Silmapaistvad" meeskonnad, kes kujundavad lõpliku tarneaja.
Ükski mõõdik ei näita kunagi põhjust, miks sellel või teisel meeskonnal distributsiooni kohaletoimetamine kaua aega võttis, arvas Ivan, sest tegelikkuses võib olla miljon ja väike käru ning need võivad olla mitte tehnilised, vaid organisatsioonilised. Need. kõige rohkem võid mõõdikutest oodata, et näitad meeskondi ja nende tulemusi ja siis pead ikka nendel tiimidel jalgadega järge ajama ja uurima, mis neil viga on.
Teisest küljest oli Ivani ettevõttel standard, mis nõudis, et kõik meeskonnad katsetaksid komplekte mitmel pingil. Meeskond ei saanud järgmisele tribüünile liikuda enne, kui eelmine oli valmis. Selgus, et kui kujutada DevOps protsessi ette tribüünide läbimise jadana, siis mõõdikud võiksid näidata meeskondade nendel tribüünidel veedetud aega. Teades meeskonna seisukohta ja aega, oli võimalik nendega täpsemalt rääkida põhjustest.
Ivan võttis kõhklemata toru ja valis inimese numbri, kes on DevOpsi läbi ja lõhki hästi kursis:
— Denis, palun öelge, kas on võimalik kuidagi aru saada, et meeskond on sellest või teisest tribüünist mööda saanud?
- Kindlasti. Meie Jenkins loobub lipust, kui konstruktsioon on pingil edukalt veeretatud (testi läbinud).
- Super. Mis on lipp?
- See on tavaline tekstifail, nagu "stand_OK" või "stand_FAIL", mis ütleb, et koost läbis testi või ebaõnnestus. Noh, saate aru, eks?
- Ma arvan, jah. Kas see on kirjutatud hoidlas samasse kausta, kus koost asub?
- Jah
— Mis juhtub, kui koost ei läbi katsestendi? Kas ma pean uue ehituse tegema?
- Jah
- Noh, okei, tänan. Ja veel küsimus: kas ma saan õigesti aru, et saan stendi kuupäevana kasutada lipu loomise kuupäeva?
- Absoluutselt!
- Super!
Inspireerituna pani Ivan toru maha ja mõistis, et kõik on paika loksunud. Teades ehitusfaili loomise kuupäeva ja lippude loomise kuupäeva, oli võimalik kuni sekundini välja arvutada, kui palju aega meeskonnad igal stendil veedavad ja aru saada, kus nad kõige rohkem aega veedavad.
"Mõistades, kus kõige rohkem aega veedetakse, määrame meeskonnad kindlaks, läheme nende juurde ja süveneme probleemisse." Ivan naeratas.
Homseks seadis ta endale ülesandeks visandada joonistatava süsteemi arhitektuur.
Jätkub ...
Allikas: www.habr.com