Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka na Patoarchitekci.io lub gdzieś w opisie na dole, ogarniecie spokojnie.

Łukasz Kałużny: Dobra, zbliżamy się do końca trzeciego sezonu. Przypominamy o jesiennych szkoleniach, bo już część wiosenno-wakacyjna za nami, czyli Patoarchitekci.io/szkolenia. Będą Container Appsy, modelowanie danych, sporo Kubernetesa, networking sieciowy i być może Architektura 101, bo trochę osób się dopytuje o kolejną już edycję.

Szymon Warda: I w ogóle gdybyście mieli jakieś pomysły albo jakieś potrzeby odnośnie szkoleń to piszcie, bo to są nasze pomysły, ale podejrzewam, że możemy też o kilku innych rzeczach pogadać.

Łukasz Kałużny: Albo zrobić to dedykowane u Was. Co dzisiaj Szymonie mamy za temat?

Szymon Warda: Temat, który wałkujemy już od jakiegoś czasu tak naprawdę regularnie, ale nadarzyła się fajna okazja, żeby porozmawiać sobie o DORA, metrykach, wydajności zespołów.

Łukasz Kałużny: I zrobimy to z bardzo praktycznym podejściem.

Szymon Warda: Tak.

Łukasz Kałużny: Dzisiejszym naszym gościem jest Kinga Gaździńska. I temat, o którym będziemy rozmawiać, złapałem, bo zdarza jej się występować na konferencjach z ciekawymi rzeczami i z tym występowała na InfoShare. Na co dzień Kinga jest architektką w grupie Pracuj, z głównie backgroundem .Netowym. A ja Kingę też poznałem na szkoleniu z Kubernetesa, jeżeli dobrze pamiętam, albo którychś konsultacjach, które robiliśmy w grupie Pracuj. Cześć Kinga.

Kinga Gaździńska Świetna pamięć. Cześć, cześć wszystkim.

Łukasz Kałużny: Tak, zapamiętałem, bo byłaś aktywna wtedy bardzo mocno na tym szkoleniu.

Kinga Gaździńska Brzmi jak ja.

Szymon Warda: Dobrze, to zanim się rozpędzimy, ja już temat znam, to zróbmy słów wstępu, bo dzisiaj mówimy o DORA, więc zacznijmy od tego, w ogóle czym są metryki DORA, żeby uporządkować.

Kinga Gaździńska Jasne. Więc ok. 10 lat temu już, kiedy ruch DevOps się na dobre już rozhulał i ludzie zauważyli, że nadal jest tak, że często programiści mówią, że działa tylko na ich maszynach. Parę osób postanowiło, że zbada w sposób taki bardziej akademicki, jakie czynności wykonywane przez organizację i jakie cechy ich procesu wytwarzania oprogramowania wpływają pozytywnie na ich konkurencyjność na rynku, na to, że zespoły dowożą feature’y dla klientów i wszystko się ze sobą spina. I tak właśnie powstał ruch DORA, czyli DevOps Research and Assessment. I ta organizacja przez już 10 lat wypuszcza rok do roku raporty, gdzie stara się opisać na podstawie ankiet zebranych przez siebie wśród specjalistów z całego świata, w tej chwili to już są tysiące firm o różnych bardzo wielkościach i z różnych branż, gdzie ludzie odpowiadają na pytania i na podstawie tego w jakiś bardziej akademicki niż mniej sposób zbierane są wnioski. I w jednym z pierwszych już wniosków, bo właściwie prawie od pierwszych edycji raportu te metryki, kluczowe metryki zaistniały, było, że można przewidzieć to, jak będzie performowała organizacja na podstawie właśnie czterech, tylko czterech mierzalnych wskaźników. I były to, z małymi zmianami przez lata, Lead Time for Changes, czyli czas potrzebny od tego, żeby kod, który programista zakomitował, znalazł się na produkcji, był używany przez klientów. Niektórzy jeszcze definiują to w sposób bardziej rozciągły, czyli ten czas, który odpływa od tego, że klient dokonał jakiegoś requestu do tego, żeby ten request został usatysfakcjonowany. Kolejna metryka to jest Deployment Frequency, częstotliwość wdrożeń, to jak często kod jest deployowany na produkcję. Następne to Change Failed Percentage, jak często te wdrożenia, które wykonujemy, kończą się niedostępnością systemu czy jakimiś bugami, które musimy następnie poprawić. I Failed Deployment Recovery Time - jak długo po tym nieudanym wdrożeniu potrzebujemy, żeby system, usługa z powrotem była funkcjonalna.

Łukasz Kałużny: Dobra, to słuchajcie i teraz, bo zaprosiliśmy Cię, bo tytułem było właśnie jak wygląda wdrożenie DORA w organizacji. I pierwsza z rzeczy, która nam się nasunęła z Szymonem, jak o tym myśleliśmy, to w ogóle co było intencją, po co wdrożyliście te metryki?

Kinga Gaździńska Tak, klasycznie, każdy chce, żeby było jak najszybciej przy tym jak najlepiej. Więc główną intencją było przyspieszenie developmentu w organizacji, ale zrobienie tego też w sposób przemyślany. Byliśmy również ciekawi, jak pozycjonujemy się w branży. Czyli zaczęło się od przyspieszenia, ponieważ przyspieszenie to accelerate, ponieważ accelerate to książka twórców, również tych osób zaangażowanych w organizację DORA, gdzie te metryki są opisane. Ale jak już się zorientowaliśmy, że jest coś takiego, że to działa i w dodatku jeszcze koszt wdrożenia tego wydawał się naprawdę nieduży, to postanowiliśmy, że chcemy zobaczyć, jak pozycjonujemy się w branży. Ale też mieliśmy przemyślenie, że w ogóle można zacząć od tylu różnych obszarów poprawę, że fajnie by było mieć jakąś metodykę, która nam powie, od którego obszaru należałoby zacząć w ogóle myślenie o optymalizacjach procesu. A także wiedzieliśmy, że przed nami będą już niedługo różne projekty związane z wymianą pewnych narzędzi, których używamy w procesie CI/CD na inne narzędzia, że będziemy zmieniać środowisko w On-premie, itp. I chcieliśmy zebrać mierzalnie, porównać, być w stanie porównać jak ta zmiana wpłynie na szybkość dostarczenia feature’ów na produkcję.

