Observability, w oparciu o miary techniczne, pokazuje wpływ na biznes

Z przedstawicielami BSH, Omnilogy, PKO Banku Polskiego i Raiffeisen Bank International rozmawialiśmy o tym: jak zwiększyć tempo osiągania wartości biznesowej z nowych produktów i aplikacji; jak ocenić, czy dostarczona wartość biznesowa jest wystarczająca; jak narzędzia wspierające pomagają zespołom DevOps zbierać, korelować i analizować ogromne ilości danych o wydajności aplikacji i uzyskać wgląd w ich funkcjonowanie w czasie rzeczywistym; a także zastosowaniach obserwowalność w kontekście narzędzi programistycznych i metodologii prowadzenia projektów.

MONITORING VS OBSERVABILITY, DEVOPS VS SITE RELIABILITY ENGINEERING

Chciałbym zaproponować, abyśmy – jak to utarło się w naszych debatach – w pierwszej kolejności odpowiedzieli na pytanie jaki jest status i doświadczenia rozwoju DevOps oraz obserwowalności w Waszej organizacji?

Renata Jaroszyńska, dyrektor Biura Platformy Bankowości Elektronicznej, PKO BP (R.J.): Jeżeli chodzi o monitoring i obserwowalność, to w banku – zwłaszcza w kanałach elektronicznych platform mobilnych – tego typu rozwiązań jest bardzo dużo i są to dojrzałe rozwiązania. Z kolei w kontekście DevOps jesteśmy w trakcie transformacji. Idziemy w kierunku zespołów produktowych. Mamy doświadczenia w tym obszarze, ale cała organizacja jeszcze w takim modelu nie pracuje. Coraz bardziej jednak zacieśniamy więzy między biznesem a IT, bo widzimy jakie przynosi to zyski.

Marek Łada, Head of Software Engineering, BSH (M.Ł.): Odpowiadam za całość Software Engineeringu w Grupie BSH w Polsce oraz globalnie jednocześnie kieruję jednym z zespołów, aktualnie największym o nazwie Java PoD. Polska jest to jeden z czterech, globalnych hubów w BSH. Mój zespół tworzy rozwiązania IoT stosowanych w urządzeniach domowych takich, jak ekspresy do kawy, pralki, lodówki czy odkurzacze autonomiczne firm Bosch i Siemens. Odpowiadamy też za wewnętrzne projekty digitalizacji, m.in. automatyzację procesów fabrycznych. W BSH mamy jedynie wyspy DevOps’owe, aczkolwiek bardzo istotne. Przy czym odnosimy silne wrażenie, że sam DevOps jest niewystarczający. Bardzo mocno idziemy więc w kierunku Site Reliability Engineering, które jest również ciekawym tematem z punktu widzenia obserwowalności.

Marek Walczak, Dynatrace Country Sales Manager, Omnilogy (M.W.): Odpowiadam w Omnilogy za polski rynek wdrożeń Dynatrace, trochę ewangelizację rynek i pomagam klientom w podejmowaniu właściwych decyzji. Mamy – w zakresie observability – najlepszy produkt na rynku. W Polsce korzysta z niego kilkudziesięciu klientów, w tym większość banków, operatorzy, firmy z sektora ubezpieczeń, e-commerce i publicznego.

Michał Olszewski, Solution Architect, Omnilogy (M.O.): Ja najczęściej noszę dwa kapelusze. Pierwszego bardzo nie lubię, bo ma napis konsultant. Wolę być nazywany architektem, ponieważ faktycznie realizuję wdrożenia u klientów. Trzeba pamiętać, że DevOps to nie gotowy template, to coś, co trzeba dostosować do kultury, a nawet mentalności danej organizacji. I to właśnie od wielu lat robię.

Krzysztof Stumpf, Head of IT Delivery Stream, MIT Group Delivery Center Poland, Raiffeisen Bank International (K.S.): Reprezentuję polskie Delivery Center dla Grupy Raiffeisen Bank. Odpowiadam za jeden ze streamów obejmujący obszar cloud computing, Big Data i integracji. U nas temat observability i DevOps jest adresowany przez tzw. platformy. Jako Grupa działamy głównie w chmurze AWS. Wszystkie produkty, które tworzymy działają więc w pewnych setupach platformowych, w tym obejmujących skrojony na miarę dla nas DevOps. Zachowujemy jednak balans pomiędzy podejściem platformowym a produktowym.

Czy istnieje presja na zwiększanie szybkości w jakiej osiąga się dziś wartość biznesową z powstających systemów IT? Czy jest to odczuwalne? Czy to nadrzędny temat do rozmowy, do której jesteście zapraszani przez biznes?

M.Ł.: Do pewnego stopnia tak. W BSH, część digitalowa i IT pracują w formacie Scaled Agile Framework. Jest to bardzo agile’owe podejście, gdzie temat Minimum Viable Product pojawia się bardzo często. Założenie jest proste, jeżeli rozpoczynamy nowy projekt, to trzeba jakąś wartość dostarczyć. Presja i kultura pracy są takie, by szybko osiągać rezultaty. Największą zaletą podejścia agile’owego jest zaś właśnie to, że relatywnie szybko mamy coś, co nadaje się do użycia.

