Od podejścia Everything as a Code do Monitoring as a Code

Z Tomaszem Płońskim, CTO w Omnilogy, rozmawiamy o zmianach, jakie wprowadził DevOps w – korzystających z tej metodologii – organizacjach; automatyzacji i transparentności oraz wspierających ją technologiach; monitoringu środowisk IT; dostarczaniu przez Dynatrace wspólnych danych dla programistów, administratorów, biznesu czy działów bezpieczeństwa; a także usprawnieniach w procesie tworzenia oprogramowania  – weryfikowaniu kodu aplikacji dużo wcześniej niż na produkcji; większym wykorzystaniu testów automatycznych; czy połączeniu bram jakościowych z platformą Observability.

DevOps to przede wszystkim kultura organizacji czy technologia?

Przede wszystkim kultura wspierana technologią. Nie da się patrzeć na temat DevOps, nie widząc tej zależności.

Czy DevOps wymusił zmiany w technologii?

Wymusił to za silne słowo, ale na pewno ukierunkował. Podstawą DevOps jest automatyzacja i transparentność, więc technologia musi je wspierać. To że większość aplikacji powstaje dziś w architekturze mikrousługowej, uruchamiane są w chmurze prywatnej lub publicznej, to – w dużej mierze – jest wynikiem tej potrzeby. Środowiska te praktycznie same wymuszają automatyzację pracy. A transparentność to wyzwanie dla narzędzi do monitoringu.

DevOps to wspólny cel różnych kompetencji. Co jest kluczowe, aby był realizowany?

Wspólnoty zawsze buduje się w oparciu o wspólny język, jedną prawdę. Dla DevOps dobrym przykładem jest platforma Observability, jaką jest Dynatrace. Dostarcza ona wspólnych danych dla programistów, administratorów, biznesu czy działów bezpieczeństwa. Wspiera cały BizDevSecOps. Jeszcze nie tak dawno na procesy DevOps patrzyliśmy głównie jako narzędzie do jak najszybszego przekazania nowych funkcjonalności klientom. Wraz ze wzrostem świadomości, rozwojem Site Reliability Engineering, już na etapie wdrażania jesteśmy w stanie ocenić skuteczność nie tylko na poziomie IT, lecz także biznesowym, wskazującą bezpośrednio zależność między wydajnością, błędami a celami, takimi jak wzrost wielkości sprzedaży czy optymalizacja zachowania użytkowników.

Patrząc na aplikację, nie możemy zignorować obszaru UX, który bardzo często ma kluczowe znaczenie dla użytkownika końcowego. To wszystko da się zmierzyć bezpośrednio w platformie Observability. Zmierzyć i odpowiednio zareagować. Pamiętajmy, że – na przykładzie Dynatrace – teraz w budowaniu kultury BizDevSecOps mamy jeszcze jednego sprzymierzeńca. Jest to silnik sztucznej inteligencji, która te zależności analizuje za nas i podpowiada, na jakie dane powinniśmy zwrócić uwagę w pierwszej kolejności. Pozwala te dane współdzielić i nawiguje przy analizie w każdym kierunku. Również w kierunku bezpieczeństwa.

Działy bezpieczeństwa mają wyspecjalizowane narzędzia, które działają niezależnie od procesów wytwórczych. Można je zastąpić?

Nie ma o tym oczywiście mowy. Są to wysoce wyspecjalizowane platformy konfigurowane i obsługiwane przez znakomitych specjalistów. Włączenie działu bezpieczeństwa w proces DevOps nie może wiązać się ze zwiększeniem ich obciążenia. Działy te już dzisiaj są na granicy wydolności z uwagi na konieczność przeciwdziałania niespotykanej skali zagrożeń. Dlatego ponownie wrócę do jednego z kluczowych czynników w budowaniu kultury DevOps, czyli automatyzacji.

Te same narzędzia – wykorzystywane do oceny wydajności – oceny dostępności, mogą analizować w trybie ciągłym wdrażany kod i sprawdzać go pod kątem istnienia w nim podatności. A ponieważ działają 24/7, to natychmiast alarmują, gdy tylko pojawi się nowe zagrożenie. Jest to zdecydowana przewaga nad skanerami analizującymi repozytoria kodu wg harmonogramu, np. raz dziennie. Tutaj naprawdę liczy się każda godzina.