Łukasz Kałużny: Wiesz co, chciałbym się jeszcze dopytać przy tym wdrożeniu, w jaki sposób patrzyliście na te metryki, że one przyspieszą?

Kinga Gaździńska Tak naprawdę same metryki wiedzieliśmy, że nie przyspieszą, ale byliśmy ciekawi, które obszary. Czyli można podzielić te metryki na takie dwie, które mówią o tym, jak szybko i jak często coś wdrażamy, ale też te dwie drugie, które stoją na straży tego, żeby to, co wdrażamy, nadal było dobrej jakości, żeby klienci mogli korzystać, a nie tylko cieszyć się z tego, że ich feature wjechał na produkcję, tylko że jest nieużyteczny. Więc wiedzieliśmy, że efekt powinien być taki, że jak zobaczymy, że w którejś metryce odstajemy mocno od branży, albo że któraś jest niższa niż byśmy sobie marzyli w tym pozycjonowaniu zaproponowanym przez DORA, to że tam powinniśmy się skupić i dociec dlaczego ta wartość jest taka, a nie inna.

Szymon Warda: Cały czas właśnie mówisz w formie mnogiej - my. A to co mnie zainteresowało to było właśnie kto był inicjatorem tak naprawdę? Bo to jest zawsze ciekawe, z kogo wychodzi inicjatywa i kto jest tą osobą, która chciałaby to faktycznie wdrożyć?

Kinga Gaździńska W przypadku naszej organizacji to było dosyć proste, bo inicjatorem były zarazem osoby, które były władne, żeby taki projekt wdrożenia przeprowadzić. Głównie można powiedzieć, że to był szef zespołu architektów, Kamil Piechociak, który się zajął researchem na ten temat, wydaniem książki “Accelerate” i decyzją, że warto te metryki zrobić. Ale też człowiek, który był w stanie zasponsorować ten projekt. Dyrektor działu technologii, można powiedzieć właściwie, że CTO naszej grupy. Więc tutaj było dużo szczęśliwych zdarzeń, które pewnie nie są udziałem każdej firmy. Wyobrażam sobie, że jeżeli to byłby proces zupełnie oddolny, grupa programistów myśli sobie, że byłoby super to mierzyć, to może być trochę dłuższa droga do wprowadzenia tych metryk. Ale co mnie się osobiście bardzo podoba jest to, że nawet nie mierząc jeszcze niczego, nie zbierając danych, konkretnych dat wdrożeń i tych punktów, już można sobie na podstawie swojego gut feeling czy na podstawie swoich doświadczeń oszacować, wziąć udział w tej ankiecie, prostej, czterokrokowej i już się zpozycjonować względem swojego produktu. I wtedy z takim wynikiem można już pójść do przełożonego czy do managera jakiegoś produktu i dalej próbować namawiać do wdrożenia.

Łukasz Kałużny: Dobra, to teraz przejdźmy bardziej do technikaliów. Jak wyglądało wdrożenie metryk? Może zacznijmy od tego, które wybraliście metryki do mierzenia?

Kinga Gaździńska Tak naprawdę w uproszczeniu można powiedzieć, że wszystkie. W uproszczeniu, bo jak podchodzi się do wdrożenia tych metryk, to zaczyna się okazywać, że trzeba zastosować pewną swoją interpretację. To jest zarazem spora wada akurat tych Four Keys metrics DORA, że jest tam przestrzeń na interpretację. Nieoczywista, bo na pierwszy rzut ucha, jak słyszy się te nazwy tych metryk, to wydaje się, że to jest dosyć precyzyjne. Natomiast każdy ma odrobinę inny proces dostarczania oprogramowania i DORA tutaj nie definiuje, w którym momencie należy wziąć start procesu np. wdrażania zmian na produkcję. Nawet rozmawialiśmy z konsultantem tutaj z Googla, który też jest ewangelizatorem m.in. w zakresie DORA i on zapytany, które czasy warto obserwować, powiedział, że pewnie wszystkie. Więc to też jest jakiś sposób, żeby łapać sobie różne punkty i mieć po prostu więcej tych metryk, niż wynika to z tej nazwy. Więc zaczęliśmy mierzyć wszystkie metryki, tylko też ten nasz proces wdrożenia przebiegał oczywiście z zachowaniem miejsca na tuning. Czyli na samym początku to, co zrobiliśmy, to ankietę. Kilka osób siadło sobie i na podstawie swojego takiego gut feeling zrobiło, przeszło przez tę ankietę bez mierzenia czegokolwiek. Dostaliśmy w miarę zbliżone wyniki. Potem staraliśmy się sobie na poziomie całej spółki Pracuj.pl przemyśleć jak wygląda ten nasz proces wytwarzania oprogramowania tak, żeby złapać główne punkty. Zastanawialiśmy się też, jakie informacje już zbieramy, bo mamy całkiem rozbudowaną platformę developerską, można tak powiedzieć. Czyli mamy kilka narzędzi używanych już przez programistów, tak żeby przyspieszyć proces tworzenia nowych aplikacji. Np. ustandaryzowaliśmy już kilka lat temu proces wdrożenia aplikacji, dzięki czemu programista może tylko używając komendy w command line poprosić o utworzenie sobie projektu w TeamCity czy w Octopusie. Więc to nam bardzo uprościło to, że już mieliśmy wdrożoną taką standaryzację i tuning, do tego integrację z API Octopusa, integrację z API GitHuba, TeamCity, to to bardzo uprościło proces wdrożenia. Więc zrobiliśmy sobie taki pogląd na to, jakie dane już możemy gdzieś mieć odłożone w też naszym takim systemie do sprawdzania jak poziom Nonfunctional Requirements jest spełniony w różnych aplikacjach, więc nie startowaliśmy tak zupełnie od zera. Ale było dużo informacji, których nam jeszcze brakowało, więc musieliśmy się zastanowić skąd je pozyskać. Oczywiście zrobiliśmy też research dostępnych już narzędzi i powiedzieliśmy, że skoro to jest tak znana tematyka, to na pewno jakieś gotowce są dostępne na rynku. I faktycznie, tylko że niestety żaden z nich nas nie przekonał tutaj w zespole, bo każdy z nich narzucał dużo uproszczeń i ograniczeń, jeszcze więcej niż my przyjęliśmy. Być może gdybyśmy korzystali z jednego jakiegoś, mielibyśmy tylko po prostu Jenkinsa, który oplikuje cały pipeline, czy wszystko robili przez GitHuba, być może znaleźlibyśmy jakiś taki tool. Ale niestety to nie jest, niestety stety, to nie jest nasz przypadek. Więc po tym jak już mieliśmy pogląd jak to mniej więcej powinno wyglądać, jaki mamy model, zdecydowaliśmy, które punkty są dla nas interesujące, zabraliśmy się do implementacji. Tutaj napotkaliśmy pierwsze problemy. Głównie tutaj kolega, który się z tym zmierzył, kolega z zespołu, to Michał Smaga, on poświęcił niecały kwartał myślę z pomocą koncepcyjną ze strony zespołu, z naszej strony tutaj i też ze strony zespołu, który zajmuje się bardziej infrastrukturą. On poświęcił mnóstwo czasu na to, żeby zrozumieć, jak połączyć np. commity czy pull requesty z tym, co w Octopusie jest wdrażane, z wersją aplikacji, która jest wdrażana. Dokonywał różnych eksperymentów. Czasami to wychodziło lepiej, czasem gorzej. Więc taki proces decyzji i jeszcze dostosowywania tego, co jest wysyłane do Octopusa, tego jak jest tagowany, jakie tagi są też w GitHubie publikowane, trwał przez przez chwilę. I następnie już zobaczyliśmy pierwsze wyniki, więc tutaj były kolejne decyzje. Np. można było zaobserwować, że jeśli ktoś zmieni plik Readme, ta zmiana przejdzie też przez review, bo każda zmiana u nas przechodzi przez review, ten pull request jest zaakceptowany i naturalnie wtedy wdrożenie nie następuje, w tym wyniku, bo została zmieniona tylko dokumentacja. Ale jeżeli parę miesięcy później ktoś wdroży aplikację to ona jest powiązana z tym pull requestem. Więc ten czas time for changes po prostu nam wystrzelił do 200-kilkudziesięciu dni np. I to znowu była kwestia obcięcia takich maxów czy nie powiązywania np. zmian w plikach Readme tylko i w dokumentacji. Tak że trochę takich wykluczeń też musieliśmy poczynić. I na sam koniec to jest już czerpanie korzyści z tego co wdrożyliśmy, czyli raz na jakiś czas z naszym ultra skomplikowanym interfejsem do wyciągania tych metryk, który w tej chwili jest po prostu SQL-ką odpalaną on demand, raportujemy w momencie, w którym to jest ciekawe czy kogoś interesuje.

