Iskreno govoreći, Ivan se često smijao uzaludnom trudu svojih kolega iz odjela monitoringa. Uložili su velike napore kako bi implementirali metriku koju im je menadžment tvrtke naredio. Bili su toliko zaposleni da nisu htjeli da itko drugi išta radi.
Ali upravi to nije bilo dovoljno - stalno su naručivali sve više i više novih metrika, vrlo brzo prestajući koristiti ono što je prethodno učinjeno.
U posljednje vrijeme svi pričaju o LeadTime-u - vremenu isporuke poslovnih značajki. Mjerilo je pokazalo ludu brojku - 200 dana za isporuku jednog zadatka. Kako su svi oahli i aahali i podigli ruke prema nebu!
Nakon nekog vremena, buka je postupno zamrla i uprava je dobila naredbu za stvaranje druge metrike.
Ivanu je bilo potpuno jasno da će nova metrika jednako tiho umrijeti u mračnom kutu.
Doista, pomislio je Ivan, saznanje o broju nikome ne govori baš ništa. 200 dana ili 2 dana - nema razlike, jer je nemoguće odrediti razlog po broju i razumjeti je li to dobro ili loše.
Ovo je tipična zamka metrike: čini se da će nova metrika ispričati bit postojanja i objasniti neku tajnu tajnu. Svi se tome toliko nadaju, ali iz nekog razloga ništa se ne događa. Da, jer tajnu ne treba tražiti u metrici!
Za Ivana je to bila prijeđena faza. On je to razumio za mjerenja, a sve tajne treba tražiti u , tj. je da je ova metrika formirana.
Za internetsku trgovinu objekt utjecaja bit će njezini klijenti koji donose novac, a za DevOps to će biti timovi koji stvaraju i uvode distribucije pomoću cjevovoda.
Jednog dana, sjedeći u udobnoj stolici u hodniku, Ivan je odlučio pažljivo razmisliti kako želi vidjeti DevOps metriku, uzimajući u obzir činjenicu da su objekt utjecaja timovi.
Svrha DevOps metrike
Jasno je da svi žele smanjiti vrijeme isporuke. 200 dana, naravno, nije dobro.
Ali kako, to je pitanje?
Tvrtka zapošljava stotine timova, a tisuće distribucija svaki dan prolaze kroz DevOps cjevovod. Stvarno vrijeme isporuke pojavit će se kao distribucija. Svaki tim će imati svoje vrijeme i svoje karakteristike. Kako možeš išta pronaći u ovom neredu?
Odgovor se nameće sam od sebe - moramo pronaći problematične timove i shvatiti što se s njima događa i zašto to tako dugo traje, te naučiti od "dobrih" timova kako sve učiniti brzo. A da biste to učinili, morate izmjeriti vrijeme provedeno od strane timova na svakom od DevOps štandova:
“Svrha sustava bit će odabir momčadi na temelju vremena prolaska pored tribina, tj. Kao rezultat, trebali bismo dobiti popis naredbi s odabranim vremenom, a ne brojem.
Ako saznamo koliko je ukupno vremena bilo na tribini i koliko je vremena bilo u pauzama između tribina, možemo pronaći timove, pozvati ih i detaljnije sagledati razloge i otkloniti ih”, smatra Ivan.
Kako izračunati vrijeme isporuke za DevOps
Da bismo ga izračunali, bilo je potrebno proniknuti u DevOps proces i njegovu bit.
Tvrtka koristi ograničeni broj sustava, te se informacije mogu dobiti samo od njih i nigdje drugdje.
Svi zadaci u tvrtki registrirani su u Jiri. Kada je zadatak preuzet, za njega je stvorena grana, a nakon implementacije izvršena je obveza na BitBucket i Pull Request. Kada je PR (Pull Request) prihvaćen, distribucija je automatski kreirana i pohranjena u repozitorij Nexusa.
Zatim je distribucija pokrenuta na nekoliko postolja pomoću Jenkinsa za provjeru ispravnosti uvođenja, automatskog i ručnog testiranja:
Ivan je opisao iz kojih se sustava koje informacije mogu uzeti za izračun vremena na tribinama:
- Iz Nexusa – Vrijeme stvaranja distribucije i naziv mape koja je sadržavala kod naredbe
- Od Jenkinsa – Vrijeme početka, trajanje i rezultat svakog posla, naziv postolja (u parametrima posla), faze (koraci posla), poveznica na distribuciju u Nexusu.
- Ivan je odlučio ne uključiti Jira i BitBucket u plan jer... više su se odnosile na fazu razvoja, a ne na izbacivanje gotove distribucije na postolje.
Na temelju dostupnih informacija nacrtan je sljedeći dijagram:
Znajući koliko je vremena potrebno za izradu distribucija i koliko se vremena troši na svaku od njih, lako možete izračunati ukupne troškove prolaska kroz cijeli DevOps cjevovod (puni ciklus).
Ovo su DevOps metrike koje je Ivan završio:
- Broj stvorenih distribucija
- Udio distribucija koje su “došle” na štand i “prošle” štand
- Vrijeme provedeno na postolju (ciklus postolja)
- Puni ciklus (ukupno vrijeme za sve postolje)
- Trajanje posla
- Zastoji između tribina
- Zastoji između pokretanja poslova na istom postolju
S jedne strane, metrika je vrlo dobro karakterizirala DevOps cjevovod u smislu vremena, s druge strane, smatrana je vrlo jednostavnom.
Zadovoljan dobro obavljenim poslom, Ivan je napravio prezentaciju i otišao je prezentirati upravi.
Vratio se smrknut i spuštenih ruku.
“Ovo je fijasko, brate”, nasmiješio se ironični kolega...
Pročitajte više u članku “".
Izvor: www.habr.com