🥇Metrike DevOps – od kod pridobiti podatke za izračune

Iskreno rečeno, Ivan se često smejao neuspelim naporima kolega iz odeljenja za monitoring. Uložili su ogromne napore u realizaciju metrika koje su im nalagala uprava kompanije. Bili su toliko zauzeti da nikome drugom nisu želeli ništa da rade.

A upravi nikada nije bilo dovoljno – stalno je naručivala nove i nove metrike, vrlo brzo prestajući da koristi one koje su ranije napravljene.

Poslednjih dana svi su samo govorili o LeadTime-u – vremenu isporuke poslovnih funkcionalnosti. Metрика je pokazala neverovatnu brojku – 200 dana za isporuku jednog zadatka. Kako su svi jaukali, uzdisali i podizali ruke ka nebu!

Nakon nekog vremena, buka je postupno tiho utihnula, a uprava je poslala zahtev za izradu još jedne metrike.

Ivanu je bilo potpuno jasno da će i nova metrika tiho umreti u mračnom uglu.

Zaista, razmišljao je Ivan, poznavanje broja nikome ne govori ništa. 200 dana ili 2 dana – nema nikakve razlike, jer se po broju ne može odrediti uzrok i shvatiti da li je to dobro ili loše.

To je tipična zamka metrika: čini se da će nova metrika otkriti suštinu postojanja i objasniti neki tajni ključ. Svi se nadaju tome, ali iz nekog razloga ništa se ne dešava. Zato što treba tražiti tajnu sasvim van metrika!

Za Ivana, to je bila prošlost. Razumio je da metrike – to je samo obična drvena lenjirka za merenja, a sve tajne treba tražiti u objektu uticaja, tj. u onome što formira tu metriku.

Za internet prodavnicu, objekat uticaja će biti njeni kupci, koji donose novac, a za DevOps – timovi koji kreiraju i raspoređuju distribucije koristeći pipeline.

Jednom, smešten u udobnom stolicu u holu, Ivan je odlučio dobro razmisliti o tome kako bi želeo da vidi DevOps metrike uzimajući u obzir da su objekti uticaja timovi.

Cilj DevOps metrika

Jasno je da svi žele smanjiti vreme isporuke. 200 dana – to jednostavno ne može proći.

Ali kako, tu je pitanje?

U kompaniji radi stotine timova, a kroz DevOps pipeline prolazi hiljade distribucija dnevno. Stvarno vreme isporuke će izgledati kao raspodela. Svaki tim će imati svoje vreme i svoje posebnosti. Kako iz ove gužve pronaći išta?

Odgovor se pojavio sam od sebe – potrebno je pronaći problematične timove i otkriti šta se dešava s njima i zašto im je potrebno toliko vremena, a od "dobrih" timova naučiti kako sve raditi brzo. A za to je potrebno izmeriti vreme koje timovi provode na svakoj DevOps stanici:

"Cilj sistema je odabir timova prema vremenu prolaska stanica, tj. na kraju trebamo dobiti listu timova sa izabranim vremenom, a ne broj.

Ako saznamo koliko je ukupno vremena potrošeno na stanicu i koliko vremena je potrošeno na zastoje između stanica, moći ćemo pronaći timove, nazvati ih i detaljnije istražiti uzroke i eliminisati ih", pomislio je Ivan.

Kako izračunati vreme isporuke za DevOps

Za izračunavanje je bilo potrebno dublje istražiti proces DevOps i njegove entitete.

U kompaniji se koristi ograničen broj sistema, a informacije se mogu dobiti samo iz njih i niotkuda više.

Sve zadaće u kompaniji registrovane su u Jiri. Kada se zadaća preuzme u rad, za nju se kreira branch, a nakon implementacije vrši se commit u BitBucket i Pull Request. Pri prihvatanju PR-a (Pull Request) automatski se kreira distribucija i čuva u skladištu Nexus.

Nakon toga, distribucija se raspoređuje na nekoliko stanica putem Jenkins-a radi provere ispravnosti implementacije, automatskog i ručnog testiranja:

Ivan je naveo iz kojih sistema koju informaciju možemo uzeti kako bismo izračunali vreme na stanicama:

Iz Nexusa – vreme kreiranja distribucije i naziv fascikle u kojoj se nalazio kod tima.
Iz Jenkins-a – vreme početka, trajanje i rezultat svake posla, naziv stanice (u parametrima posla), stejdži (koraci posla), link na distribuciju u Nexusu.
Ivan je odlučio da Jiru i BitBucket ne uključuje u proces, jer su se više odnosili na fazu razvoja, a ne na raspodelu gotove distribucije po stanicama.

Na osnovu dostupnih informacija nacrtana je takva shema:

Znajući koliko vremena se troši na kreiranje distribucija i koliko vremena se troši na svaku od njih, može se lako izračunati ukupni trošak za prolazak kroz ceo DevOps proces (potpuni ciklus).