R.J.: W taki sam sposób pracuje PKO Bank Polski. Jest to ścisła współpraca między biznesem a IT. Celem jest szybkie dostarczanie wartości dla klientów. Śledzimy, czego potrzebują i staramy się na bieżąco odpowiadać na te potrzeby. Równolegle analizujemy, co się dzieje w naszych systemach. Tam, gdzie trzeba wprowadzać zmiany technologiczne – wynikające z rozwoju, wykorzystania infrastruktury i aplikacji – to na bieżąco poprawiamy i udoskonalamy nasze rozwiązania. Wprowadziliśmy też metodykę agile, tryb pracy małych zespołów, które dobrze się rozumieją i mocno czują odpowiedzialność za produkt. To wszystko sprawia, że widoczne są regularne przyrosty.

PRZEJŚCIE OD DEVOPS DO BIZSECDEVOPS

Pytam tutaj też o oczekiwania drugiej strony – biznesu. Czy ma poczucie, że jest jakiś margines optymalizacji kiedy przerzucają na Was zadanie do realizacji?

M.Ł.: W naszym przypadku z zarządu BSH płynie wyraźny sygnał, że szybkość w nowych funkcjach jest ważna, ale również jakość. A to w zwinnym podejściu jest niekiedy wyzwaniem. Agile nie polega tylko na tym, że szybko biegniemy w jakimś kierunku, ale że robimy to również solidnie.

K.S.: Przy dzisiejszych technologiach Infrastructure as a Code, wykreowanie gotowego środowiska programistycznego z funkcjonalnością observability, CI/CD to de facto utworzenie nowego konta AWS wraz z pewnym specyficznym dla organizacji setupem narzędziowym i sieciowym, w ramach którego deweloper ma wszystko, czego potrzebuje, a Dział Security wie dokładnie jak ten setup wygląda. Mamy wtedy sytuację, gdy od strony technicznej temat MVP jest łatwy do zrealizowania i można się skupić na funkcjonalnościach biznesowych.

M.W.: Mam tezę, którą chciałbym poddać pod dyskusję. Mówimy dzisiaj o DevOps, bo taki jest temat debaty. Wydaje się jednak, że DevOps to zawężenie zagadnienia. Właściwsze wydaje się dzisiaj podejście BizSecDevOps. W tworzeniu i utrzymaniu aplikacji zazwyczaj na jakimś etapie udział mają prawie wszystkie działy firmy. Jeżeli więc musimy zaprząc do pracy nad ich wytworzeniem ludzi o różnych profilach kompetencyjnych, to proces wytwórczy musi to uwzględniać i zapewnić narzędzia do efektywnej współpracy. To samo dotyczy zapewnienia bezawaryjnej i bezpiecznej pracy tych aplikacji na produkcji.

M.Ł.: Wspomniany przez Ciebie element organizacyjny to pionowe podziały. Mamy jednak w organizacjach też podziały poziome w postaci różnych aplikacji, mikroserwisów, systemów multicloud… Nagle okazuje się, że staromodne podejście dotyczące typowego monitorowania nie odpowiada na wiele pytań i nie pozwala uzyskać odpowiedzi.

M.O.: Jeśli chcemy określić i spełnić jakiś cel, to powinien zostać wcześniej zdefiniowany Jeśli tak się stanie, to zarówno część deweloperska, jak i techniczna będą w stanie wykazać, że spełniły założony cel. Jednocześnie biznes będzie w stanie zrozumieć korzyści i wartość biznesową projektu. Jeśli tego nie robimy, to całość nam się rozmywa. Zawsze jedna strona jest niezadowolona, bo coś się dzieje za wolno, albo nie do końca sprawdzają się MVP. Klient zaś zderzy się z czymś, co nie spełnia wszystkich jego oczekiwań. I co wówczas?

R.J.: Mówi się, że pierwsze wrażenie robi się tylko raz. Produkt, który tworzymy musi przynieść wartość biznesową. Jako IT odpowiadamy za to, aby przygotować fundamenty, platformy na których mogą rozwijać się i działać zespoły produktowe. Musimy dostarczyć filary, aby zespoły mogły programować nie martwiąc się o kwestie podstawowe. między innymi obserwowalności czy bezpieczeństwa.

M.W.: Badanie Dynatrace pokazuje, że ponad 50% specjalistów ds. bezpieczeństwa nie ufa deweloperom i prawie tyle samo deweloperów uważa bezpieczeństwo za stopera innowacji. Odpowiedzią Dynatrace na ten problem jest platforma Observability, która pozwala „skleić” Sec z DevOps.

Dane pobierane przez OneAgent Dynatrace pozwalają np. wykrywać w czasie rzeczywistym podatności, określać miejsca ich występowania i dodatkowo oceniać rzeczywisty stan zagrożenia dla każdego wykrytego przypadku. Dotyczy to zarówno produkcji jak i procesu wytwórczego. Dynatrace nie zastąpi wszystkich specjalizowanych narzędzi stosowanych przez departamenty bezpieczeństwa, ale skutecznie włącza bezpieczeństwo w kontekst SecDevOps.