Narzędzie to nie wymaga żadnej konfiguracji. Wystarczy tylko włączyć i reagować zgodnie ze wskazanym przez sztuczną inteligencję priorytetem. Zarówno po promocji na środowisko produkcyjne, jak i w potoku uruchamiania na kolejnych środowiskach testowych.

Shift-left, shift-right?

Dokładnie tak. Jeżeli weryfikujemy aplikację w warunkach produkcyjnych – czyli shift-right – zależy nam na jak najszybszym wykryciu problemu i ograniczeniu jego skali. Kluczowe jest zebranie wszystkich danych do jego naprawy. Dynatrace to zapewnia. Wykorzystywane przez tę platformę algorytmy AI same wykrywają anomalie. Analiza bazuje na połączonych danych metrycznych, transakcjach z analizą drzewa kodu, logach i danych infrastrukturalnych. AI Dynatrace pomaga znaleźć przyczynę problemu. W większości przypadków tylko odczytujemy wynik tej analizy.

Natomiast podejście shift-left daje możliwość działania dużo wcześniej niż na produkcji. Testy i monitoring we wczesnych fazach budowy aplikacji pozwalają uniknąć sytuacji, gdy niewykryte wcześniej problemy dotykają użytkowników końcowych. Wystarczy trochę zmodyfikować proces Continuous Integration/Continuous Delivery – CI/ CD – i wprowadzić odpowiednie bramy jakościowe w potoku dostarczania oprogramowania.

Proces C/CD jest dzisiaj normą. Nikt również nie uruchamia aplikacji bez testów. Co tutaj jest nowego?

Chodzi o automatyzację i zakres oceny. Jakiś czas temu typowym scenariuszem było zbudowanie nowej wersji oprogramowania, wdrożenie na środowisko i przekazanie do testów. Na bazie raportu z testów podejmowana była decyzja, czy oprogramowanie spełnia normy jakościowe. Najczęściej głównie decydował wynik testów funkcjonalnych. W bardziej dojrzałych organizacjach dochodziły automatyczne testy wydajnościowe. Jednak na końcu to człowiek analizował ich przebieg i oceniał.

Obecnie – wraz ze wzrostem dojrzałości procesów DevOps – widać większe wykorzystanie testów automatycznych – funkcjonalnych, API, wydajnościowych czy bezpieczeństwa. I to jest dobry kierunek. Często wynik raportowany przez automaty daje przesłankę do odrzucenia wersji. Widać tutaj tylko jedno zagrożenie, zakres raportowanych – i tym samym ocenianych – danych jest bardzo ograniczony.

Środowisko testowe jest dla automatów czarną skrzynką. Są w stanie ocenić tylko zewnętrzne metryki. Wyobraźmy sobie prosty scenariusz. Zatwierdziliśmy zmiany w kodzie dotyczące logowania do aplikacji. Nasz proces CI/CD zbudował i wdrożył nową wersję aplikacji, a następnie uruchomił test wydajnościowy. W kolejnym kroku ocenił wyniki, które otrzymał – czas odpowiedzi i procent błędów. Jeżeli mieściły się w normie, to zezwolił na wdrożenie na kolejnym środowisku, np. na produkcji. Po wdrożeniu okazało się jednak, że nowe logowanie spowodowało awarię serwerów, bo nikt nie zwrócił uwagi na zwiększoną liczbę zapytań do bazy danych, zwiększone zapotrzebowanie na moc obliczeniową itp.

A powinien zwrócić na to uwagę?

Tak, tym bardziej że jest to bardzo proste. Wystarczy wdrożyć odpowiednie bramy jakościowe w połączeniu z platformą Observability. My rekomendujemy i wdrażamy Dynatrace Software Intelligence nie tylko na środowiska produkcyjne, ale i przedprodukcyjne. Dlatego podczas wykonywania testów monitoring pozwala skorzystać z bardzo kompleksowych danych. Widzimy wszystko co się dzieje wewnątrz aplikacji pod obciążeniem, tak samo jak na produkcji.

