Observability dla managera: skąd wiedzieć, że biznes działa

Część rzeczy w komunikacji między systemami można mierzyć także w API Management, na dużo wyższym poziomie.

Wpływa na retencję pracowników, bo po prostu lepiej się pracuje. Praca od awarii do awarii to nie jest dobre zarządzanie systemami ani czasem zespołu.

Kwartał od wdrożenia to już inna organizacja, która myśli przyszłościowo. Zmiana bierze się z wyjścia z trybu strażaka i ze standaryzacji procesów wytwórczych.

Szymon Warda: Mając liczby, konkretne zachowania i wiedzę, dla ilu osób system działa wolno — bo zawsze będzie działał wolno, nie oszukujmy się — wiemy jedno: nie wszystkie systemy opłaca się optymalizować do granicy możliwości. Można powiedzieć: zgadza się, system działa wolno, ale dla 2% użytkowników. Jeśli zespół jest w trybie strażaka, musi działać tu i teraz, szybko, żeby działało. Zwykle kosztem jakości. A jeśli cierpi jakość, problem będzie powtarzalny: nie naprawiamy go poprawnie, tylko łatamy tu i teraz, a potem nie mamy czasu, żeby zrobić to dobrze. I to się powtórzy. Przejście na observability daje nam to, że wyprzedzamy problemy. Inwestujemy nie tylko w procesy gaszenia, ale w procesy utrzymaniowe, patrzące do przodu. Mamy więcej zaplanowanego czasu, a awarii jest po prostu mniej.

Mikołaj Szczerbicki: Cześć! Witamy w Powered by Protopia. Jestem Mikołaj Szczerbicki, a dzisiaj jest ze mną Szymon Warda, który w jednym z poprzednich odcinków zapowiedział, że poruszymy temat observability.

Szymon Warda: A co my powiemy, to się ziści.

Mikołaj Szczerbicki: Dokładnie. Szymon, na początku chciałbym postawić się w roli managera, dla którego kluczowe pytanie w ocenie systemu brzmi: czy mój biznes działa, czy nie? Wydaje mi się, że większość słuchaczy powie: dobrze, ale moja infrastruktura jest już monitorowana, więc po co mam słuchać dzisiejszego odcinka? Przekonaj mnie, że warto.

Szymon Warda: Słuchaj, Mikołaj, nieraz widziałem, że każdy twierdzi, że ma jakiś monitoring czy observability. Różnicę jeszcze wyjaśnimy, ale prawie zawsze widziałem taką sytuację: jako manager dostajesz telefon od biznesu, często dość gniewny. Czemu system nie działa od pół godziny? Idziesz do zespołu utrzymania, adminów, DevOpsów, jakkolwiek ich nazwiemy, i pytasz: co się dzieje? A oni: jak to? Widzimy, że wszystko działa. Procesor i RAM są w porządku, to chyba system działa. Jak się czujesz w takiej sytuacji? Bo taką sytuację miałeś albo będziesz miał, i to pewnie prędzej niż później.

Mikołaj Szczerbicki: Myślę, że w tym momencie komuś zaczyna się palić pod stopami.

Szymon Warda: Albo przychodzą flashbacki, kiedy to ostatnio wystąpiło, bo wystąpiło na pewno. Przejdźmy więc do tego, czym różni się monitoring od observability. Monitoring to patrzenie na system z punktu widzenia tego, czy pamięć, procesor, może jeszcze dysk są pełne. Czy to jest w porządku.

Mikołaj Szczerbicki: Czyli poczekaj, observability to nie jest tylko modna nazwa dla tego samego?

Szymon Warda: Nie, to jest coś zupełnie innego. Observability to obserwowalność, czyli właściwie cel, który chcemy osiągnąć: z danych, które mamy, jesteśmy w stanie wywnioskować, jak system się zachowuje i czy jest dobrze. Patrząc na liczby, możemy powiedzieć, co tak naprawdę dzieje się w jego wnętrzu. Będziemy jeszcze mówili, że to nie tylko systemy, ale też procesy. To cała droga, która musi się gdzieś zacząć. Finalnie widzimy, że coś się dzieje, a nawet więcej: widzimy to, zanim zacznie się dziać. Przechodzimy od reaktywności do proaktywności w tym, jak obserwujemy nasze systemy.