K.S.: Wskazany problem to tylko kwestia rozwiązania organizacyjnego. U nas np. ludzie z CyberSec są w Product Teamach. W tym samym stopniu odpowiadają za dowiezienie produktu, a oprócz tego raportują do CSO.

M.Ł.: Przez wiele lat pracowałem w amerykańskim koncernie Honeywell, który częściowo działa w segmencie zbrojeniowym. Tam bezpieczeństwo było na tak wysokim poziomie, że bez zgody komórki CyberSec właściwie nie można było niczego zrobić. Firma świadomie brała technologie trochę starsze, bo bezpieczeństwo było ważniejsze od szybkości działania, a czasami nawet od kosztów. Teraz pracuję w firmie, gdzie aspekt bezpieczeństwa jest ważny, ale nie jest postawiony aż w takim stopniu na „ostrzu noża”, bo mówimy o systemach gospodarstwa domowego. Oczywiście każda firma ma tajemnice w postaci know-how, ale jest pewna różnica między silnikiem do samolotów wojskowych a ekspresem do kawy.

R.J.: Współpraca bezpieczeństwa z deweloperami jest konieczna. Zanim jeszcze zacznie się praca nad produktem zespół security musi uczestniczyć w tym procesie dając swoje wytyczne. Do tego potrzebne są zmiany mentalne.

M.W.: Mentalne oczywiście tak, ale aby mogła nastąpić zmiana kulturowa musimy dostarczyć odpowiednie wsparcie narzędziowe. Ma to szczególne znaczenie w odpowiednio dużej skali, w której ilość danych i interakcji jest tak duża, że nie da się jej „ogarnąć” przy ekspresie do kawy. Będę bronił tezy, że dobra platforma Observability jest lepszym rozwiązaniem niż sytuacja, w której każdy zespół każdy ma swoje narzędzia i mierzy to co uzna za niezbędne w swoim obszarze. Wielokrotnie widzimy sytuacje, w których IT wszystko „świeci się na zielono”, a klienci nie kończą transakcji.

R.J.: Faktycznie często było tak, że miary IT dotyczyły wydajności, przepływów itd., a nie było miar dotyczących produktów, które przekładają się na zysk biznesowy. Monitoring, który powinien być budowany razem z produktem, powinien obejmować podejście biznesowe.

M.W.: Marek powiedział o SRE. To jest słowo klucz. DevOps to wstęp do świata SRE.

M.Ł.: Mówimy, że SRE to DevOps na sterydach.

M.W.: Sednem SRE jest opomiarowanie Service-Level Objective, czyli poziomów uzgodnień wszystkich uczestników BizSecDevOps. Ostatecznie chodzi o to, aby biznes działał skutecznie. Platforma Dynatrace oferuje do tego gotowe oprzyrządowanie i pozwala skupić uwagę na pomiarach tego, co istotne w miejsce tego, co poszczególne zespoły potrafią mierzyć.

M.Ł.: To, o czym mówimy to niekończące wyzwanie aktualne od 20-30 lat, a polegające na tym, że w IT mówimy, iż powinniśmy rozmawiać z biznesem. Wiadomo, że musimy, ale jak to zrobić? Coraz więcej metodologii mają pewien, bardzo silny element naturalnej współpracy z biznesem. Wspomniane SRE to DevOps plus mierzalność, SLO, elementy miękkie, Business Partnership. Dzięki temu biznes jest naszym partnerem, a nie jedynie kolejną „warstwą” organizacji, z którą musi rozmawiać.

M.W.: Mamy ciekawe doświadczenie w relacji firmą, która wdrożyła we współpracy z Google zasady SRE. Firma ta po wykonaniu PoC Dynatrace stwierdziła, że gdyby mieli te narzędzia wcześniej, to rok pracy nad SRE można było zamknąć w kwartale i znacząco ograniczyć nakład pracy nad utrzymaniem. Ta oszczędność czasu dotyczyła nie tylko wytworzenia narzędzi, ale przede wszystkim łatwości dokonywania uzgodnień miar SLO pomiędzy IT i biznesem.

M.O.: Co ważniejsze, dzięki temu łatwiej jest zachęcić zespoły do współpracy.

OBSERVABILITY Z PERSPEKTYWY NOOPS

Wszyscy właściwie mówiliście o platformach inżynieryjnych, Site Reliability Engineering, które jest DevOps’em na sterydach. Ale dziś mówi się też o NoOps, odcięciu pewnej części informacji idącej do osób o określonym profilu. Te profile znowu się rozchodzą. Z drugiej strony dążymy do holistycznej informacji. Może dałoby się to uspójnić swego rodzaju nakładką ułatwiającą dystrybucję informacji w organizacji?

M.Ł.: Bardzo dobrze to opisałeś. To prawda, z jednej strony jesteśmy w coraz większym stopniu zależni od technologii. Staje się coraz bardziej złożona, wielochmurowa, oparta o niezliczoną liczbę mikroserwisów i kontenerów. Więcej deweloperów pracuje nad jej rozwojem, jednocześnie coraz szybciej się zmieniają projekty. W efekcie dokumentacja nie zawsze jest perfekcyjna, nie zawsze właściwie przeczytana. Ten czynnik tworzenia oprogramowania stanowi wysokie ryzyko.