Łukasz Kałużny: To zaraz sobie do tego przejdziemy. To słuchaj, dwie rzeczy, które trochę poleciały w tym, co zaczęłaś mi odpowiadać, to realnie kto jest właścicielem procesu?

Kinga Gaździńska Właścicielem tego procesu w tej chwili jest zespół architektów. My działamy trochę, nasz zespół działa na pograniczu zespołów developerskich. Współpracujemy z różnymi zespołami developerskim, ale też jesteśmy odpowiedzialni za dostarczanie tych narzędzi przyspieszających kodowanie, a także platformy opartej na backstage’u od Spotify’a. Więc to wszystko tak się spina, że ten proces wydaje się, że ma sens, że jest u nas. Też dlatego, że jesteśmy odpowiedzialni za standaryzację, za dostarczenia standardów, więc gdzieś w naszych okolicach leży decyzja, jak powinny te procesy wdrażania, programowania wyglądać.

Łukasz Kałużny: A kto realnie to wdraża? Czyli to jest też wasz zespół realnie zajmował się tym wdrożeniem w tym wypadku?

Kinga Gaździńska To akurat było założenie, postawiliśmy sobie za cel, czy też nasz szef postawił sobie za cel, żeby zespoły developerskie nie musiały się dostosowywać w żaden sposób, żeby nie musiały też niczego deklaratywnie dostarczać. Bo łatwo sobie można było wyobrazić, że jako punkt startu bierzemy sobie jakiś moment, kiedy ktoś przyciska specjalnie przygotowany przycisk na ten cel, że właśnie zaczynam development zadania i chcieliśmy uniknąć za wszelką cenę takich dodatkowych działań. Tak samo tego, żeby trzeba było coś w Gira oznaczyć na zadaniu. Chociaż oczywiście te wszystkie opcje rozważaliśmy.

Szymon Warda: Trochę zaczęłaś o tym mówić i to jest chyba też obszar, który też sporo osób interesuje, bo powiedziałaś, że to wam zajęło mniej więcej kwartał. Trochę mówiłeś o problemach. A tak gdybyś mogła przejrzeć, przejść przez to właśnie, co było faktycznie łatwe, co was zaskoczyło, że łatwo się udało i było w porządku, a co realnie było dużo trudniejsze niż zakładaliście tak naprawdę?

Kinga Gaździńska Dużo łatwiejszy był ten proces zbierania metryk dla Azure’a. Bo może powinnam jeszcze powiedzieć, że działamy w dwóch środowiskach. Jedno to jest AKS. Drugie to jest On-premowe serwery wirtualki, więc w związku z tym mamy taki tooling troszeczkę dwojaki. I to była zarazem trudność, że musieliśmy zająć się, czy też chcieliśmy zająć się zebraniem aplikacji wdrażanych na środowisko On-premowe, bardziej klasyczne serwery, jak i na AKS-a. Na AKS-a było łatwiej to zrobić też dzięki temu, że całkiem tutaj nam Łukasz dobrze pomaga i to środowisko jest zaopiekowane. Więc tam publikacja dodatkowej labelki np. nie była problemem. Natomiast dla środowiska On-premowego, gdzie mamy Octopusa, w Team City budujemy aplikację, z GitHuba pobieramy kod, to okazało się troszeczkę bardziej skomplikowane i trzeba było też pewne uproszczenia przyjąć. Poziom skomplikowania też był zwiększony tym, że mamy różne technologie. Dla różnych technologii odrobinę różnią się procesy wdrażania, więc też ucinaliśmy zakres po prostu. Uznawaliśmy, że dla części aplikacji nie będziemy zbierać tych metryk na razie, że np. 80% naszych aplikacji to jest .Net, więc interesuje nas na pierwszy rzut to, co się dzieje z tymi aplikacjami, bo one są najczęściej wdrażane np. A to, co było z kolei łatwe, to powiedziałabym, że sam ten proces potem przeliczania, bo można by sobie wyobrazić, że to są jakieś straszne, duże ilości danych, ale tak naprawdę podeszliśmy do tego w sposób może trochę naiwny, ale okazało się, że się sprawdził. Czyli raz na dzień przychodzą odpalane grunge’owe updatery, które wyciągają sobie informacje z GitHuba, wyciągają informacje z Octopusa i zapisują je do SQL-owej tabelki na Azure, nothing fancy nudne, ale działa.