Mikołaj Szczerbicki: Dobrze, rozumiem już różnicę między monitoringiem a observability. Jak wspomniałeś, mamy administratorów, developerów, opsów, zespoły SRE. Każdy z nich pracuje na swoim kawałku systemu, każdy patrzy w swoje i każdy mówi, że jest dobrze. Jak możemy to usprawnić?

Szymon Warda: A wiesz, co jest najlepsze? Jest awaria, siada DevOps z developerem tego systemu, każdy ze swoimi zabawkami, i zaczyna się „moje, twoje”. Nie są w stanie się dogadać. Każdy z tych zespołów ma swoje systemy. Spójrzmy na to z Twojego punktu widzenia: za to trzeba zapłacić, ludzie muszą się tych narzędzi nauczyć, trzeba je utrzymać. To dodatkowe koszty, które organizacja ponosi, bo ma bałagan: nic nie jest zunifikowane ani scentralizowane, a podczas awarii jedni ją widzą, a drudzy mogą jej nie widzieć. Co więcej, zespoły developerskie w ostatnich latach mocno przyzwyczaiły się do tego, że chcą mieć widoczność. Nie tylko lokalny debugger, ale to, jak system zachowuje się naprawdę. Chcą mieć liczby. Skoro mają swoje narzędzia, same je utrzymują, czyli tracą czas.

Szymon Warda: Proces wytwarzania oprogramowania znowu zwalnia, proces wdrażania znowu zwalnia, bo dochodzą kolejne zabawki, przy których tracimy czas. My idziemy w kierunku: scentralizujmy to i dajmy narzędzia aktualne, zgodne z najnowszym trendem, które faktycznie przynoszą wartość. Kiedy to zunifikujemy, będziemy mogli komunikować się tymi samymi liczbami w wielu departamentach: wytwarzania, utrzymania, monitorowania i tak dalej. Mamy te same liczby, więc możemy mówić liczbami. Mało kto będzie dyskutował, że są inne niż te, które raportujemy, bo to my je zbieramy.

Mikołaj Szczerbicki: Dobrze. Monitoring informuje nas o awarii albo…

Szymon Warda: Jak się uda.

Mikołaj Szczerbicki: …ostrzega przed awarią. Ale mówimy tylko o straszeniu, o złych scenariuszach. Czy są jeszcze inne obszary, w których observability nam pomoże?

Szymon Warda: Bardzo się cieszę, że wychodzisz poza reakcję na awarię. Co jeszcze możemy zrobić? Bardzo dużo. Wspomniałem, że będziemy mieli liczby, a liczby są krytyczne w kilku scenariuszach. W każdej dużej organizacji, w dowolnym systemie, ktoś będzie narzekał, że coś działa wolno. Mając liczby, konkretne zachowania i wiedzę, dla ilu osób działa wolno — bo zawsze będzie działał wolno, nie oszukujmy się — wiemy, że nie wszystkie systemy opłaca się optymalizować do granicy możliwości. Można powiedzieć: zgadza się, system działa wolno, tylko dla 2% użytkowników. Zadajmy sobie pytanie, czy warto wydawać pieniądze, żeby to jeszcze poprawić.

Mikołaj Szczerbicki: Rozumiem, że mówimy o konkretnych przypadkach, które widziałeś.

Szymon Warda: Tak, dokładnie. Dobry stan observability pozwala nam mówić nie o uczuciach, tylko o tym, co się dzieje. W dowolnej sytuacji mówimy: to są liczby, to są nasze dashboardy. Czemu są wartościowe, a czemu czasem śmieszne, jeszcze powiemy. Ale układamy wszystko w liczby.

Mikołaj Szczerbicki: Czyli jako manager biznesowy dostaję oręż, którego mogę używać w dialogu z każdym zespołem.

Szymon Warda: Tak. I to nie tylko w tym dialogu. Częsta sytuacja: infrastruktura, chmurowa czy na Kubernetesie, jest przeskalowana w górę. Przychodzi nowy system i słyszymy, że potrzebuje 20 CPU i 100 GB RAM-u, a potem okazuje się, że korzystamy z 50% tego. Maszynom daje się za dużo zasobów. Mając wykresy, mówimy: w ciągu miesiąca procesor realnie nie przekracza pewnej wartości, podobnie pamięć i dysk. Użyjmy mniejszych maszyn. To bardzo duże oszczędności na infrastrukturze, a im więcej jej mamy, tym łatwiej je osiągnąć.