Nie widziałem jednak jeszcze raportu, który odpowiedziałby na pytanie o skuteczność observability versus oczekiwania. Jak to wygląda? W sensie czysto akademickim absolutnie potrzebujemy dashboardów, które pokazują to, co jest naprawdę istotne z punktu widzenia funkcjonowania aplikacji. Ale na ile jest to skuteczne? Na ile pokazuje prawdziwy obraz?

M.W.: Wszyscy przywykli do dashbordów. Natomiast trend jest taki, aby zamiast oferować „data on the glass”, zautomatyzować działania diagnostyczne i naprawcze. Poza wyświetlaniem na pulpitach informacji o stanie systemu, dużo skuteczniejsze są notyfikacje o konkretnych problemach kierowane do osób odpowiedzialnych za usuwanie problemów, a tam gdzie to możliwe i dozwolone dokonywanie autoremediacji. Na szczęście potrafimy pokazać to klientom w formie prezentacji wersji demo, albo potwierdzić po trwającej godzinę instalacji, która praktycznie kończy wdrożenie na potrzeby PoC. Nic nie działa na wyobraźnie lepiej jak sprawdzenie w praktyce.

M.O.: Dla mnie największą różnicą między tym, co mieliśmy, czyli monitoringiem a observability, jest fakt, że nasze narzędzie posiadają algorytmy i mechanizmy sztucznej inteligencji, które analizują stan aplikacji za nas. Nie powinniśmy nawet mieć dashboardów, lecz otrzymywać notyfikacje, jeśli pojawią się anomalie i móc zareagować na nie. To de facto wspomniana perspektywa NoOps, kiedy nie chcemy na co dzień spędzać czasu monitorując, czy aplikacje zachowują się tak, jak powinny i czy założone cele są spełnione.

Z drugiej strony potrzebujemy danych z poziomu DevOps’owego, z perspektywy połączenia wszystkich perspektyw. Jeśli nagle nie spełnimy któregoś ze wskaźników KPI, ale mamy informacji o powodzie takiej sytuacji, to w Dynatrace możemy dojść do detali i zrozumieć co wpłynęło na to, że konkretny KPI „nie został osiągnięty” i jak to szybko naprawić.

R.J.: Liczba i zakres informacji, które są widoczne na monitoringach, jest ogromna. W tym gąszczu bardzo ciężko zauważyć anomalie, jeżeli chce się patrzeć tylko na wykresy. Muszą być definiowane inteligentne warunki, które – w momencie ich przekroczenia – wzbudzają alarm. Wykresy, dashboardy są tylko po to, aby wejść głębiej, obejrzeć coś dokładniej. Helicopter View to podstawa. Bez tego nie da się sprawnie działać.

M.W.: Observability od monitoringu różni się przede wszystkim tym, że zamiast mierzyć zadane miary, oceniamy wszystko i doszukujemy się anomalii w działaniu systemu jako całości. Tu pojawiają się algorytmy AI i automatyzacja bez których takie podejście nie byłoby możliwe. W przypadku wystąpienia awarii zamiast więc otrzymać kilkadziesiąt sygnałów z różnych miejsc o przekroczeniu mierzonych parametrów, Dynatrace poinformuje nas o problemie, oceni ilu dotyka użytkowników, w jakich lokalizacjach, na jakich urządzeniach czy przeglądarkach i wskaże źródło zakłócenia do konkretnej linii kodu włącznie. Powie nam też jakie działanie spowodowało błąd.

M.O.: W świecie idealnym, gdzie mamy dojrzałą organizację, ten proces może być nawet zautomatyzowany. Reakcja jest szybka i problem nie zdąży się rozlać, bo następuje reakcja w momencie jego wykrycia. Realizowaliśmy tego typu projekt u jednego z klientów w Polsce. Zautomatyzował on cały proces wytwarzania i utrzymania aplikacji.

Jeżeli jakiś parament spada, to odpowiednie release’y są cofane, weryfikowane, czasem dobalansowywane, a niekiedy – jeśli nie da się w pełni zautomatyzować ich naprawy lub weryfikacji tego, co się wydarzyło – lądują na froncie dashboardu. Wówczas administratorzy analizują, co można zrobić inaczej. Wspomniana firma w tej chwili praktycznie nie zagląda do systemu produkcyjnego. Co więcej, nikt nie ma uprawnień do manualnej zmiany jego konfiguracji. Wszystko dzieje się automatycznie.

W jednej z wypowiedzi Marek zastanawiał się nad skutecznością observability. Nie wiem, czy to dobrze wybrzmiało? Czy my dopiero do tego zmierzamy? Czy potrzebujemy do tego jakiejś metodyki? Czy wystarczą nasze doświadczenia?

M.W.: Widać w naszych działaniach sporą dozę nieufności, która nie raz chroni nas przed pochopnymi decyzjami. Niestety niejednokrotnie nie pozwala nam uzyskać odpowiedniej skali efektów. Może zatem potrzebujemy nieco więcej odwagi i rozmachu. Gotowe przykłady płyną ze świata i nie jest tak, że nie możemy ich adaptować w naszych realiach. Zbyt powolne wdrażaniem zmian powoduje, że sumują się wady starego i błędy młodości nowego.