Łukasz Kałużny: Stare, skuteczne podejście do Business Intelligence, przeliczyć raz na dzień i będzie dobrze.

Kinga Gaździńska Tak, tak, dokładnie. Gdyby zmiany w naszym procesie developmentu były tak dynamiczne, to byśmy musieli je dosłownie suwaczkami gdzieś poprawiać, to oczywiście tak byśmy podeszli też do mierzenia metryk. Ale ponieważ to nie jest informacja, która nam jest potrzebna na bieżąco, wystarczy nam spokojnie raz na jakiś czas, to uznaliśmy, że pójdziemy po linii najmniejszego oporu. I to zadziałało.

Łukasz Kałużny: Bo sporo mówimy, co się udało, tak patrząc. A słuchaj Kinga, co się nie udało, tak z perspektywy, której planowaliście w tym momencie?

Kinga Gaździńska Tak, to pierwsze co, mamy jednak wciąż część aplikacji, mimo że standaryzację wprowadziliśmy już parę lat temu, mamy część aplikacji, które nie są tak bardzo ustandaryzowane. W związku z tym musieliśmy się pogodzić z tym, albo pogodziliśmy się z tym, że dla nich nie będziemy mieli tych metryk zbieranych w sposób automatyczny. Dla nich możemy sobie przeprowadzać je jakoś on demand, gdyby zaszła taka okoliczność. To nie jest duży procent aplikacji, ale wciąż ograniczaliśmy koszt wdrożenia tego projektu, tak to nazwę. Dosyć szybko po wdrożeniu metryk, po tym, jak zaczęliśmy mierzyć, jeszcze nawet w trakcie ich wdrażania, okazało się, że roll backi zajmują dużo więcej czasu niż byśmy sobie marzyli. I od razu była pierwsza pozytywna zmiana zainicjowana tym. Czyli dodaliśmy do naszych kroków w Team City krok roll back, bardzo prosty. I tutaj była taka edukacja, że: drogi programisto, jeżeli zobaczysz, że jednak to wdrożenie twoje nie poszło, to zamiast wgrywać za chwilę nową wersję aplikacji, albo zamiast powtarzać deployment i ręcznie ustawiać poprzednią wersję, kliknij po prostu roll back. Dzięki temu będziemy mogli zbierać informacje automatycznie, ile tych roll backów było, jak długo one trwały. Tylko, że za tym idzie z kolei edukacja. Tylko przecież edukowaliśmy na moment wdrożenia tego przycisku, a przychodzą nowi ludzie, to trzeba ich z tym zapoznać. Też te roll backi nie wydarzają się zbyt często, ludzie o nich zapominają. Tak że to jest takie kolejne wyzwanie, że gdzieś jednak ten standard, który się przewija tu przez moje wypowiedzi, jest ważny. I wszystko, co pójdzie ścieżką niestandardową, jest nie do wyłapania automatycznym mierzeniem. Też ten lead time, który my uznaliśmy, że chcemy nie zajmować się na początku tym, jak długo w zespole trwa np. code review. Uznaliśmy, że to jest trochę część procesu, na którą mamy dużo mniejszy wpływ jako zespół architektów i to jest coś, co zespoły powinny sobie w ramach swoich retrospekcji np. jakoś śledzić i opiekować. Więc uznaliśmy, że nas będzie interesował ten moment, kiedy już accept na pull request’cie został dany i pull request został domerge’owany do mastera. Dzięki temu widzimy faktycznie jaki narzut dają raczej narzędzia, ale czasami jest tak, ponieważ nie wszędzie mamy feature flagi czy wręcz w niewielu produktach mamy feature flagi, bo też nie ma często takich przypadków, ale zdarzają się przypadki, że jakieś wdrożenie musi poczekać na to, aż biznes powie: to jest ten moment, albo na początek nowego tygodnia, albo z powodów biznesowych. Więc to jest też taki czynnik, który potrafi nam wydłużyć lead time, mimo że nie jest on spowodowany jakimiś niedostatkami narzędzi albo nie wprost, to być może brak feature flag można uznać za jakiś niedostatek, ale nie w jakiś taki bardzo prosty sposób. Też rzecz, z którą się zmierzyliśmy w kontekście spółek zagranicznych, bo tutaj nie wspomniałam, mówiłam o tym automatycznym mierzeniu w Pracuj, ale do grupy należą też spółki z Niemiec i z Ukrainy i tam również chcieliśmy w jakiś sposób zbadać, na jakim poziomie dojrzałości są te spółki. I to, z czym się zmierzyliśmy, to nie wiem, może coś, co można barierą kulturową nazwać, może coś, co można nazwać niedostatkami w zaufaniu, ale nie zawsze ludzie chętnie dzielą się prawdziwymi wartościami, które mogą być niewygodne. I może jest to naturalny proces rozwoju spółki, że np. dużo rzadziej wdraża, albo że ten czas wdrożenia jest dużo dłuższy, czy wdrożenia częściej się kończą błędami, bo np. jest niewystarczająco budżetu na testy. To jest jak najbardziej normalna rzecz. I to, co my chcieliśmy zrobić, to zobaczyć, gdzie jest największy problem, od czego zacząć, a nie robić jakiś gaming session. Ale tam gdzie liderzy techniczni chcieli trochę zakolorować rzeczywistość, akurat biznes przyszedł nam z pomocą, bo biznes nie jest zainteresowany kolorową, zieloną trawą, tylko tym, żeby działało i żeby klienci mogli korzystać. Więc w momencie, w którym ankiety były wypełnione też przez biznes, staraliśmy się to opisać słowami bardziej zrozumiałymi dla biznesu, np. czy wystarczająco często są wdrażane nowe zmiany, albo jak długo trzeba czekać na usatysfakcjonowanie tego requestu. To dostaliśmy bardziej prawdziwe wartości i byliśmy w stanie już jakieś wnioski wyciągnąć. Tak że to jest też ciekawe, że tam, gdzie te problemy są bardziej zauważalne przez biznes, to jest też duża ochota na współpracę.