Mikołaj Szczerbicki: Wspomniałeś o Kubernetesie. Mówiliśmy chwilę o kwestiach biznesowych, wejdźmy teraz głębiej w technikę. Na rynku jest dużo rozwiązań i dużo vendorów, którzy mówią, że ich rozwiązanie jest świetne i zawsze Ci pomoże. Po co więc observability jako całość, a nie konkretne rozwiązanie konkretnego vendora?

Szymon Warda: Zanim do tego przejdziemy, jeszcze jeden kluczowy element wartości: przejście z reaktywności na proaktywność. Jeśli Twój zespół — a to pewnie brzmi znajomo dla większości managerów — jest reaktywny, czyli reaguje na awarie, które już się wydarzyły, to jest w trybie strażaka. Musi działać tu i teraz, szybko, żeby działało. Zwykle kosztem jakości. A jeśli cierpi jakość, problem będzie powtarzalny: nie naprawiamy go poprawnie, tylko łatamy tu i teraz, a potem nie mamy czasu, żeby zrobić to dobrze. I to się powtórzy.

Mikołaj Szczerbicki: Czyli gaszenie od pożaru do pożaru.

Szymon Warda: Od pożaru do pożaru. A wtedy nie jesteś w stanie niczego zaplanować. Mówimy, że w tym kwartale coś zrobimy, kwartał mija, a my nawet tego nie ruszyliśmy. Czemu? Bo cały czas biegaliśmy z wiaderkiem i z taczkami, które często były puste. Robiliśmy dużo, ale nie były to wartościowe rzeczy, tylko reakcja na to, co tu i teraz. Przejście na observability daje nam to, że wyprzedzamy problemy. Inwestujemy nie tylko w procesy gaszenia, ale w procesy utrzymaniowe, patrzące do przodu. Mamy więcej zaplanowanego czasu, a awarii jest po prostu mniej. Mamy czas, żeby zadbać o infrastrukturę i powiedzieć zespołowi developerskiemu: to działa wolno, tu coś źle wykorzystujecie, tu wydajność aplikacji jest zła. Mamy widoczność i możemy szybko powiedzieć, co zrobić, żeby było lepiej, a nie tylko żeby przeżyć kolejny dzień.

Szymon Warda: To oczywiście przekłada się też na retencję pracowników. Po prostu życie jest lepsze. Ale wracając do pytania…

Mikołaj Szczerbicki: Jeśli wejdziemy trochę głębiej: czym technicznie jest observability? Z czego się składa?

Szymon Warda: Słuchaj, mówi się o trzech filarach: metrykach, logach i trace'ach. Nazywam je stopniami dojrzałości. Logi ma każdy, lepsze lub gorsze. Czasem widzimy w organizacjach, jak developerzy wchodzą na maszyny i przeglądają logi jak biegające cyferki w Matriksie: o, tu jest błąd. Podziwiam umiejętności, ale w większej skali niekoniecznie są przydatne. Potem metryki, czyli realne liczby, które zbieramy. Możemy ich zbierać naprawdę dużo. I trace'y, które mówią nam, jak cały proces zachowuje się w sensie biznesowym, gdy przepływa przez wszystkie serwisy i mikroserwisy w organizacji. Dzięki nim wiemy, co jak się zachowuje, a co więcej: gdzie warto inwestować czas w optymalizację, która komunikacja działa, a która nie, jaką ma latencję, gdzie się wywala i jaki jest rozkład czasu odpowiedzi. To bardzo ważny element całego Kubernetesa. Czemu o tym mówimy? Żeby dać liczby.

Szymon Warda: Liczby są fajne, bardzo lubię liczby. System od vendorów, o których wspomniałeś, to dla średniego zespołu 5–6 cyferek w dolarach rocznie. To brzmi jak dość znaczący koszt.

Mikołaj Szczerbicki: Zależy od wielkości organizacji, ale myślę, że ten rząd wielkości robi na każdym wrażenie.

