Szczerze mówiąc, Iwan często śmiał się z daremnych wysiłków swoich kolegów z działu monitoringu. Dołożyli wszelkich starań, aby wdrożyć wskaźniki, które zlecił im zarząd firmy. Byli tak zajęci, że nie chcieli, żeby ktokolwiek inny się czymkolwiek zajmował.
Zarządom jednak to nie wystarczyło – ciągle zamawiali coraz to nowe mierniki, bardzo szybko przestając korzystać z tego, co robiono wcześniej.
Ostatnio wszyscy mówią o LeadTime – czasie dostarczania funkcji biznesowych. Wskaźnik pokazywał zawrotną liczbę – 200 dni na wykonanie jednego zadania. Jak wszyscy wznosili ochy i achy, i podnosili ręce do nieba!
Po pewnym czasie szum stopniowo ucichł i zarząd otrzymał polecenie stworzenia kolejnej metryki.
Dla Iwana było całkowicie jasne, że nowa metryka równie spokojnie umrze w ciemnym kącie.
Rzeczywiście, pomyślał Iwan, wiedząc, że ta liczba nikomu nic nie mówi. 200 dni czy 2 dni - nie ma różnicy, bo nie da się ustalić przyczyny na podstawie liczby i zrozumieć, czy to dobrze, czy źle.
To typowa pułapka metryk: wydaje się, że nowa metryka powie istotę istnienia i wyjaśni jakąś tajemnicę. Wszyscy na to bardzo liczą, ale z jakiegoś powodu nic się nie dzieje. Tak, bo sekretu nie należy szukać w metrykach!
Dla Iwana był to etap zaliczony. Zrozumiał to do pomiarów i trzeba szukać wszystkich tajemnic , tj. polega na tym, że ta metryka jest tworzona.
W przypadku sklepu internetowego obiektem wpływu będą jego klienci, którzy przynoszą pieniądze, a dla DevOps – zespoły tworzące i wdrażające dystrybucje za pomocą potoku.
Któregoś dnia, siadając w wygodnym fotelu na korytarzu, Ivan postanowił dokładnie przemyśleć, jak chce widzieć metryki DevOps, biorąc pod uwagę fakt, że obiektem wpływu są zespoły.
Cel wskaźników DevOps
Oczywiste jest, że każdemu zależy na skróceniu czasu dostawy. 200 dni to oczywiście niedobrze.
Ale jak, oto jest pytanie?
Firma zatrudnia setki zespołów, a przez potok DevOps codziennie przechodzą tysiące dystrybucji. Rzeczywisty czas dostawy pojawi się w postaci rozkładu. Każdy zespół będzie miał swój własny czas i swoją własną charakterystykę. Jak znaleźć cokolwiek w tym bałaganie?
Odpowiedź pojawiła się naturalnie – musimy znaleźć zespoły problemowe, dowiedzieć się, co się z nimi dzieje i dlaczego to tak długo trwa, a także nauczyć się od „dobrych” zespołów, jak zrobić wszystko szybko. A żeby to zrobić, trzeba mierzyć czas spędzony przez zespoły na każdym ze stanowisk DevOps:
„Zadaniem systemu będzie selekcja drużyn na podstawie czasu przejścia przez trybuny, czyli tzw. W rezultacie powinniśmy otrzymać listę poleceń z wybranym czasem, a nie liczbą.
Jeśli dowiemy się, ile czasu łącznie spędziliśmy na stoisku i ile czasu spędziliśmy na przestojach między stoiskami, będziemy mogli znaleźć ekipy, zadzwonić do nich, dokładniej poznać przyczyny i je wyeliminować” – pomyślał Iwan.
Jak obliczyć czas dostawy dla DevOps
Aby to obliczyć, trzeba było zagłębić się w proces DevOps i jego istotę.
Firma korzysta z ograniczonej liczby systemów, a informacje można uzyskać tylko z nich i nigdzie indziej.
Wszystkie zadania w firmie zostały zarejestrowane w Jira. Gdy podjęto się zadania, tworzono dla niego gałąź, a po realizacji dokonywano zatwierdzenia do BitBucket i Pull Request. Po zaakceptowaniu żądania PR (Pull Request) dystrybucja została automatycznie utworzona i zapisana w repozytorium Nexusa.
Następnie dystrybucja została wdrożona na kilku stanowiskach przy użyciu Jenkinsa do sprawdzenia poprawności rolloutu, testów automatycznych i manualnych:
Ivan opisał, z jakich systemów można uzyskać informacje do obliczenia czasu na stoiskach:
- Z Nexusa – czas utworzenia dystrybucji i nazwa folderu zawierającego kod polecenia
- Od Jenkinsa – Czas rozpoczęcia, czas trwania i wynik każdego zadania, nazwa stoiska (w parametrach zadania), etapy (kroki zadania), link do dystrybucji w Nexusie.
- Ivan zdecydował się nie włączać Jiry i BitBucketa do procesu, ponieważ… dotyczyły one bardziej etapu developmentu, a nie wypuszczania gotowej dystrybucji na stoiska.
Na podstawie dostępnych informacji sporządzono następujący diagram:
Wiedząc, ile czasu zajmuje utworzenie dystrybucji i ile czasu poświęca się na każdą z nich, możesz łatwo obliczyć całkowity koszt przejścia przez cały potok DevOps (pełny cykl).
Oto wskaźniki DevOps, które uzyskał Ivan:
- Liczba utworzonych dystrybucji
- Udział dystrybucji, które „przyszły” na stoisko i „minęły” stoisko
- Czas spędzony na stojaku (cykl stoiska)
- Pełny cykl (całkowity czas dla wszystkich stanowisk)
- Czas trwania pracy
- Przerwa między stoiskami
- Przestoje pomiędzy kolejnymi uruchomieniami pracy na tym samym stanowisku
Z jednej strony metryki bardzo dobrze charakteryzowały potok DevOps pod względem czasu, z drugiej strony uznawano je za bardzo proste.
Zadowolony z dobrze wykonanej pracy, Ivan przedstawił prezentację i poszedł przedstawić ją kierownictwu.
Wrócił ponury i z opuszczonymi rękami.
„To fiasko, bracie” – ironiczny kolega uśmiechnął się…
Przeczytaj więcej w artykule „".
Źródło: www.habr.com