Szymon Warda: To właśnie tak przewija się przez to, co mówisz, to, że to trochę oczywiste właściwie, że te wszystkie rzeczy w DORA trzeba trochę dostosować do swojej organizacji, gdzieniegdzie uprościć, gdzieniegdzie zmienić właśnie. Gdzie były takie elementy gdzie faktycznie wam się rzuciło, że okay, to upraszczamy, to zmieniamy, to jest takie totalnie, robimy trochę zdecydowanie pod nasz wygląd, pod naszą organizację zdecydowanie?

Kinga Gaździńska Najbardziej chyba właśnie w tym lead time, czyli ucięcie obszaru zainteresowania, skrócenie tego czasu, który nas interesuje mimo, że na pewno taka informacja jak długo od pierwszego commita programisty, albo nawet jak długo od decyzji programisty, że już po jego stronie praca jest skończona, do wdrożenia, też jest bardzo ciekawą informacją i zupełnie inne wnioski z niej można wyciągnąć. Też wydaje mi się, że sam sposób korzystania z metryk, bo można do tego podejść na bardzo wiele sposobów. I o ile sami twórcy podkreślają, że te metryki nie powinny stać się KPI-em, tutaj można do znudzenia przytaczać Goodhart’s Law, że metryka, która staje się KPI-em, przestaje być dobrą metryką. To nawet po konferencji takich parę pytań do mnie trafiło, już osób, którym się zaświeciła jakaś lampka, że to jest fantastyczna metryka dla zespołu, na jakim poziomie sobie to ustaliliście i jak to działa u was? I to jest coś, czego my się zdecydowaliśmy nie robić świadomie. Czyli zbieramy metryki na poziomie wszystkich zespołów, wszystkich produktów. W tej chwili nie dzielimy ich ani na różne technologie, ani na różne zespoły, ani na różne produkty, mimo że to też może być ciekawa informacja, pod warunkiem, że nie jest to traktowane jako KPI. Więc to jest też coś, co zdecydowaliśmy. Na pewno to, że my patrzymy na te metryki w tej chwili cyklicznie, a nie jakoś bardziej na bieżąco. To też jest coś, co było decyzją na ten moment, że zaczynamy to wdrażać. Też nie chcemy, żeby to nam przysłoniło inne wskaźniki. Podobała mi się np. prezentacja na ostatnim InfoShare, przypomnienia o Developer Happiness, który też powinien być wskaźnikiem branym pod uwagę. Więc nie chcieliśmy też, żeby tylko patrzeć na te cztery cyferki, już na nic więcej. Tak, więc myślę, że to takie dostosowania z naszej strony.

Łukasz Kałużny: Dobra, słuchaj, to ja teraz, bo to było już, ale żeby też nie umknęło ludziom, to takie trzy rzeczy. Ile czasu wam tak faktycznie zajęło te wdrożenie? Bo powiedziałaś tam o kwartale kodowania, było mniej więcej. Ile czasu wam zajęło? Jaki procent firmy obejmuje i jakie było zaangażowanie ludzi? Jakbyś powiedziała jak to było ilościowo u was?

Kinga Gaździńska Ten kwartał to tak naprawdę był już development tuning i pierwsze patrzenie na pierwsze metryki. Czyli z kolei to nie obejmuje tego, co mieliśmy już wcześniej, to, o czym mówiłam, ta standaryzacja, to było parę lat, które niestety, ale czy na szczęście poświęciliśmy, ale dochodziliśmy do momentu, w którym mamy te 80-85% aplikacji wdrażanych w standardowy sposób długo i krokowo.

Łukasz Kałużny: Kinga, pozwól, że Ci się wtrącę, ja to określę dla słuchaczy, bo zawsze to powtarzam w dyskusjach, też mi się w podcaście zdarza, że platform engineering były robiony zanim był na to busworld. Jesteście jednym z tych przypadków.

Kinga Gaździńska Tak, o to dokładnie chodzi, tak, tak. Nawet z pewnym zdumieniem któregoś razu zobaczyliśmy, zobaczyliśmy w zespole, czy któreś z nas zobaczyło na konferencji. Platform Engineer, jakiś nowy trend, tak czytamy, czytamy… O, to my, robimy to. Jest tak, jak mówisz. Więc to na pewno pomogło. I tutaj, jeżeli nie ma tego w organizacji, to trzeba sobie zająć czas na, w zależności od skali, na jakąś standaryzację, na opisanie procesu i najchętniej standaryzację, bo to bardzo upraszcza. Więc ten kwartał czy dwa miesiące pracy jednej osoby to już właściwie jest całość z naszego punktu widzenia, z dokładnością tego, że mieliśmy już standaryzację wcześniej. Jeśli chodzi o to, jaki procent organizacji to obejmuje, to mierzymy dla całego Pracuj.pl z dokładnością do tych obciętych kilku procent aplikacji, których zdecydowaliśmy się nie opiekować tym, bo są mniej standardowe, zajęłoby to więcej czasu, a być może zaopiekujemy je w przyszłości, np. zmieniając platformę, wprowadzając Kubernetesa do On-prema. A w pozostałych spółkach, w pozostałych trzech spółkach, w których nie mierzymy tego automatycznie, robimy to na podstawie deklaracji i też cyklicznie. Bardzo mocno też inspirowaliśmy się tym, co jest dostępne w raportach DORA i tym, co było w książce “Accelerate”, formułując nasze własne standardy developerskie na poziomie grupy. Tutaj dzięki temu uniknęliśmy dużo dyskusji. Na podstawie preferencji byliśmy w stanie się odwołać do tego, że zobaczcie tutaj są badania, tutaj są ankiety, to działa. Chociaż może powinnam jeszcze też trochę o kontrowersjach wspomnieć wokół DORA. Niektórzy podnoszą, że te wszystkie ankiety, te roll data, które są zbierane, nie są publikowane przez autorów raportu, co może, nie musi być jakąś przestrzenią do pewnych nadużyć i tego, że też warto wspomnieć, że w tej chwili DORA została kupiona, że rozwija się w ramach Google Cloud’a, więc naturalnym jest myślenie, że może ktoś tam próbuje troszeczkę sprzedać swój produkt i warto o tym pamiętać.

