Iskreno govoreći, Ivan se često smijao uzaludnim naporima svojih kolega iz odjeljenja za praćenje. Uložili su velike napore da implementiraju metrike koje im je menadžment kompanije naredio da postignu. Bili su toliko zauzeti da nisu htjeli da bilo ko drugi radi bilo šta.
Ali menadžmentu to nije bilo dovoljno - stalno su naručivali sve više i više novih metrika, vrlo brzo prestajući koristiti ono što je ranije urađeno.
U posljednje vrijeme svi pričaju o LeadTime-u - vremenu za isporuku poslovnih funkcija. metrika je pokazala ludu brojku - 200 dana za isporuku jednog zadatka. Kako su svi urlali i aah i digli ruke ka nebu!
Nakon nekog vremena, buka je postupno utihnula i uprava je dobila nalog da kreira još jednu metriku.
Ivanu je bilo potpuno jasno da će nova metrika jednako tiho umrijeti u mračnom kutu.
Zaista, pomisli Ivan, poznavanje broja nikome ništa ne govori. 200 dana ili 2 dana - nema razlike, jer je po broju nemoguće utvrditi razlog i shvatiti da li je dobar ili loš.
Ovo je tipična zamka metrike: čini se da će nova metrika reći suštinu postojanja i objasniti neku tajnu tajnu. Svi se tome mnogo nadaju, ali iz nekog razloga se ništa ne dešava. Da, jer tajnu ne treba tražiti u metrici!
Za Ivana je ovo bila prošla faza. On je to razumeo za mjerenja, a sve tajne se moraju potražiti , tj. je da je ova metrika formirana.
Za online prodavnicu, predmet uticaja će biti njeni klijenti koji donose novac, a za DevOps timovi koji kreiraju i razvijaju distribucije koristeći pipeline.
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 predmet utjecaja timovi.
Svrha DevOps metrika
Jasno je da svi žele skratiti vrijeme isporuke. 200 dana, naravno, nije dobro.
Ali kako, to je pitanje?
Kompanija zapošljava stotine timova, a hiljade distribucija svakodnevno prolaze kroz DevOps cevovod. Stvarno vrijeme isporuke će se pojaviti kao distribucija. Svaki tim će imati svoje vrijeme i svoje karakteristike. Kako možeš pronaći nešto u ovom neredu?
Odgovor je nastao prirodno – moramo pronaći problematične timove i shvatiti šta se s njima događa i zašto to traje toliko dugo, te naučiti od „dobrih“ timova kako sve brzo uraditi. A da biste to učinili, morate izmjeriti vrijeme provedeno od strane timova na svakom od DevOps štandova:
“Svrha sistema će biti odabir timova na osnovu vremena prolaska tribina, tj. Kao rezultat, trebali bismo dobiti listu naredbi sa odabranim vremenom, a ne brojem.
Ako saznamo koliko je ukupno vremena provedeno na tribini, a koliko vremena je utrošeno na zastoje između tribina, možemo pronaći ekipe, pozvati ih i detaljnije razumjeti razloge i eliminirati ih”, smatra Ivan.
Kako izračunati vrijeme isporuke za DevOps
Da bi se to izračunalo, bilo je potrebno uroniti u DevOps proces i njegovu suštinu.
Kompanija koristi ograničen broj sistema, a informacije se mogu dobiti samo od njih i nigdje drugdje.
Svi poslovi u kompaniji su registrovani u Jira. Kada je zadatak preuzet, kreirana je grana za njega, a nakon implementacije izvršeno je urezivanje na BitBucket i Pull Request. Kada je PR (Pull Request) prihvaćen, distribucija je automatski kreirana i pohranjena u Nexus spremištu.
Dalje, distribucija je puštena na nekoliko štandova koristeći Jenkins za provjeru ispravnosti uvođenja, automatskog i ručnog testiranja:
Ivan je opisao iz kojih sistema koje se informacije mogu uzeti za izračunavanje vremena na štandovima:
- Iz Nexusa – vrijeme kreiranja distribucije i naziv foldera koji je sadržavao komandni kod
- Od Jenkinsa – vrijeme početka, trajanje i rezultat svakog posla, naziv štanda (u parametrima posla), faze (koraci posla), veza do distribucije u Nexusu.
- Ivan je odlučio da ne uključi Jira i BitBucket u proces, jer... više su se odnosile na fazu razvoja, a ne na izvlačenje gotove distribucije na štandovima.
Na osnovu dostupnih informacija, nacrtan je sljedeći dijagram:
Znajući koliko je vremena potrebno za kreiranje distribucija i koliko vremena je utrošeno na svaku od njih, možete lako izračunati ukupne troškove prolaska kroz cijeli DevOps cjevovod (pun ciklus).
Ovo su DevOps metrike koje je Ivan završio:
- Broj kreiranih distribucija
- Udio distribucija koje su “došle” na štand i “prošle” štand
- Vrijeme provedeno na postolju (ciklus stajanja)
- Puni ciklus (ukupno vrijeme za sve tribine)
- Trajanje posla
- Zastoji između tribina
- Zastoji između pokretanja poslova na istom postolju
S jedne strane, metrike su vrlo dobro karakterizirale DevOps cevovod u smislu vremena, s druge strane, smatrale su se vrlo jednostavnim.
Zadovoljan dobro obavljenim poslom, Ivan je napravio prezentaciju i otišao da je predstavi menadžmentu.
Vratio se smrknut i spuštenih ruku.
"Ovo je fijasko, brate", osmehnuo se ironični kolega...
Više pročitajte u članku “".
izvor: www.habr.com