Podobnie jest z observability. Jeżeli platformy Dynatrace używamy z różnych względów – biznesowych, prawnych, kulturowych – tylko w ograniczonym zakresie, to mamy do czynienia z podobnym stanem przejściowym. Część naszych naszch klientów w Polsce ma platformę Dynatrace wdrożoną częściowo, bo np. jeden z zespołów kupił ją po to, aby mieć możliwość wykazania, że ewentualne błędy nie powstały po ich stronie. Mamy jednak coraz więcej przykładów pełnoskalowego wdrożenia, które pozwalają potwierdzić efektywność observability w polskich warunkach.

Na świecie jest wiele tego typu przykładów. Raport Total Economy Impact firmy Forrester Research – oparty o te case study – pokazuje realne korzyści z wdrożenia Dynatrace. Jest to ROI na poziomie 270% i zwrot inwestycji w zaledwie 6 miesięcy. Powód? Między innymi wzrost czasu poświęcanego na innowacje vs utrzymanie, większa skuteczność działania aplikacji, większe zadowolenie klientów, polecanie usług a w efekcie wzrost przychodów. Do tego zadowoleni pracownicy, bo nie zarywają nocy i weekendów walcząc z awariami. Szybciej identyfikują jej miejsce. Nie „rzucają więc papierami”. Te czynniki powodują wysokie ROI.

Czy PKO Bank Polski ma wspomniane Helicopter View na funkcjonowanie swoich systemów?

R.J.: Mamy je w zakresie nadzorowania funkcjonowania kanałów elektronicznych, mobilnych. Jak wspomniałam, mamy monitoring na poziomie aplikacji i działające w trybie 24/7 centrum monitoringu, do którego trafiają wszystkie alarmy. Jeżeli chodzi o aplikację iPKO, którą się w tej chwili zajmuję, to mamy monitoringi aplikacyjny i sprzętowy. Każda aplikacja jest monitorowana i dla każdej porobione są dashboardy i alarmy. Nasz system monitoringu rozwija się cały czas tak samo, jak nasze produkty. Jest to stały proces.  Zwłaszcza przy przechodzeniu na mikroserwisy, ten proces jest niezwykle ważny.

M.W.: Teraz wyobraź sobie sytuację, w której Platforma zadba o to sama i nie trzeba robić tego na piechotę.

M.O.: Jak robiliśmy instrumentację pewnych rzeczy w jednym z banków, i administratorzy zobaczyli co udało nam się osiągnąć, to powiedzieli, że szkoda, że nie wiedzieli tego trzy miesiące wcześniej, gdy zaczęli tworzyć własny monitoring. Na platformie Dynatrace mogliby w tym samym czasie zrobić dwa razy więcej i dużo taniej, bo koszt utrzymania bieżącego monitoringu jest – cytuję – „zatrważający”. Ludzie próbują budować coś własnego z gotowych elementów, bo jest cała masa rozwiązań open source. Tylko wdrożenie, skonfigurowanie i utrzymanie takiego rozwiązania są niekiedy droższe niż najdroższy produkt na rynku.

M.W.: Dodam do tego co powiedział Michał, że gdybyście spytali, z czym konkurujemy na polskim rynku, to nie są to rozwiązania konkurencji, lecz podejście „zrób to sam”.

K.S.: W RBI działamy w wielu krajach. I to nie jest tylko polska specyfika. Ludzie po prostu lubią mieć coś „swojego”. Ponieważ używamy Amazon Web Services, to de facto do monitoringu i observability używamy narzędzi Prometheus, Grafana, CloudWatch. To są rozwiązania open source, ale nie musimy się nimi martwić, bo oferowane są nam jako Managed Services. My to „paczkujemy” i oferujemy użytkownikom jako gotową platformę, a mimo to jest dokładnie tak samo, jak mówiłeś. Ludzie wolą setupy niestandardowe, bo są ich własne, które traktują je jak własne „dziecko”. Doskonale to rozumiem. Sam kiedyś byłem deweloperem i też wolałem mieć swoje narzędzia, a nie narzucone przez kogoś.

M.W.: Jest jeszcze inna kwestia. Kiedyś jak się chciało coś kupić, to szło się do CIO, który podejmował decyzję o inwestycji. Dzisiaj, aby kupić system o odpowiednio dużym poziomie komplikacji, trzeba uzyskać konsensus na wielu poziomach organizacji. Tymczasem to właśnie te osoby są często zagrożone jego wdrożeniem. Często zdarza się też, że kluczowy pracownik, np. deweloper o unikalnych kompetencjach, ma tak silny wpływ na szefa i jego szefów, że paraliżuje ich strach przed „rzuceniem papierami”. Niestety obserwujemy takie zjawisko.

M.Ł.: Pamiętajmy, że rozwijanie wielu systemów wewnętrznie to jeden z megatrendów dzisiejszego świata IT. Nie oznacza to, że dotychczasowi zewnętrzni partnerzy technologiczni są eliminowani, ale krytyczne dla naszej działalności rozwiązania chcemy rozwijać wewnętrznie. Posiadanie pracownika wewnątrz organizacji ma dodatkową wartość z racji możliwej ścieżki rozwoju i faktu, że bardzo szybko następuje dziś digitalizacja wszelkich, możliwych biznesów.