Szymon Warda: Użyć statystyki, żeby były lepsze wyniki.

Łukasz Kałużny: Wiesz co, ja się, pozwól Kinga, odwołam, bo dwa razy już omawialiśmy ten raport, linki znajdziecie w opisie do tego na stronie. I też dyskutowaliśmy, że część jest machiną sprzedażową i że to w niektórych częściach raportu czuć.

Szymon Warda: Szczególnie w takich rozszerzonych metrykach.

Kinga Gaździńska Warto sobie z tego zdawać sprawę. Natomiast to jest może też ten element wybierania dla swojej firmy czy dla swojego zespołu, bo nie trzeba tego przecież robić na poziomie całej firmy, tych rzeczy, które mają szansę, czujemy, że przyniosą pozytywny efekt i eksperymentowania. A jeśli nie przynoszą pozytywnego efektu, to wycofywania się z tych eksperymentów bez żalu.

Szymon Warda: Jasne, to ja tak trochę doprecyzuję, bo ten element, wspomniałaś o tym trochę, ale żeby to trochę ustrukturyzować. Jak mierzycie, które metryki? Bo to jest dość ważny i pewnie taki dość element będzie dużą wartością dla słuchaczy.

Kinga Gaździńska To idąc od początku, lead time for changes. Moment merge’a pull requesta zaakceptowanego już do mastera piszemy z GitHuba. Następnie moment deploymentu bierzemy albo z Octopusa, albo z API Kubernetesa, AKS-a. I uznajemy to za moment, kiedy kod w wersji związany z tą zmianą, która była w pull request’cie znalazł się na pierwszej instancji serwera w On-premie np., albo pierwszy został odpalony na AKS-ie, czyli to jest pierwsza metryka. Bierzemy ten czas, który minął od jednego do drugiego punktu. Druga metryka, Deployment Frequency, osobno mierzymy ją sobie dla każdego z datacenter. Oczywiście prosta suma może nam dać całość, ale chcieliśmy też mieć pogląd na te dwa światy osobno i to bierzemy zdaje się z Octopusa i z AKS-a też zbieramy te wartości. Change Failed Percentage, to jest liczba tych momentów, w których programista kliknął przycisk roll back. Czyli tak jak mówiłam, to na pewno nam nie pokrywa 100%, ale już daje nam pewien ogląd na to, jak często zmiana wymagała wycofania. Tak długo, jak programiści pamiętają o tym, żeby wycofywać zmiany, tak jak prosimy ich o to, żeby robili. I Faild Deployment Recovery Time, uznajemy też w pewnym uproszczeniu za czas, jaki był potrzebny na przebudowanie, czy właściwie na wrzucenie tej wersji poprzedniej, tego obrazu poprzedniego, czy tej poprzedniej paczki na środowisko produkcyjne. I tutaj jeszcze taki komentarz, chociaż pewnie będziecie mnie jeszcze pytać o to, jakie są na to plany, bo to się narzuca, więc mogę nie wybiegać w przód.

Szymon Warda: Śmiało, możesz wybiegać, więc zawsze dobrze powtórzyć, wrócić do czegoś.

Kinga Gaździńska Pewnie, więc tutaj, żeby trochę zmniejszyć te dziury we wnioskowaniu, które oczywiście zdajemy sobie sprawę, że mogą być, to też postanowiliśmy zacząć mierzyć dla każdej z aplikacji, dla każdego serwisu poziom SLI. I to też wydaje nam się, że będzie trochę bardziej pokazywać, że np. Gdzieś wystąpił problem po wdrożeniu aplikacji. Więc jeżeli będziemy widzieć, że gdzieś te wartości są dużo niższe niż oczekiwane, to będziemy mogli spojrzeć też na metryki DORA, czy przypadkiem to nam gdzieś nie umyka i ten proces doszczelniać jeszcze.

Łukasz Kałużny: Wiesz co, to jeszcze tylko szybko dodam dla słuchaczy. SLI to server level indicator, czyli to co obserwujemy pod SLA, SLO, czy nasz system działa zgodnie z założeniem, upraszczając teraz bardzo.

Szymon Warda: Łukasz jest dumny z rozwinięcia tego skrótu. Tak sobie mówimy o metrykach, mówimy o systemie, który wdrożyliśmy, mówimy, że nam to zajęło 3 miesiące. Fajnie, ale teraz zejdźmy na ziemię, bo cokolwiek co daliśmy naszej organizacji, wymaga jakiegoś utrzymania, wymaga zaangażowania ludzi. Czy mierzyliście może jakkolwiek bieżący koszt utrzymania tych metryk? Nie oczekuję oczywiście kosztu w PLN czy w euro, ale chociażby zaangażowanie ludzi, jak Wam się z tym żyje na co dzień obecnie?

Kinga Gaździńska Tak, ponieważ ucinaliśmy trochę te zakresy, więc ten koszt bieżący nie jest duży. To jest koszt na Azure, który pewnie nie jest, nie mam danych, nawet nie to, że się nie chcę dzielić, ale nie mam konkretnych danych. Ale to samo świadczy o tym, że on jest zaniedbywalny na poziomie całej organizacji tego, ile wynosi faktura do Azure’a. Też nie przychodził do nas szef DevOpsów i nie groził palcem, że tutaj widzi Spike na fakturze. Więc to jest taki zaniedbywany koszt + odpalanie tych updater’ów, więc to też jest bardzo zaniedbywany koszt, jeśli chodzi o samą infrastrukturę, na której to działa. Jeśli chodzi o koszt ludzki, to też nie wymagało to, już mamy od ponad kwartału, właściwie można powiedzieć pewnie ponad pół roku, od pół roku na pewno, wiem, że mamy już, mierzymy, bo te wartości prezentowałam na Confie, więc przez te pół roku nie musieliśmy tam niczego robić, nic zaglądać. I tu jest gwiazdka, że będziemy musieli to zrobić, jak wdrożymy już nowe narzędzie do deploymentu, jak już będziemy mieli Kubernetesa w On-premie, przepniemy się na Argo CD, to będziemy musieli oczywiście dostosować te mierzenie do tego nowego procesu, więc tutaj ten koszt będziemy musieli ponieść. I przy każdej takiej zmianie w narzędziach, w toolingach taki koszt będzie do poniesienia, ale na bieżąco. Ponieważ też nie nie mamy tego nigdzie na żadnym dashboardzie wyświetlanego, więc to też nie jest tak, że ktoś tam jest delegowany do patrzenia na to odpalanie SQL-ki, jest interfejsem, który na ten moment nam wystarczał.