Szymon Warda: Słuchaj, z naszego doświadczenia: ostatnio rozmawialiśmy z dużym klientem z sektora finansowego — mówię ogólnie, bo nie możemy zdradzać szczegółów. Pokazaliśmy mu możliwości platformy, którą promujemy, bo uznaliśmy, że ma sens. Teraz rozważa wycofanie się od jednego z wielkich dostawców, ponieważ jego rachunek to już nie 6 cyferek, tylko 7 i 8 cyferek w dolarach rocznie. Ucięcie takiego kosztu to sukces, którym każdy może zabłysnąć, powiedzmy sobie szczerze. Kilka lat temu były też publikacje, z których wynikało, że organizacje płaciły 15 i 50 milionów dolarów rocznie za systemy observability. To znaczące koszty, które każda organizacja zauważy. A czemu w ogóle o tym mówimy? Z bardzo prostego powodu. Wspomniałeś o Kubernetesie. Mówimy o platformie opartej na stosie Grafany, która integruje się z nim natywnie. Jeśli pójdziesz do zespołu developerskiego i powiesz, że będziecie mieli tę platformę, usłyszysz…

Szymon Warda: …przybij piątkę, znamy to. Jeśli pójdziesz do zespołu SRE, będą wiedzieli, o jaki system chodzi, bo z niego korzystają. Gwarantuję Ci, że jak poszukasz, znajdziesz go w organizacji. Tylko pewnie gorzej utrzymany, nie do końca ogarnięty i niewdrożony procesowo. To systemy, które są standardem rynkowym: od Kubernetesa po gigantów chmurowych, hyperskalerów, o których wspominał Łukasz.

Mikołaj Szczerbicki: Czyli observability na rozwiązaniach open source daje radę Twoim zdaniem?

Szymon Warda: Daje radę, a nawet więcej niż daje radę. Korzystają z tego hyperskalerzy, a Kubernetes integruje się z tym natywnie. To droga, którą należy iść. Wiadomo, ma to swoje kłopoty. Ale nie jest też tak, że pójdziemy do vendora, zapłacimy i wszystko będzie działać. Mieliśmy przypadek u klienta, który włączył takie observability na swoim klastrze i cały system się złożył. Wszystko przestało działać. Okazało się, że automatyczne observability w tym bardzo znanym rozwiązaniu wpinało się w miejsce, w które nie powinno, i system momentalnie przestał działać. Dojście do przyczyny zajęło dwa dni. Słaby scenariusz, ale tak często działają magiczne rozwiązania, które obiecują za dużo, a potem nie dowożą, bo nie mogą.

Mikołaj Szczerbicki: Wracając do tego, od czego zacząłem: z punktu widzenia managera najważniejsze jest dla mnie, żeby biznes działał.

Szymon Warda: Żeby działał przewidywalnie. A przewidywalnie to nie znaczy, że podbijasz wersję systemu do monitorowania i nagle Twojego biznesu nie ma przez cały dzień, a nikt nie wie czemu. Obiecanki są różne i przy takich kwotach każdy obieca bardzo dużo. My mówimy prosto: będzie to wymagało części pracy po stronie aplikacji i pewnych zmian. Tych zmian jest coraz mniej. Im więcej pracy wykonamy, tym więcej wartości dostaniemy. Trzeba wejść w aplikację, żeby złapać kontekst, ale to się opłaca długofalowo. Magia u vendorów, którzy biorą za to wielkie pieniądze, polega na tym, że mówią: wszystko będzie działało. No nie do końca. Doskonale wiemy, że wdrożenie każdego systemu kosztuje. Nasza propozycja jest taka: zróbmy to raz, a dobrze. Czemu raz? Bo na rynku są standardy takie jak OpenTelemetry, które zawładnęły światem observability. Stały się standardem. Co więcej, duzi vendorzy korzystają z tego standardu, żeby integrować się z aplikacjami.

Szymon Warda: To już dużo mówi. Możemy wejść w rozwiązania open source, które nie dość, że świetnie się skalują i są opłacalne kosztowo, to jeszcze łatwo je utrzymać. Tę trójkę bardzo miło usłyszeć, a możemy z nią zrobić bardzo dużo.

Mikołaj Szczerbicki: Kiedy tego słucham, widzę przede wszystkim, że observability to nie tylko dashboardy ze wszystkich systemów, które pokazują piękne wykresy i mnóstwo wartości, błyszczą się i migają wszystkimi kolorami. Poza samą platformą to także zmiana nawyków organizacji, tak?