Wykorzystując dodatkowo projekt open source Keptn, łatwo wzbogacamy proces CI/CD o automatyczną ocenę testów na bazie obiektywnych danych z monitoringu. Patrzymy oczywiście na czasy odpowiedzi, błędy, ale i na liczbę zapytań do bazy danych, komunikację między usługami, wyjątki czy zapotrzebowanie aplikacji na infrastrukturę.

Nie zapominajmy również o sprawdzeniu, czy nasza nowa wersja nie zawiera podatności bezpieczeństwa. Definiujemy metryki, wybierając dowolne SLI dostępne w Dynatrace. Następnie przypisujemy im cele SLO w oparciu o wartości bezwzględne, ale i o przyrosty w stosunku do poprzednich wersji. Wprost przeciwdziała to regresji. Keptn jest obecnie jednym z najintensywniej rozwijanych projektów Cloud Native Computing Foundation.

Oczywiście automatyczne bramy jakości to tylko ułamek jego możliwości, ale najprostszy do wdrożenia w procesach DevOps. Projekt powstał, aby uprościć potoki CI/CD, pozwalając na deklaratywne definiowanie wszystkich zadań związanych z testami, oceną, wdrożeniami czy nawet autoremediacją. Keptn posiada integrację z wieloma narzędziami. Baza ta jest też stale powiększana.

Wszystko wydaje się faktycznie proste, przynajmniej w teorii, ale czy nie ma tutaj pułapki, że przy częstych wydaniach wersji monitoring nie będzie nadążał za zmianami?

To zagrożenie faktycznie istnieje, zwłaszcza gdy budujemy rozwiązania do monitoringu sami, korzystając np. z platform typu open source. My mamy łatwiej, bo bazujemy na Dynatrace. Tej platformy praktycznie nie trzeba konfigurować. Nie trzeba nic robić z aplikacją czy serwerami, aby monitoring działał. Wszystko możemy zautomatyzować, w tym monitoring i jego konfigurację.

Obecny trend bazuje na podejściu Everything as a code i wynikającej z niego możliwości samowystarczalności. Już w 2020 roku State of DevOps Report wymieniał samoobsługowość – Self Servi-ce – w monitorowaniu i alarmowaniu jako jeden ze wskaźników dojrzałości DevOps w organizacji, zaraz obok CI/CD, infrastruktury na żądanie czy nowych sposobów wdrażania, jak Blue/Green czy Canary.

Co ważne, całą konfigurację Dynatrace możemy trzymać w repozytorium Git i wdrażać ją razem ze zmianami oprogramowania. Ten sam potok CI/CD może wgrywać wersję aplikacji i wprowadzać zmiany w monitoringu, więc zawsze jesteśmy gotowi. Dzięki podejściu Monitoring as a Code wdrażamy Dynatrace w trybie GitOps. Takie podejście ma jeszcze jedną zaletę. Właściciel aplikacji czuje się właścicielem monitoringu, więc zawsze dba, aby był najwyższej jakości. I łatwo może go optymalizować.

Monitoring jako Self Service brzmi obiecująco, ale czy to nie powoduje, że dotychczasowe działy monitoringu przy przejściu na DevOps nie są już potrzebne?

Czasami właśnie tak się dzieje. Monitoring jest wchłaniany przez zespoły DevOps i kompetencje idą w kierunku całkowitej automatyzacji, wykrywania problemów i remediacji. Jest to najłatwiejsze w mniejszych organizacjach, często jedno lub kilku produktowych, gdzie liczba integracji jest stosunkowo mała.

W dużych organizacjach – gdzie do realizacji jednego procesu biznesowego angażowanych jest kilkadziesiąt różnych systemów, tych bardzo nowoczesnych i tych trochę mniej – dział monitoringu wciąż jest niezbędny. Chociaż jego rola ewoluuje. Ma całościową wiedzę na temat firmy i potrafi efektywnie uruchamiać poszczególne jednostki do działania, o ile jest to niezbędne. Odpowiada za koordynację i mediację, najczęściej buduje też standardy, implementowane później przez działy DevOps. I często staje się przyczółkiem do budowy kultury Site Reliability Engineering – SRE – na poziomie całej organizacji.