Iskreno, Ivan se često smijao na uzaludne napore kolega iz odjela za nadzor. Ulagali su ogromne napore da ostvare metrike koje im je tražilo rukovodstvo kompanije. Bili su toliko zauzeti da više nikome ništa nisu htjeli raditi.
A rukovodstvu nikada nije bilo dosta – stalno je naručivalo nove i nove metrike, vrlo brzo prestajući koristiti one koje su već bile napravljene.
Posljednjih je dana svatko samo govorio o LeadTime-u – vremenu isporuke poslovnih značajki. Metrika je pokazala nevjerojatnu brojku – 200 dana za isporuku jednog zadatka. Kako su svi uzdisali, govorili i podizali ruke prema nebu!
Nakon nekog vremena buka je postupno utihnula i od rukovodstva je stigao zahtjev za izradu još jedne metrike.
Ivanu je bilo savršeno jasno da će i nova metrika tiho umrijeti u mračnom kutku.
Doista, razmišljao je Ivan, poznavanje broja ničemu nikome ne govori. 200 dana ili 2 dana – nema nikakve razlike, jer po broju nije moguće utvrditi uzrok i razumjeti je li to dobro ili loše.
Ovo je tipična zamka metrika: čini se da će nova metrika ispričati suštinu postojanja i objasniti neku tajnu. Svi se na to nadaju, ali ništa se iz nekog razloga ne događa. Zato što tajnu treba tražiti nimalo ne u metrikama!
Za Ivana je to bila prošlost. Razumio je da za mjerenje, a sve tajne treba tražiti u , tj. u onome što oblikuje tu metriku.
Za internetsku trgovinu objekt utjecaja bit će njezini kupci, koji donose novac, a za DevOps – timovi koji kreiraju i distribuiraju pakete koristeći cjevovod.
Jednog dana, smjestivši se udobno u fotelji u predvorju, Ivan je odlučio dobro razmisliti o tome kakve bi volio vidjeti DevOps metrike uzimajući u obzir da su objekt utjecaja timovi.
Cilj DevOps metrika
Jasno je da svi žele smanjiti vrijeme isporuke. 200 dana – to svakako nije prihvatljivo.
Ali kako, to je pitanje?
U kompaniji rade stotine timova, a kroz DevOps cjevovod prolaze tisuće paketa dnevno. Stvarno vrijeme isporuke izgledat će kao raspodjela. Svaki tim imat će svoje vlastito vrijeme i svoje vlastite osobitosti. Kako među tim neredima pronaći išta?
Odgovor se nametnuo sam od sebe – potrebno je pronaći problematične timove i razumjeti što se s njima događa i zašto im treba toliko dugo, a od "dobrih" timova naučiti kako sve raditi brzo. A za to je potrebno izmjeriti vrijeme koje su timovi proveli na svakom od DevOps okruženja:
„Cilj sustava će biti odabir timova prema vremenu prolaska okruženja, tj. na kraju trebamo dobiti popis timova s odabranim vremenom, a ne broj.
Ako saznamo koliko je vremena ukupno potrošeno na okruženje i koliko vremena je potrošeno na zastoje između okruženja, moći ćemo pronaći timove, nazvati ih i detaljnije razjasniti uzroke i ukloniti ih”, pomisli Ivan.
Kako izračunati vrijeme isporuke za DevOps
Za izračun bilo je potrebno produbiti se u proces DevOps-a i njegove entitete.
U tvrtki se koristi ograničen broj sustava, a informacije se mogu dobiti samo iz njih i nigdje drugdje.
Sve zadatke u tvrtki registrirali su u Jira. Kada bi zadatak bio preuzet u rad, za njega se stvarala grana, a nakon implementacije vršio bi se commit u BitBucket i Pull Request. Pri prihvaćanju PR (Pull Request) automatski se stvorio distribucijski paket i pohranio u Nexus.
Zatim se distribucijski paket implementirao na nekoliko okruženja putem Jenkinsa za provjeru ispravnosti implementacije, automatsko i ručno testiranje:
Ivan je opisao iz kojih sustava koju informaciju možemo uzeti kako bismo izračunali vrijeme na okruženjima:
- Iz Nexusa – Vrijeme stvaranja distribucijskog paketa i naziv mape u kojoj se nalazio kod tima
- Iz Jenkinsa – Vrijeme početka, trajanje i rezultat obrade svake job-e, naziv okruženja (u parametrima job-e), stage-ovi (koraci job-a), poveznica na distribucijski paket u Nexusu.
- Jira i BitBucket Ivan je odlučio ne uključivati u pipeline, jer su se više odnosili na fazu razvoja, a ne na prolazak gotovog distribucijskog paketa kroz okruženja.
Na temelju dostupnih informacija oblikovala se takva shema:
Znajući koliko vremena je potrebno za stvaranje distribucijskih paketa i koliko vremena se troši na svaki od njih, lako se može izračunati ukupni trošak za prolazak cijelog DevOps pipeline-a (cijeli ciklus).
Evo kakve su DevOps metrike tijekom došli do Ivana:
- Broj izrađenih distribucijskih paketa
- Postotak distribucijskih paketa koji su stigli na okruženje i prošli kroz okruženje
- Vrijeme provedeno na okruženju (ciklus okruženja)
- Ciklus (ukupno vrijeme za sve stanice)
- Trajanje poslova
- Zastoja između stanica
- Zastoja između pokretanja poslova na jednoj stanici
S jedne strane, metrički podaci su jako dobro opisivali DevOps proces u smislu vremena, a s druge strane, smatrali su se veoma jednostavnima.
Zadovoljan dobro obavljenim poslom, Ivan je pripremio prezentaciju i otišao je predstaviti je vodstvu.
Na povratku je izlazio ozbiljan i s spuštenim rukama.
— To je fijasko, brate — nasmiješeno je rekao ironični kolega...
Nastavak pročitajte u članku «».
Izvor: habr.com