Szymon Warda: Słuchaj, dotknąłeś dwóch bardzo ważnych tematów. Zawsze śmieję się, kiedy wchodzę do organizacji — a widzieliśmy już niejedno — i widzę cztery, pięć, sześć albo więcej monitorów z ładnymi wykresami. Wtedy wiem, że to choinka, która ładnie wygląda na pokaz, a nikt z niej nie korzysta. Czemu? Bo jak wykres spada, jest już po fakcie. My mówimy inaczej: chodzi o bycie proaktywnym. Mamy alerty, możemy powiadomić, że coś wydarzy się za dzień, za dwa, za jakiś czas. Wokół techniki budujemy procesy, dzięki którym organizm organizacji działa lepiej. Nie będę się oszukiwał: samą techniką nie rozwiążemy tematów miękkich. Dlatego kiedy doradzamy klientom, technika to jedno, czyli dajemy możliwości realizowania procesów. Potem mówimy: macie możliwości, korzystajcie z nich. Teraz wdrażamy alerting, teraz wykrywamy anomalie, czyli widzimy, że coś zaczyna się chyba psuć.

Szymon Warda: Może się temu przyjrzyjmy. To nie jest tak, że masz jedną metrykę. Systemy produkują czasem dziesiątki tysięcy różnych metryk, więc trzeba umieć odsiać. Inaczej to próba picia z hydrantu: można stracić zęby. My pokazujemy, jak z tego realnie korzystać i co robić dalej. Takie narzędzia umożliwiają też procesy reagowania i bardzo popularny teraz ruch, czyli shift left. Nie jest tak, że zespół utrzymania ma swoje zabawki, a developerzy nie wiedzą, co z tym zrobić. Mówimy developerom: tak Wasz system zachowuje się na produkcji, przyjrzyjcie się, bo to jedno zunifikowane narzędzie, jeden system. Nie ma „works on my machine”, czyli „na mojej maszynie działa”. Mówimy: tak jest na produkcji i nie ma co dyskutować. Mamy liczby, mamy zapytania SQL, które się wykonują, mamy wszystko. I nagle okazuje się, że to wygląda inaczej, więc zróbcie coś z tym. Albo wiemy, że jest dobrze.

Szymon Warda: Nie ma sensu dalej poprawiać wydajności, bo na produkcji działa bardzo dobrze.

Mikołaj Szczerbicki: Wydaje mi się, że to jedna z ważniejszych rzeczy, przynajmniej dla osób, które patrzą z biznesowego punktu widzenia. Rozmawialiśmy kiedyś prywatnie o tym, że poprawianie wszystkich wskaźników na siłę może się po prostu nie opłacać.

Szymon Warda: Tak, dokładnie. Warto inwestować pieniądze tam, gdzie to ma sens i gdzie będzie wartość. Tej wartości nie zmierzymy jednak, dopóki nie będziemy mieli liczb, które powiedzą nam, czy doszliśmy do optymalnego poziomu. Idźmy kawałek dalej. Mówiliśmy o adminach i tak dalej, mamy liczby, możemy coś powiedzieć developerom. A Ciebie interesuje, jak to będzie działało z biznesem. Kiedy mierzymy, możemy ustalić coś krytycznego, czyli wskaźniki SLA, SLO i SLI. Możemy powiedzieć, do jakiego poziomu utrzymania się zobowiązujemy. Rozmawialiśmy z firmami, które mówią, że muszą mieć uptime 100%. Odpowiadamy, że to nierealne. Przy 99,99% mówimy o godzinach. Dodam jeszcze jedną dziewiątkę i mówimy o minutach w skali roku.

Mikołaj Szczerbicki: Zawsze się śmieję, że jak dokładamy kolejną dziewiątkę po przecinku, to w kwocie wydawanych pieniędzy musimy dokładać kolejne zero przed przecinkiem.

Szymon Warda: Czasem nawet więcej, im dalej idziemy.

Mikołaj Szczerbicki: Możemy to zanotować.