SKUTECZNE NADZOROWANIE CORAZ HYBRYDOWYCH ŚRODOWISK IT

M.W.: Kiedyś było tak, że człowiek rozwijał system, sam go budował i wszystko było dokumentowane, w pewien sposób stabilne. A dzisiaj infrastruktura IT jest coraz bardziej rozproszona, chmurowa, dynamicznie się zmienia. Młodzi ludzie nie chcą utrzymywać starych systemów, tylko realizować nowe, fajne projekty. A jak im się nie podoba to mogą odejść z dnia na dzień. Utrzymanie ciągłości pracy staje się coraz trudniejsze. Platforma Dynatrace w dużym stopniu może nas zabezpieczyć także przed tym zjawiskiem.

M.O.: Rozumiem czemu ludzie boją się platformy. Jeśli tworzą własne rozwiązanie, to poznają je w tempie, w jakim je tworzą. Jak dostają gotową platformę taką, jak Dynatrace, która pokrywa praktycznie wszystko, to ciężko jest im się odnaleźć w ogromie możliwości dostępnych w menu. Bronią się przed nauką nowego narzędzia w takiej skali.

R.J.: Pierwszy opór przed monitoringiem faktycznie bywa duży. Ale w momencie, kiedy zespoły zaczynają z niego korzystać i dostrzegają, że informacje, których musieli wcześniej długo szukać są na wyciągnięcie ręki, to zaczynają doceniać platformy Dynatrace czy Grafana. Nietrudno przekonać ich, aby zrobili integrację kolejnych modułów i funkcjonalności.

Czy w przypadku obserwowalności też mamy do czynienia z vedorlock?

M.W.: Vendorlock oczywiście nie jest niczym fajnym. Ale nasuwa się pytanie, czy tak kompleksowa platforma, jak Dynatrace stwarza takie zagrożenia? I tak i nie. Jeżeli „wgranie” naszej platformy to kwestia kilku godzin, to podobnie będzie z inną, która ją ewentualnie zastąpi. Zawsze można wyłączyć i nie używać agentów Dynatrace, pamiętajmy jednak, że na tym rozwiązaniu budujemy kulturę funkcjonowania firmy.

M.O.: Wyjątkowo się z Tobą nie zgodzę. Poprawnie zbudowany DevOps to nie tylko platforma observability. To są także: pipeline-y, narzędzia, które badają Quality Gate’y lub mierzą KPI – czy to na etapie wdrożeń, czy potem, w trybie rzeczywistym. Jest cała masa rozwiązań, które potrafią się podpiąć do tych platform, także open source.

W tym momencie możemy wytworzyć cały proces, opierając się na narzędziach, które pozwalają automatyzować masę rzeczy. Później – jeśli zmieniamy platformę – musimy tylko dostarczyć z tej nowej integrację, metryki i dane, które zastępują nam poprzednie rozwiązanie. W kontekście kultury nie budujemy więc vendorlock.

K.S.: Jestem jednak fanem używania chmury i dostępnych tam Managed Services. Dostawca tych usług dba o ich jakość, dostarczanie nowych wersji itd. De facto też staje się vendorem, ale różnica jest taka, że płacę za tyle, ile używam. Jeżeli zdecyduję się nie używać danej usługi albo używać jej mniej, to momentalnie obniżam rachunek.

M.W.: To jest kolejny, istotny problem. Migracja do chmury bez odpowiedniego narzędzia pomiarowego jest ryzykowna. Zamieniasz wydatki CAPEX na OPEX, ale nie wiesz jak wysokie będą w przyszłości miesięczne opłaty. Nagle okazuje się, że wydatki eksplodowały, bo kod został źle napisany. W on-premise działał dobrze, ale w chmurze coś się „rozkrzaczyło” i ten sam kod generuje wysokie koszty. Tymczasem platforma observability widzi cały ekosystem środowiska IT jako jedną przestrzeń, czy jest w naszym centrum danych, czy w dowolnej chmurze publicznej. Generuje więc spójne raporty.

M.O.: Marek zapomniał powiedzieć, że Dynatrace zmienił niedawno sposób licencjonowania.

Nowy uzależniony jest m.in. od tego, ile masz danych. A jeśli zdecydujesz się na chmurę to możesz mieć naszą platformę jako Managed Services.

K.S.: Czy Dynatrace planuje dogadać się np. z AWS albo Microsoft, aby mieć w tych chmurach swoje rozwiązanie?

M.W.: Dynatrace jest „dogadany” w wszystkimi dużymi graczami. W AWS są usługi Managed Services for Dynatrace.

M.O.: Dodatkowo, jeśli będziesz brał Dynatrace, w wersji chmurowej – z Grail Data Lakehouse – to będziesz mógł także zdecydować, czy chcesz płacić za duży system pamięci masowej, bo jako bank potrzebujesz np. długiej retencji danych, a niekoniecznie będziesz robił na niej analizy wydajnościowe. Zdecydujesz czy chcesz płacić za procesor, czy za storage.