Łukasz Kałużny: Dobra. To słuchaj, przejdźmy teraz od technologii do tego, co się dzieje dalej. Co Wam wyszło z tych metryk? Bo już o jednej rzeczy wspomniałaś, czyli o roll backowaniu i improvement’cie na tym. A co innego Wam wyszło?

Kinga Gaździńska Tak, poza tym wspominałam już o tej naszej zagranicy i to było też dosyć ciekawe, że jak poznaliśmy wartości lead time’u i Deployment Frequency dla jednej ze spółek zagranicznych, to zorientowaliśmy się, że to jest priorytet na ten rok, żeby w tych wartościach zmienić klasyfikowanie. I dzięki temu byliśmy w stanie namówić osoby z tej spółki do przeprowadzenia takiego eksperymentu, najpierw w jednym zespole, później to się bardzo szybko rozlało na całą spółkę. To jest trzydzieści parę programistów, więc nie jest to jakaś wielka skala, ale i tak byliśmy pod wrażeniem tego, jak szybko załapało, biorąc pod uwagę, że byli dosyć konserwatywni w podejściu. Więc to jest taka realna zmiana, która już się dokonała. Biznes zadowolony, bo faktycznie deploymenty zaczęły być robione częściej. I ten czas, skrócenie tego czasu i przesunięcie odpowiedzialności w stronę zespołów, bo to na tym polegała zmiana, że jak zobaczyliśmy, jaka jest wartość metryki, to zaczęliśmy z nimi też rozmawiać, jak konkretnie ten proces wdrożenia u nich wygląda. Okazało się, że tam jest taki release manager, który musi poukładać wersję do wydania, musi to zakolejkować, jest takim w tym procesie. I po zachęceniu ich do tego, żeby jednak pozwolić ludziom deployować na produkcję i przesunąć tę odpowiedzialność w kierunku zespołów + zatrudnić więcej testerów, tak żeby też ten waterfall był trochę bardziej zwinny. Mimo, że rzeczywiście wydawało im się, że już są całkiem agile, to to jest realna zmiana, która na pewno się udała.

Szymon Warda: Dobra. A tak naprawdę mówimy sobie, że te metryki zbieramy, wszystko fajnie. A kto jest konsumentem tych metryk tak naprawdę? Jak to jest dalej propagowane w organizacji, kto czyta, kto analizuje, itd.?

Kinga Gaździńska To jest coś, co na pewno może być u nas jeszcze elementem do zmiany w przyszłości. Zresztą już obserwujemy, że to zainteresowanie się zwiększa, bo w tej chwili metryki są oglądane częściej przez nas, czyli zespół architektów z zespołami jeszcze powiedzmy DevOps czy z DevOpsami, tak, żeby mieć na bieżąco jakiś pogląd, a prezentowane kwartalnie na prezentacjach działowych. Tak że wtedy może cała firma sobie z tego skorzystać. Ale nasz dział, który zajmuje się dostarczaniem oprogramowania, dostarczeniem czy rozwojem produktów już wyraźnie wyrażał takie zainteresowanie, że oni by chcieli częściej to widzieć i też może jakieś swoje wnioski na tej podstawie wysnuwać. Więc to jest coś, co pewnie też byśmy docelowo chcieli udostępnić właśnie w naszej instancji backstage’u, czyli takiego katalogu.

Łukasz Kałużny: Wiesz co, ja teraz od razu przejdę do takiej rzeczy. A bo parę razy gdzieś określenie, że biznes się pojawiło, tak jak mówiłeś o tych zagranicznych spółkach. I pytanie w ogóle czy wychodzicie z tymi metrykami poza IT?

Kinga Gaździńska Tak jak mówię, to w tej chwili kwartalnie, w ramach prezentacji kwartalnych. Czyli to nie jest jakieś szalone wyjście też dlatego, że nie mieliśmy takiej potrzeby prowadzenia ostatnimi czasy projektów, które by jakoś znacząco wymagały czasu, skupienia zespołów developerskich, tak żeby prosić biznes o to, że tu jest coś do zrobienia i tutaj są metryki na poparcie tej tezy, że to trzeba zrobić, bo wyglądają teraz tak, oczekujemy, że będą wyglądać inaczej. I tu są jeszcze do tego badania, że jak to zrobimy, to będziemy wydajni organizacyjnie czy będziemy szybciej dostarczać oprogramowania. Ponieważ nie mieliśmy takich projektów ostatnimi czasy do zrobienia, to też nie mieliśmy potrzeby jakoś uzasadniać i wychodzić, szczególnie do biznesu z tymi wskaźnikami. Natomiast tak jak mówię, tam, gdzie w tej spółce, w której jednak taka zmiana procesu była konieczna, to ta rozmowa się odbyła. Czyli tam nie mieliśmy konkretnych wartości, ale wyniki ankiet. Zresztą zaangażowaliśmy właśnie też te osoby, które są na pograniczu biznesu i developmentu, żeby też swoje zdanie wyraziły w tym temacie.

Szymon Warda: Jasne, tak powoli, powoli będziemy zbierali ten odcinek. Tak w ramach takiego podsumowania tak naprawdę, jakie inne metryki jeszcze badaliście? Bo DORA nie jest jedynym sposobem tak naprawdę. I czemu akurat wybraliście DORA? Jak to poszło? I co dalej w ogóle planujecie z nią robić?

