Kako je Ivan radio DevOps metrike. Objekt utjecaja

Prošao je tjedan otkako je Ivan prvi put razmišljao o DevOps metrikama i shvatio da s njima mora upravljati vremenom isporuke proizvoda. (Time-To-Market).

Čak je i tijekom vikenda razmišljao o metrikama: "Pa što, što ću mjeriti vrijeme? Što će mi to donijeti?"

Doista, što donosi znanje o vremenu? Pretpostavimo da isporuka traje 5 dana. I što onda? Je li to dobro ili loše? Čak i ako je to loše, treba li nekako smanjiti to vrijeme? Ali kako?
Ove misli nisu mu dale mira, ali rješenje nije dolazilo.

Ivan je shvaćao da je došao do same srži. Beskrajni grafikon metrika koje je dosad vidio davno su ga uvjerili da standardni pristup neće upaliti i da, ako samo izgradi grafikon (čak i kohortni), neće biti nikakve koristi.

Što učiniti?…

Metrika je poput obične drvene ravnala. Mjerenja napravljena njome ne govore razlog, zašto mjerenog predmeta točno te dužine koju je pokazala. Ravnalo samo pokazuje njegovu veličinu, i ništa više. Nije filozofski kamen, već samo drvena daska kojom se mjeri.

"Nehrđajući čelik" omiljenog pisca Garryja Harrisona uvijek je govorio: misao mora stići do dna mozga i tamo se odmarati, stoga je, nakon nekoliko dana bezuspješnog mučenja, Ivan odlučio preći na drugi zadatak...

Nakon nekoliko dana, dok je čitao članak o internetskim trgovinama, Ivan je iznenada shvatio da iznos novca koji internet trgovina dobiva ovisi o ponašanju posjetitelja web stranice. Upravo oni, posjetitelji/klijenti, predaju novac trgovini i predstavljaju njihov izvor. Na konačni iznos novčanih sredstava koje trgovina dobiva utječu promjene u ponašanju kupaca, a ne nešto drugo.

Ispostavilo se da je za promjenu mjere vrednovanja potrebno utjecati na one koji formiraju tu vrijednost, tj. za promjenu količine novca internet trgovine treba utjecati na ponašanje klijenata te trgovine, a za promjenu vremena isporuke u DevOps-u potrebno je utjecati na timove koji to vrijeme "stvaraju", tj. koji koriste DevOps u svom radu.

Ivan je shvatio da metrikama DevOps-a ne bi trebali predstavljati samo grafikoni. Trebali bi predstavljati alat za pronalaženje "izvrsnih" timova koji oblikuju konačno vrijeme isporuke.

Nema nikakvih metrika koje bi ikada mogle pokazati razlog zašto je određeni tim dugo isporučivao distribuciju, mislio je Ivan, jer u stvarnosti može biti milijun i jedan razlog, a mnogi od njih mogu biti ne tehnički, već organizacijski. Odnosno, maksimum što se može očekivati od metrika – to su prikazi timova i njihovih rezultata, a zatim će se morati ići osobno do tih timova i saznati šta ih muči.

S druge strane, u kompaniji Ivan je postojao standard koji je obavezivao sve timove da testiraju izgradnje na nekoliko okvira. Tim nije mogao preći na sljedeći okvir dok prethodni nije bio završen. Tako da, ako zamislimo DevOps proces kao niz prolaska kroz okvire, metrike bi mogle pokazivati vrijeme koje timovi troše na tim okvirima. Poznavajući okvir i vrijeme tima, moglo se konkretnije razgovarati s njima o uzrocima.

Nakon što je kratko razmišljao, Ivan je podigao slušalicu i nazvao osobu koja se dobro razumije u unutrašnjost DevOps-a:

— Denis, možeš li mi reći kako možemo saznati je li tim prošao određeni okvir?
— Naravno. Naš Jenkins postavlja zastavicu ako je izgradnja uspješno prošla (prošla testiranje) na okviru.
— Super. A što je zastavica?
— To je obična tekstualna datoteka poput "okvir_OK" ili "okvir_FAIL", koja govori da li je izgradnja prošla ili nije prošla okvir. Razumiješ?
— U principu da. Da li se to piše u istu mapu u skladištu gdje se nalazi izgradnja?
— Da.
— A što će se desiti ako izgradnja ne prođe okvir? Hoće li biti potrebno napraviti novu izgradnju?
— Aha.
— Dobro, hvala. I još jedno pitanje: ispravno razumijem da ću kao datum prolaska okvira moći koristiti datum kreiranja zastavice?
— Apsolutno!
— Super!

Ohrabren, Ivan je spustio slušalicu i shvatio da je sve na svom mestu. Znajući datum kreiranja datoteke izgradnje i datume kreiranja zastavica, mogao je do sekunde izračunati koliko vremena timovi troše na svaki okvir i shvatiti gde najviše gube vreme.

„Razumijevajući gdje se najviše gubi vreme, precizno ćemo pronaći timove, otići do njih i istražiti problem.“ Ivan se osmehnuo.

Za sutra je sebi postavio zadatak da skicira arhitekturu nadolazećeg sistema.

Nastavak slijedi…

Izvor: habr.com