M.W.: Dynatrace odpowiedział w ten sposób na ograniczenie, które dotyczy wielu wdrożeń chmurowych, w których jest dużo danych, w szczególności tych, które trzeba wcześniej indeksować. W efekcie powstał Grail Data Lakehouse oparty o dostępny w chmurze storage, na który można wgrać dowolnego typu dane, także te niepoindeksowane. Nie ma rehydracji nieużywanych danych. Zapytanie do zwracają odpowiedzi w ułamkach sekund. W uproszczeniu ciężar opłat jest przesunięty z przechowywania danych na zapytania.

OBSERVABILITY JAKO PREDICTIVE MAINTENANCE

Chciałbym jeszcze, abyście podzielili się spostrzeżeniami dotyczącymi tego, czego nie robić wdrażając narzędzia observability, czego unikać, a co jest dobrą praktyką? Jaka są Wasze oczekiwania i wizja wytwarzania oprogramowania jeśli już opanowało się observability?

M.Ł.: W przemyśle observability znane jest od lat jako koncepcja Predictive Maintenance. Zresztą dotyczy dzisiaj nie tylko przemysłu, ale też Smart Buildings czy Smart Cities. Są to systemy oparte na algorytmach AI, które – analizując tysiące różnych czynników i odczytów z czujników – szukają anomalii w zachowaniach danego systemu. System działa, ale system Predictive Maintenance wyłapuje sygnały, które mogą świadczyć o potencjalnej awarii. Nie czekamy na nią, tylko staramy się jej zapobiec.

M.O.: DevOps także musi oprzeć się o sztuczną inteligencję. Platformy wykorzystujące algorytmy AI pozwalają przeanalizować jakąkolwiek anomalię i dowiedzieć się czy ona może mieć negatywny wpływ czy nie. Sprawdzić potencjalne zależności. Określić, czy to jest sygnał False Positive. Czy sytuacja jest normalna, czy zaczyna na coś wpływać? Dynatrace analizuje nie tylko „współczynniki” techniczne i biznesowe, ale też związane z bezpieczeństwem. Dlatego powtórzymy, nie powinno się mówić o DevOpsie, tylko BizDevSecOpsie.

K.S.: Największy problem w IT to fakt, że jak dodajemy nowy komponent to trzeba dodać do niego funkcjonalność observability. Warto, aby coś – zamiast człowieka – dbało o ten aspekt.

M.W.: Jak wgrasz agenta Dynatrace na hosta, to tam dzieje się to już samoistnie. Agent wykrywa modyfikacje, nowe komponenty i frameworki. Już na poziomie developmentu możesz zdecydować, co ma być monitorowane. Działa to na zasadzie Monitoring as a Code. Każda aplikacja wchodzi na produkcję z całym oprzyrządowaniem do monitorowania.

K.S.: W AWS jak zdecydujesz się dodać nowy komponent, to ktoś z tyłu dba o to, aby Grafana, Prometeusz czy CloudWatch mogły zbierać informacje o nowej usłudze Managed Services. Jest łatwiej, choć nie ma jeszcze sztucznej inteligencji, która by za Nas to zrobiła. To pewnie tylko kwestia czasu.

M.W.: Szymonie, wspomniałeś o dobrych praktykach. Dla mnie podstawową jest to, aby uświadamiać zarządy firm o wadze wdrożenia platform Observability i wpływie jaki to ma na całą organizację i jej kulturę, która jest kluczowa do tego, aby skutecznie konkurować z otoczeniem.

M.Ł.: Jeśli mówimy o dyskusjach na poziomie zarządu, to jest to głównie rola CIO lub CDO. Oni tego typu wiedzę powinni mieć i rozmawiać o tym z CEO lub innym członkiem zarządu.

M.W.: Interes całej firmy jest reprezentowany na poziomie zarządu. Inwestycje w takie narzędzia jak Dynatrace, to często ten sam budżet, co etaty.

K.S.:  W większości organizacji nie ma już budżetów IT. Jest za to wirtualny budżet przypisany pod konkretne tribe’y.

Mamy tu dwa „progi”, o które można się potknąć. Strukturę budżetowo-organizacyjną oraz kulturowo-świadomościową. Co jeszcze może być przeszkodą?

M.Ł.: Brak rozmów z biznesem. Pewne elementy są w miarę oczywiste i łatwo w ich zakresie podjąć decyzję w obrębie IT. Ale warto też dowiedzieć się od biznesu, jakie są ich priorytety. I może okazać się, że w tym momencie dashboard powinien być trochę inaczej skonstruowany, aby inne rzeczy były bardziej widoczne.

R.J.: Na pewno przydałyby się dashboardy produktowe.

K.S.: W RBI mamy platformę wymiany walut, której rozwój nadzoruje Product Owner. Nie jestem pewny czy, chce on znać poziom utylizacji compute power w usłudze AWS EC2. Chce za to wiedzieć ilu w danej chwili mamy zalogowanych klientów, z jakiego kraju i jaki jest wolumen ich transakcji.

M.W.: To taki dashboard SLO, gdzie wklikujesz się w kolejne warstwy.

M.Ł.: SLO znowu wymaga rozmowy z biznesem, aby wiedzieć jakie informacje są istotne.