Kinga Gaździńska Tak. Często też w różnych narzędziach, które obiecują zająć się wydajnością dostarczania oprogramowania różnorakie metryki są serwowane. Tylko że jak zaczynaliśmy doczytywać, to okazało się, że np. tam istotną daną jest liczba linijek kodu dostarczanych przez programistę, albo w jakichś innych podejściach liczba bugów, które programista rozwiązał w jakiejś jednostce czasu. I to są takie dane, które nas, jak to ładnie nazwać, nie zauroczyły. Z naszego doświadczenia wynika, że trudno coś ciekawego z takich liczb wywnioskować, bo łatwo można wpłynąć na takie akurat dane. A DORA i te 4 metryki wydawały się być takim bardzo prostym, o niskim progu wejścia sposobem, żeby już coś zobaczyć i coś zmienić. Więc też nie powiedzieliśmy sobie, że to jest nasz cel i na tym poprzestajemy. Tak jak mówię, teraz zainteresowaliśmy się też SLI, próbujemy określić SLA, czyli ten poziom, który powinna każda aplikacja osiągnąć ze swoim SLI. Tak że dalej odkrywamy. Są też inne metryki DevOps, które mają ciekawe akronimy, Space, DevEx i tym podobne. One tym się różnią, że jeszcze uwzględniają czynnik ludzki w jakiś sposób, to co mówiłam, czy ta radość z kodzenia, czy subiektywne odczucie programisty, że w sumie żyje mu się dosyć łatwo w firmie i nikomu bardzo nie przeszkadza w tworzeniu oprogramowania. I to jest taki element, który staraliśmy się np., wdrażając kolejne zmiany w tej naszej platformie, opiekować ankietą. Taką po prostu ankietą, jak się czasami robi też dla użytkowników, albo często się robi dla użytkowników - na ile oceniasz przydatność? Na ile byś polecił? Tutaj też można różne metodyki badań dobrać. Więc to badaliśmy tak punktowo. Staramy się też po prostu rozmawiać w firmie, to jest też całkiem niezły sposób, żeby wyczuć czy jest w porządku czy nie.

Łukasz Kałużny: Słuchaj, ja wezmę, bo jest to publiczne, trzeba też powiedzieć, jaką macie częstotliwość deploymentu uśrednioną, bo na InfoShare akurat to pokazałaś. Czyli w zależności od miesiąca, ale ponad 300 deploymentów miesięcznie i dzienne wdrażanie.

Kinga Gaździńska Tak, deploymenty miesięcznie to chyba na jedno tylko środowisko, bo wydaje mi się, że tam było…

Łukasz Kałużny: Tak, ja mówię o jednym tak, tak, tak, bo jak byśmy… Dlatego trochę biorę, że to wspólne aplikacje i inne rzeczy, bo tak to wychodzi pomiędzy 700 a 1000, jak zliczymy obydwa DC, które pokazałaś na slajdzie. Więc naprawdę niezły wynik patrząc się na całość.

Kinga Gaździńska To jest też konsekwencja architektury mikroserwisowej, w której działamy, więc jest naturalne, że tych wdrożeń jest po prostu sporo

Łukasz Kałużny: I wdrożenie od pull requesta jest takie, bo patrzę ile zajmuje average, ten lead time, który u Was jest zdefiniowany po akceptacji, to 6 dni na proda z testami jest niezłym wynikiem.

Kinga Gaździńska Niezłym, natomiast to jest akurat ta wartość, której byśmy chcieli jeszcze.

Łukasz Kałużny: Ją skrócić. Bo pewnie automatyzacja testów i innych rzeczy pozwolą to skrócić Nieźle.

Kinga Gaździńska Tak, tak, tak, mamy częściowo testy zautomatyzowane, mamy też testy UI-a automatyczne, więc też staramy się z każdą taką metryką zrozumieć, co wpływa na nią i np. czy właśnie wdrożenie jeszcze feature flag by tej wartości nie skróciło, bo zespoły mogłyby wdrażać i ktoś tylko mógłby przełączyć potem flagę. Te zmiany nie musiałyby czekać gdzieś kilka dni na coś, na jakiś znak.

Szymon Warda: Ok, słuchając tego odcinka mocno zachęciłaś i faktycznie pokazałaś wartość. A ja takie pytanie praktyczne na zakończenie. Załóżmy, że ktoś posłuchał, stwierdza ok, chcę w to wejść, chcę spróbować. To jakieś rady dla takich osób? Od czego zacząć? Co zrobić w ogóle? Co byś powiedziała?

Kinga Gaździńska Myślę, że zacząć od wejścia na stronę DORA, to jest Dora.de zdaje się i przejścia przez tą krótką, czterokrokową ankietę. Potem jeszcze są 3 pytania, trochę bardziej doszczegóławiające, gdzie można już bardzo konkretne. To się nazywa w ich nomenklaturze gape abilities wydaje mi się. Bardzo konkretne obszary do umiejętności sobie ocenić, na ile je stosujemy w organizacji czy w zespole. I następnie zostajemy przekierowani na całą ścianę kilkunastu, kilkudziesięciu artykułów. Każdy z nich naprawdę rzetelnie opowiada o tych capabilities. Tak jak mówiłam na prezentacji na konferencji, w moim mniemaniu to jest rzetelnie ustrukturyzowana taka wiedza busworldów, które od lat przewijają się na konferencjach. Słyszymy o Continuous Deployment, idziemy tam, patrzymy, jest artykuł Continuous Deployment. Pierwsze akapity mówią dlaczego warto to mieć. Kolejne akapity mówią o tym, jak do tego dojść. I to samo jest dla Database Change Management np. To jest akurat publity, która też tutaj, ten nasz konsultant z Googla, który opowiadał nam o DORA trochę bardziej od kuchni, wspominał, że w Polsce jest najczęściej nieposiadaną przez firmę umiejętnością. Więc też można pójść zobaczyć dlaczego warto mieć i wdrażać. To jest, myślę, takie najlepsze miejsce startu. Ewentualnie dla osób, które lubią czytać książka “Accelerate”.

Szymon Warda: Czyli ogólnie rzecz biorąc read the documentation, można powiedzieć tak naprawdę po raz kolejny.

Kinga Gaździńska Tak, tylko właśnie mam wrażenie, że ta documentation tutaj to nie jest toga, to nie jest jakiś cały ruch DevOps, gdzie już teraz jak wpisze się DevOps w przeglądarkę to nie wiadomo gdzie spojrzeć nawet, jest tyle wyników wyszukiwania. Więc to taki dosyć przyjemny i można zacząć małymi krokami.

Szymon Warda: Dobrze, to w takim razie kończymy. Dziękujemy pięknie!

Łukasz Kałużny: Dzięki za podzielenie się wiedzą i doświadczeniem.

Kinga Gaździńska Bardzo miło mi było z Wami dzisiaj rozmawiać. Dziękuję.

Szymon Warda: Dzięki.

Łukasz Kałużny: Na razie.

Kinga Gaździńska Na razie, cześć.