{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps metrike - kje pridobiti podatke za izra\u010dune","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Iskreno re\u010deno, Ivan se \u010desto smejao neuspelim naporima kolega iz odeljenja za monitoring. Ulo\u017eili su ogromne napore u realizaciju metrika koje su im nalagala uprava kompanije. Bili su toliko zauzeti da nikome drugom nisu \u017eeleli ni\u0161ta da rade. <\/p>\n

A upravi nikada nije bilo dovoljno \u2013 stalno je naru\u010divala nove i nove metrike, vrlo brzo prestaju\u0107i da koristi one koje su ranije napravljene.<\/p>\n

Poslednjih dana svi su samo govorili o LeadTime-u \u2013 vremenu isporuke poslovnih funkcionalnosti. Met\u0440\u0438\u043a\u0430 je pokazala neverovatnu brojku \u2013 200 dana za isporuku jednog zadatka. Kako su svi jaukali, uzdisali i podizali ruke ka nebu!<\/p>\n

Nakon nekog vremena, buka je postupno tiho utihnula, a uprava je poslala zahtev za izradu jo\u0161 jedne metrike.<\/p>\n

Ivanu je bilo potpuno jasno da \u0107e i nova metrika tiho umreti u mra\u010dnom uglu.<\/p>\n

Zaista, razmi\u0161ljao je Ivan, poznavanje broja nikome ne govori ni\u0161ta. 200 dana ili 2 dana \u2013 nema nikakve razlike, jer se po broju ne mo\u017ee odrediti uzrok i shvatiti da li je to dobro ili lo\u0161e.<\/p>\n

To je tipi\u010dna zamka metrika: \u010dini se da \u0107e nova metrika otkriti su\u0161tinu postojanja i objasniti neki tajni klju\u010d. Svi se nadaju tome, ali iz nekog razloga ni\u0161ta se ne de\u0161ava. Zato \u0161to treba tra\u017eiti tajnu sasvim van metrika!<\/p>\n

Za Ivana, to je bila pro\u0161lost. Razumio je da metrike \u2013 to je samo obi\u010dna drvena lenjirka<\/a><\/noindex> za merenja, a sve tajne treba tra\u017eiti u objektu uticaja<\/a><\/noindex>, tj. u onome \u0161to formira tu metriku.<\/p>\n

Za internet prodavnicu, objekat uticaja \u0107e biti njeni kupci, koji donose novac, a za DevOps \u2013 timovi koji kreiraju i raspore\u0111uju distribucije koriste\u0107i pipeline.<\/p>\n

Jednom, sme\u0161ten u udobnom stolicu u holu, Ivan je odlu\u010dio dobro razmisliti o tome kako bi \u017eeleo da vidi DevOps metrike uzimaju\u0107i u obzir da su objekti uticaja timovi.<\/p>\n

Cilj DevOps metrika<\/h2>\n

\nJasno je da svi \u017eele smanjiti vreme isporuke. 200 dana \u2013 to jednostavno ne mo\u017ee pro\u0107i. <\/p>\n

Ali kako, tu je pitanje?<\/a><\/noindex><\/p>\n

U kompaniji radi stotine timova, a kroz DevOps pipeline prolazi hiljade distribucija dnevno. Stvarno vreme isporuke \u0107e izgledati kao raspodela. Svaki tim \u0107e imati svoje vreme i svoje posebnosti. Kako iz ove gu\u017eve prona\u0107i i\u0161ta?<\/p>\n

Odgovor se pojavio sam od sebe \u2013 potrebno je prona\u0107i problemati\u010dne timove i otkriti \u0161ta se de\u0161ava s njima i za\u0161to im je potrebno toliko vremena, a od \"dobrih\" timova nau\u010diti kako sve raditi brzo. A za to je potrebno izmeriti vreme koje timovi provode na svakoj DevOps stanici:<\/p>\n

\"DevOps
\n
\n\"Cilj sistema je odabir timova prema vremenu prolaska stanica, tj. na kraju trebamo dobiti listu timova sa izabranim vremenom, a ne broj.<\/p>\n

Ako saznamo koliko je ukupno vremena potro\u0161eno na stanicu i koliko vremena je potro\u0161eno na zastoje izme\u0111u stanica, mo\u0107i \u0107emo prona\u0107i timove, nazvati ih i detaljnije istra\u017eiti uzroke i eliminisati ih\", pomislio je Ivan.<\/p>\n

\"DevOps
\n <\/p>\n

Kako izra\u010dunati vreme isporuke za DevOps<\/h2>\n

Za izra\u010dunavanje je bilo potrebno dublje istra\u017eiti proces DevOps i njegove entitete.<\/p>\n

U kompaniji se koristi ograni\u010den broj sistema, a informacije se mogu dobiti samo iz njih i niotkuda vi\u0161e.<\/p>\n

Sve zada\u0107e u kompaniji registrovane su u Jiri. Kada se zada\u0107a preuzme u rad, za nju se kreira branch, a nakon implementacije vr\u0161i se commit u BitBucket i Pull Request. Pri prihvatanju PR-a (Pull Request) automatski se kreira distribucija i \u010duva u skladi\u0161tu Nexus. <\/p>\n

\"DevOps
\n
\nNakon toga, distribucija se raspore\u0111uje na nekoliko stanica putem Jenkins-a radi provere ispravnosti implementacije, automatskog i ru\u010dnog testiranja:<\/p>\n

\"DevOps
\n
\nIvan je naveo iz kojih sistema koju informaciju mo\u017eemo uzeti kako bismo izra\u010dunali vreme na stanicama:<\/p>\n