Szymon Warda: Tak, dokładnie. Ale ważne jest to, że dajemy jasną świadomość, do czego się zobowiązujemy. Umiemy to zmierzyć i powiedzieć, czy kontrakt wobec biznesu był spełniony, czy nie. Możemy też przełożyć potencjalne awarie albo przerwy utrzymaniowe na realne finanse organizacji. Czasem wyjdzie, że niektóre systemy mogą nie działać w pewnym przedziale czasu, bo nie ma z tym problemu, a inne są bardziej krytyczne. Nagle mamy dyskusję opartą na liczbach. Co dalej? Mówimy nie tylko o biznesie. Usuwamy też tarcia między developerami: ten system nie działa, bo tamten, bo my nie możemy, bo tamten nie działa. Mówimy: dobrze, zmierzmy to w ramach systemów, które się ze sobą komunikują. Rozmawialiśmy z Markiem o API Management, prawda? Tam też możemy mierzyć pewne rzeczy na dużo wyższym poziomie.

Mikołaj Szczerbicki: Czyli dzięki temu różne zespoły mogą rozmawiać jednym językiem.

Szymon Warda: Tak. Zespół mówi: zobowiązujemy się, że nasz system będzie działał w takim SLA, niezależnie od innych systemów. Nasz proces developmentu przestaje być narzekaniem, że komuś coś nie działa. Mówimy: takie było zobowiązanie, na to się zgadzamy, a organizacja mówi, że to jest w porządku. To kolejne kroki. Co więcej, tworzymy pętlę zwrotną. Developerzy wdrażają nową wersję i nie dowiadują się za kwartał, że coś działa albo nie działa, albo działa wolno. Mówimy: wdrożyliście wersję, a dzień później widzicie, jak się zachowuje. Jest dobrze albo niedobrze. Możemy też wdrożyć częściowo i patrzeć, jak zachowuje się ruch. W systemach krytycznych, tam gdzie ma to sens, bo nie oszukujmy się: nie wszędzie będziemy robili takie rozbudowane wdrożenia, bo to się nie opłaca. Ale gdzieniegdzie ma to wartość.

Szymon Warda: Mierząc, możemy powiedzieć, czy nowsza wersja jest gorsza, czy lepsza. Dzięki temu czas wykrycia regresji jest dużo, dużo krótszy. Dokładnie wiemy, co się wydarzyło.

Mikołaj Szczerbicki: Nasuwa mi się jeszcze jedno pytanie: w którym momencie organizacja musi na nie odpowiedzieć? Czy zanim zdecydujemy się zbudować całą platformę i wdrożyć nowe procedury i zasady, musimy wiedzieć, co i w jaki sposób chcemy monitorować, ustalić to i dopiero od tego punktu wszystko budować? Czy odwrotnie: najpierw sprawdzamy, co możemy zobaczyć, a na końcu mówimy, że wyznaczamy standardy i od teraz będziemy je stosować?

Szymon Warda: Słuchaj, jest takie fajne zdanie Tołstoja: wszystkie udane małżeństwa są do siebie podobne, a wszystkie nieudane są unikalne. Możemy wymyślać koło na nowo i mówić, że u nas będzie inaczej. Ale są standardy i dobre praktyki, które są uniwersalne i które trzeba wdrożyć. Narzędzia, które proponujemy, dają pewne możliwości, a na bazie tych możliwości muszą wejść dobre praktyki. One są uniwersalne. Oczywiście każda organizacja jest w pewnym stopniu inna i to kwestia dostosowania. Nie powiedzieliśmy jeszcze, że przy takiej platformie może działać zespół platformowy, który w tle wdraża kolejne elementy, żeby żyło się lepiej. Wdrażamy standardy: jak logujemy, jakie metryki zbieramy, jakie poziomy błędów raportujemy, co tak naprawdę jest w logach. Pamiętamy, jak wchodziło RODO i trzeba było magicznie usuwać z logów imiona, nazwiska i dane identyfikujące użytkowników. Ile było z tym roboty! To był jednorazowy strzał, a teraz mówimy: standaryzujemy to i wiemy, jak się zachowujemy.

Szymon Warda: Nagle nie chodzi tylko o to, że systemy do monitorowania i observability zachowują się lepiej. Developerzy nie muszą o tym myśleć. Mówią: robimy nowy system, musi mieć takie elementy, korzystamy z takich bibliotek, tak raportujemy. I co? Ten kawałek tortu, który jest kosztowny przy wytwarzaniu systemu, odchodzi. Wiedzą, że to nasz standard, a nawet standard ogólnorynkowy, aktualny, i wiemy, jak go wdrożyć. Co więcej, możemy zrobić przelotki, żeby zbierać dane także z systemów legacy. Nowe systemy, stare, te w trakcie developmentu i zewnętrzne możemy zbierać w jedną rurę i raportować w zunifikowany sposób. Nie jest tak, że ten system widzimy w jednym narzędziu, tamten w innym, a każdy ma inny kawałek tortu. Mamy spojrzenie na całą organizację i dokładnie wiemy, co, gdzie i jak się zachowuje. To bardzo potężny mechanizm, który daje całościowy obraz, zamiast pytania po kawałku różnych działów.

