Szczerze mówiąc, Ivan często się śmiał z bezowocnych wysiłków kolegów z działu monitorowania. Zmieniali ogromne wysiłki, aby zrealizować metryki, które zlecało im kierownictwo firmy. Byli tak zajęci, że nie chcieli już nikomu nic więcej robić.
A kierownictwo ciągle było niezadowolone – stale zamawiało nowe metryki, bardzo szybko przestając korzystać z tych, które zostały wcześniej wykonane.
W ostatnim czasie wszyscy mówili tylko o LeadTime – czasie dostawy funkcji biznesowych. Metryka pokazała szokującą liczbę – 200 dni na dostarczenie jednego zadania. Jak wszyscy wzdychali, jęczeli i wznosili ręce do nieba!
Po pewnym czasie hałas stopniowo ucichł i z kierownictwa nadeszło zlecenie na stworzenie kolejnej metryki.
Ivan miał zupełnie jasne, że nowa metryka również cicho umrze w ciemnym kącie.
Rzeczywiście, myślał Ivan, znajomość liczby nic nikomu nie mówi. 200 dni czy 2 dni – nie ma żadnej różnicy, ponieważ z liczby nie można określić przyczyny i zrozumieć, czy to dobrze, czy źle.
To typowa pułapka metryk: wydaje się, że nowa metryka opowie o istocie istnienia i wyjaśni jakiś tajny sekret. Wszyscy na to liczą, ale nic się nie dzieje. A to dlatego, że sekret należy szukać w zupełnie innych miejscach niż metryki!
Dla Ivana to był już zamknięty rozdział. Rozumiał, że do pomiarów, a wszystkie sekrety należy szukać w , tzn. w tym, co tę metrykę formuje.
Dla sklepu internetowego obiektem wpływu będą jego klienci przynoszący pieniądze, a dla DevOps – zespoły tworzące i wdrażające dystrybucje z wykorzystaniem pipeline'u.
Pewnego dnia, siedząc w wygodnym fotelu w holu, Ivan postanowił dokładnie przemyśleć, jak chciałby widzieć metryki DevOps, biorąc pod uwagę, że obiektem wpływu są zespoły.
Cel metryk DevOps
Jasne jest, że wszyscy chcą skrócić czas dostawy. 200 dni to oczywiście niedopuszczalne.
Ale jak, oto pytanie?
W firmie pracują setki zespołów, a przez pipeline DevOps przechodzą codziennie tysiące dystrybucji. Rzeczywisty czas dostawy będzie wyglądał jak rozkład. Każdy z zespołów będzie miał swój własny czas i specyfikę. Jak w tym chaosie znaleźć cokolwiek?
Odpowiedź przyszła sama – trzeba znaleźć problematyczne zespoły i dowiedzieć się, co się u nich dzieje i dlaczego trwa to tak długo, a od „dobrych” zespołów nauczyć się, jak wszystko robić szybko. Aby to osiągnąć, należy zmierzyć czas, jaki zespoły spędzają na każdym z standów DevOps:
„Celem systemu będzie selekcja zespołów według czasu przejścia przez standy, co oznacza, że w efekcie powinniśmy otrzymać listę zespołów z określonym czasem, a nie liczbę.
Jeśli dowiemy się, ile czasu łącznie poświęcono na stand oraz ile czasu spędzono na przestojach między standami, będziemy mogli znaleźć zespoły, zadzwonić do nich i dokładniej zbadać przyczyny oraz je wyeliminować” — pomyślał Ivan.
Jak obliczyć czas dostawy dla DevOps
Aby obliczyć, trzeba było zagłębić się w proces DevOps i jego elementy.
W firmie korzysta się z ograniczonej liczby systemów, a informacje można uzyskać tylko z nich i nigdzie indziej.
Wszystkie zadania w firmie były rejestrowane w Jira. Gdy zadanie było brane do pracy, tworzono dla niego branch, a po realizacji dokonywano commitu w BitBucket i Pull Request. Po zaakceptowaniu PR (Pull Request) automatycznie tworzono dystrybucję, która była przechowywana w repozytorium Nexus.
Następnie dystrybucja była wdrażana na kilku standach za pomocą Jenkins w celu sprawdzenia poprawności nałożenia, automatycznego i ręcznego testowania:
Ivan opisał, z jakich systemów można pobrać informacje, aby obliczyć czas na standach:
- Z Nexus – Czas utworzenia dystrybucji oraz nazwa folderu, w którym znajdował się kod zespołu
- Z Jenkins – Czas rozpoczęcia, czas trwania oraz wynik każdej pracy, nazwa standu (w parametrach pracy), etapy (kroki pracy), link do dystrybucji w Nexus.
- Jira i BitBucket Ivan postanowił nie uwzględniać w potoku, ponieważ bardziej dotyczyły one etapu rozwoju, a nie wdrażania gotowej dystrybucji na standach.
Na podstawie dostępnych informacji stworzono taki schemat:
Znając, ile czasu zajmuje tworzenie dystrybucji i ile czasu jest wydawane na każdą z nich, można łatwo obliczyć całkowite koszty przejścia przez cały proces DevOps (pełny cykl).
Oto jakie metryki DevOps otrzymał Ivan w rezultacie:
- Liczba utworzonych dystrybucji
- Udział dystrybucji, które „weszły” na stand i „przeszły” stand
- Czas spędzony na standzie (cykl standu)
- Pełny cykl (łączny czas dla wszystkich stanowisk)
- Czas trwania zadań
- Czas bezczynności między stanowiskami
- Czas bezczynności między uruchomieniami zadań na jednym stanowisku
Z jednej strony, metryki bardzo dobrze charakteryzowały pipeline DevOps z punktu widzenia czasu, z drugiej — były postrzegane jako bardzo proste.
Zadowolony z dobrze wykonanej pracy, Ivan przygotował prezentację i poszedł przedstawić ją kierownictwu.
Wracał z niezadowoloną miną i opadającymi rękami.
— To porażka, bracie — uśmiechnął się ironiczny kolega…
Ciężko w to uwierzyć, ale ciąg dalszy znajdziesz w artykule «».
Źródło: habr.com
