(Czas do rynku).
Nawet w weekendy myślał o metrykach: „I co z tego, że zmierzę czas? Co to mi da?”
Rzeczywiście, co daje wiedza o czasie? Załóżmy, że dostawa zajmuje 5 dni. I co dalej? To dobrze czy źle? Nawet jeśli to źle, to trzeba jakoś zredukować ten czas. Ale jak?
Te myśli nie dawały mu spokoju, ale rozwiązanie się nie pojawiało.
Ivan zdawał sobie sprawę, że zbliża się do sedna sprawy. Niezliczone wykresy metryk, które widział wcześniej, dawno przekonały go, że standardowe podejście nie zadziała, i że jeśli po prostu zbuduje wykres (), to nie przyniesie mu to żadnego pożytku.
Co zatem robić?…
Metryka to jak zwykła drewniana linijka. Pomiary dokonane za jej pomocą nie powiedzą, dlaczego dlaczego mierzony przedmiot ma dokładnie taką długość, jaką wskazuje. Linijka po prostu pokaże jego rozmiar i nic więcej. Nie jest kamieniem filozoficznym, a jedynie kawałkiem drewna, którym mierzy się.
„Stalowa szczur” jego ulubionego pisarza Harry'ego Harrisona zawsze mówił: myśl powinna dotrzeć do dna mózgu i tam się zatrzymać, dlatego po bezowocnym męczeniu się przez kilka dni Ivan postanowił zająć się innym zadaniem…
Po kilku dniach, czytając artykuł o sklepach internetowych, Ivan nagle zrozumiał, że wysokość przychodów, które generuje sklep internetowy, zależy od tego, jak zachowują się odwiedzający stronę. To oni, odwiedzający/kliëci, przekazują sklepom swoje pieniądze i są ich źródłem. Na ostateczną wysokość środków finansowych uzyskiwanych przez sklep wpływają zmiany w zachowaniu klientów, a nie coś innego.
Okazało się więc, że aby zmienić mierzony parametr, należy wpływać na tych, którzy go kształtują, tzn. żeby zmienić ilość pieniędzy w sklepie internetowym, trzeba wpływać na zachowanie klientów tego sklepu, a aby zmienić czas dostawy w DevOps, należy wpływać na zespoły, które ten czas "tworzą", tzn. używają DevOps w swojej pracy.
Ivan zrozumiał, że metryki DevOps nie powinny przedstawiać wykresów. Powinny stanowić narzędzie poszukiwania "wybitnych" zespołów, które kształtują ostateczny czas dostawy.
Żadna metryka nie pokaże przyczyny, dlaczego dana drużyna długo dostarczała dystrybucję, myślał Ivan, ponieważ w rzeczywistości przyczyn może być tysiąc i jedna, i mogą to być całkowicie nie techniczne, a organizacyjne. To znaczy, maksymalnie, co można oczekiwać od metryk, to pokazanie wyników drużyn i ich osiągnięć, a potem i tak trzeba będzie podejść do tych drużyn osobiście i dowiedzieć się, co się wydarzyło.
Z drugiej strony w firmie Ivana istniał standard, który zobowiązywał wszystkie drużyny do sprawdzania kompilacji na kilku stanowiskach. Drużyna nie mogła przejść do następnej stacji, dopóki nie zakończyła wcześniejszej. Dlatego jeśli wyobrazić sobie proces DevOps jako sekwencję przechodzenia przez stanowiska, metryki mogłyby pokazywać czas, który drużyny spędzają na tych stanowiskach. Znając stanowisko i czas drużyny, można by bardziej precyzyjnie rozmawiać z nią o przyczynach.
Nie zastanawiając się długo, Ivan podniósł słuchawkę i wykręcił numer osoby, która dobrze znała się na szczegółach DevOps:
— Denis, powiedz mi proszę, czy można jakoś zrozumieć, że drużyna przeszła daną stację?
— Oczywiście. Nasz Jenkins ustawia flagę, jeśli kompilacja została pomyślnie wdrożona (przeszła test) na stanowisku.
— Super. A co to jest flaga?
— To zwykły plik tekstowy typu „stan_OK” lub „stan_FAIL”, który mówi, że kompilacja przeszła lub nie przeszła stanowiska. Rozumiesz, tak?
— Zasadniczo tak. Pisany jest do tego samego folderu w repozytorium, w którym znajduje się kompilacja?
— Tak
— A co się stanie, jeśli kompilacja nie przejdzie stacji? Będzie trzeba robić nową kompilację?
— Aha
— No dobrze, dziękuję. I jeszcze jedno pytanie: czy dobrze rozumiem, że jako datę przejścia stacji mogę używać daty utworzenia flagi?
— Absolutnie!
— Super!
Zainspirowany Ivan odłożył słuchawkę i uświadomił sobie, że wszystko powoli nabiera sensu. Znając datę utworzenia pliku kompilacyjnego i daty utworzenia flag można było z dokładnością do sekundy obliczyć, ile czasu drużyny spędzają na każdym stanowisku i zrozumieć, gdzie spędzają najwięcej czasu.
„Rozumiejąc, gdzie znika najwięcej czasu, precyzyjnie znajdziemy drużyny, podejdziemy do nich i zgłębimy problem”. Ivan uśmiechnął się.
Na jutro postanowił nakreślić architekturę rysowanej systemu.
Ciąg dalszy nastąpi…
Źródło: habr.com