Mikołaj Szczerbicki: Jeśli dobrze zrozumiałem wszystko, co powiedziałeś, observability naprawdę mi się podoba, bo jest bardzo kompleksowe. Daje organizacji dużo więcej niż zbiór narzędzi: całą kulturę pracy z nimi, a z nią spokój, bezpieczeństwo i unifikację. Nie tylko dashboardy i alerting po fakcie, ale dużo lepszą obserwowalność.

Szymon Warda: Tak. Stajemy się proaktywni w każdym obszarze: nie tylko w zespole platformowym, nie tylko u developerów, nie tylko wobec biznesu. Wszystko całościowo. To daje bardzo duże możliwości i jest punktem wyjścia do dalszej iteracji. Ponieważ nie opieramy się na zamkniętym narzędziu, korzystamy z ogromnej wiedzy użytkowników całego ekosystemu. Dobre praktyki możemy czasem po prostu wdrożyć dzięki zewnętrznym komponentom, które ktoś rozwija. To bardzo potężne. To punkt konieczny, żeby budować dalej. Oczywiście nie rozwiąże wszystkich problemów. W przyszłym odcinku będziemy mówili o bardzo wyspecjalizowanych problemach i narzędziach, które pomagają jako ostatnia deska ratunku. Kiedy nie mamy się już czego złapać, włączamy je i, jak mówi młodzież, kopara opada.

Mikołaj Szczerbicki: Nie wiem, czy chcesz już dzisiaj zdradzić, jaki to będzie temat.

Szymon Warda: Potrzymam w napięciu. Będziemy mówili o bardzo wielu rzeczach. Observability daje spokój i porządek w obszarze, o którym zwykle nie chcemy myśleć, i sprawia, że nie żyjemy od awarii do awarii. Takie życie to nie jest dobre zarządzanie ani systemami, ani czasem pracowników.

Mikołaj Szczerbicki: Szymon, zrób na koniec naprawdę krótkie podsumowanie observability.

Szymon Warda: Dobrze. Gdzie jest tak naprawdę jego wartość? Bo o to pytasz?

Mikołaj Szczerbicki: Tak, o wartość biznesową.

Szymon Warda: Jego wartość polega na tym, że wychodzimy z trybu strażaka, czyli możemy planować czas. Wiemy, że awaria się wydarzy, i to my możemy zadzwonić do biznesu i powiedzieć: coś się dzieje z systemem, pracujemy nad tym. Wyobraź sobie, jak zupełnie inna to rozmowa. Nawet jeśli awaria będzie poważna, a może się tak zdarzyć, to my dzwonimy i informujemy. To zupełnie inna sytuacja. Druga wartość to standaryzacja wokół procesów wytwórczych: tego, jak wytwarzamy, naszych procesów i zachowań wokół systemu. Budujemy wartość z każdym dniem, a nie tylko spalamy czas na bieżące sprawy. Dla mnie to ogromne rzeczy, bo kwartał po wdrożeniu jesteśmy tak naprawdę inną organizacją. Taką, która myśli przyszłościowo, a nie próbuje przeżyć tu i teraz, obecny dzień, i wypala się nie wiadomo jak.

Mikołaj Szczerbicki: Szymon, bardzo Ci dziękuję. Mam wrażenie, że nie tylko dla mnie, ale dla wielu naszych słuchaczy to będzie bardzo pouczające i temat observability trochę im się rozjaśni. Tak jak w przypadku agentów AI, o których rozmawiałem z Łukaszem w jednym z poprzednich odcinków, to nie jest tylko modne słowo, ale coś, co w wielu organizacjach będzie dużym game changerem.

Szymon Warda: Wydaje mi się, że tak, i nieraz widzieliśmy to u klientów. Słuchajcie…

Mikołaj Szczerbicki: Dzięki wielkie. Pozdrawiamy, cześć!

Szymon Warda: Na razie, hej!