R.J.: To jest ta zmiana podejścia. Chcemy, aby monitoring, do tej pory rozumiany przez IT, był też zrozumiały i wykorzystywany przez biznes. To de facto oznacza, że musimy zmienić standardowy monitoring. Jeżeli wskazuje jedynie, że jakiś komponent odpowiada o kilka milisekund dłużej, albo mamy wzrost obciążenia CPU, to dla biznesu nic nie znaczy. Musimy „przetłumaczymy” to na język produktu, pokazując, że skutkiem tych problemów jest np. wydłużony czas logowania klienta, a to przekłada się na mniejszą transakcyjność. Biznes musi zobaczyć wpływ problemów technicznych na produkt.

Kto ma przetłumaczyć np. te wyższe obciążenie CPU na miarę biznesową?

R.J.: To jest efekt współpracy zespołów. Mamy usługi, które np. na bieżąco monitorują dostępność produktu pożyczki gotówkowej. Tak przygotowaliśmy dashboardy, że jesteśmy w stanie – na podstawie zewnętrznych usług – połączyć wszystkie komponenty, które obsługują tę usługę. Monitorując produkt biznesowy mamy wpięte wszystkie elementy, które ten produkt tworzą. Biznes mówi „co i jak”, a my mówimy, które komponenty weryfikować i gdzie ustawić progi, które wzbudzą alarmy.

M.W.: Opisałaś bardzo zaawansowany mechanizm w kilku zdaniach. Natomiast nie wspomniałaś ile pracy kosztowało to, aby to wszystko zadziałało w ten sposób. A to jest wielki wysiłek organizacji, który można „załatwić” wgraniem agentów.

K.S.: Nie zgodzę się. To, o czym mówi Renata, to wiedza biznesowa, a nie IT. Tymczasem agent jest tylko narzędziem.

M.O.: Wczoraj robiłem konfigurację Dynatrace dla jednego klienta. Zapięliśmy identyfikator MID (Member ID – przyp. red.) dla banków, które łączą się z jego usługą. Dzięki temu od razu widoczne stało się np. to. czy banki odpowiadają wolniej i przez to realizowanych jest mniej transakcji. Zajęło nam to ok. 25 minut. A jest to jak najbardziej biznesowa metryka. Pokazuje liczbę transakcji, które nie przeszły i partnerów, którzy nie mogli ich wykonać.

Pięć topowych narzędzi, które znajdują się w rankingu Gartnera, jak wepnie się w Twój program, to automatycznie zapina dodatkowe trace’owanie na wszystkich znanych frameworkach. Same wykryją techniczną i biznesową architekturę Twojej aplikacji.

K.S.: To znaczy, że agent Dynatrace ingeruje w kod, wrzuca go w każdy mikroserwis, w każdą klasę Javy?

M.O.: Nie ingeruje w niego, tylko w maszynę wirtualną Javy, która wykonuje ten kod.

M.Ł.: Kluczowym elementem jest rozmowa z odbiorcą naszej usługi i ustalenie wspólnego języka do tego stopnia, że np. w metodologii DDD poszczególne klasy w Javie są opisywane terminologią właściwą biznesowi.

Mówiliście o komunikacji z biznesem, tłumaczeniu, co jest ważne, jakie rzeczy można wychwycić. Ile takiej nowej wiedzy, schematów da się wyciągać, przedstawiać i analizować, aby stymulować większą efektywność i szybkości działania aplikacji?

R.J.: Przede wszystkim da się to zauważyć po zachowaniach klienta. Dzisiaj jest np. 10 dzień miesiąca i wiemy, że wszyscy płacą podatki. Z monitoringu da się wychwycić to, jak zachowują się klienci i to jest wartość dodana. Uczenie się zachowań na podstawie monitoringów czy trace’owania, otwiera nam drogę do zastanawiania się, co ekstra możemy jeszcze klientom dostarczyć. Gdzie możemy zdobyć dodatkową wartość biznesową.

M.W.: Jest Dynatrace Hub, swego rodzaju sklep, gdzie można kupić narzędzia zintegrowane z naszą platformą. Można tam znaleźć m.in. nasze autorskie rozwiązanie Omniscopy, które nagrywa sesje użytkownika i zbiera analitykę sesji, w tym wszystkie kliknięcia, błędy, porzucenia itd. Dane, jakie są w ten sposób zbierane, pozwalają odpowiedzieć na dowolne pytania o aktywność użytkownika w aplikacji.

K.S.: Dane IT z monitoringu i observability zaczynają się dziś mieszać z tymi biznesowymi. Zaryzykowałbym stwierdzenie, że jak się dobrze powiąże oba typy danych to można np. zdefiniować lepszy algorytm marżowania danego klienta. Nasi DevOps’i wiedzą o tym, że ich ewentualna pomyłka lub brak proaktywności przekłada się na to ile zarabia biznes. W MBO osób pracujących w IT pojawiają się w pewnym stopniu również cele biznesowe.

M.W.: Podsumowując, nie chcę, aby to brzmiało, że nie jesteście w stanie zrobić tego wszystkiego tworząc własne rozwiązania. Oczywiście, że w jakimś stopniu tak. Wydaje się jednak platforma, rozwijana na co dzień przez ponad tysiąc specjalistów zrobi to lepiej.

Debatę poprowadzili: Szymon Augustyniak i Adam Jadczak