Przy dzisiejszej złożoności środowisk informatycznych ewentualne awarie czy problemy wydajnościowe najlepiej wychwytywać przed ich wystąpieniem. Można to zrobić – dzięki odpowiednim narzędziom do monitorowania, choć trafniejsze jest tu pojęcie obserwowalności.

Środowisko IT to setki i tysiące połączonych ze sobą komponentów – komputerów, serwerów fizycznych i wirtualnych, serwisów, usług, procesów i źródeł danych. Bez skutecznego systemu nadzoru, pozwalającego administratorom w każdym momencie (a najlepiej w czasie rzeczywistym) obserwować, co dzieje się z infrastrukturą i działającymi w niej aplikacjami nie ma mowy o szybkim reagowaniu na anomalie. Te zaś mogą mieć różnorakie pochodzenie – zewnętrzne (co zwykle wiąże się z incydentami bezpieczeństwa) lub wewnętrzne, wiążące się najczęściej z problemami wydajnościowymi, „wąskimi gardłami”, itp.

Jak zatem odpowiednio zabezpieczać firmowe środowisko? Rozmawialiśmy o tym w gronie społeczności CIONET Polska w trakcie spotkania zorganizowanego we współpracy z naszym partnerem, firmą Omnilogy.

Obserwowalność zamiast monitoringu
Narzędzia do monitoringu, dzięki wbudowanym mechanizmom wykrywania i diagnozowania anomalii, są w stanie zidentyfikować źródła problemów wpływających na wydajność i bezpieczeństwo bez ingerencji człowieka. U podstaw wdrożenia systemu monitorującego leży kwestia, czego w istocie potrzebujemy – jakie metryki chcemy mierzyć. Fakt, że aplikacja udostępniona klientom nie działa, może oznaczać równie dobrze wady po stronie front-endu, jak i problemy z kolejkowaniem lub przetwarzaniem danych w jednej z niższych warstw infrastruktury.

Jednak zdaniem Marka Walczaka, Dynatrace Country Sales Managera w Omnilogy, tradycyjny monitoring – rozumiany jako punktowy, wycinkowy nadzór – przestaje odpowiadać na potrzeby nowoczesnej organizacji właśnie z uwagi na postępującą złożoność infrastruktury oraz rosnącą liczbę zagrożeń.

Idea obserwowalności idzie dalej, bo łączy dane z metryk, logów, procesów czy przepływów danych w spójną całość, spinaną przez mechanizmy automatyzacji i algorytmy sztucznej inteligencji. Dzięki obserwowalności można uzyskać ogólny obraz całego firmowego IT, wzbogacony o elementy (metryki) biznesowe (pewna ilość danych musi trafiać, rzecz jasna, do analizy ręcznej, wykonywanej przez człowieka – zwłaszcza w sytuacjach, gdy system zwraca nadmiernie dużo alertów fałszywie pozytywnych).

Tworząc nasz system monitoringu założyliśmy, że chcemy widzieć poszczególne segmenty w całości środowiska. Jeżeli to system transakcyjny, to monitoring musi obejmować nie tylko jego, ale również wszystkie systemy ‘satelitarne, by w razie awarii zapewniać pełną ścieżkę diagnostyczną – mówił Piotr Płaczek z mBanku.

Niezbędnik administratora
Jednym z narzędzi realizującym założenia obserwowalności jest Dynatrace. System „uczy się” zachowania aplikacji (procesów) w czasie, a poznawszy typowe parametry pracy, na przykład wydajność w różnych porach dnia czy szczytowe obciążenia, jest w stanie monitorować trend i wyzwala alerty w momencie wykrycia odchyleń.

W zachowaniu aplikacji warto monitorować wszelkie odstępstwa od trendów ponieważ sytuacje niestandardowe mogą wskazywać ryzyko awarii lub nietypowe, nieuzasadnione wykorzystanie danych. „Trend, którego nauczy się system, jest dla niego wytyczną, czy coś działa dobrze. O odchyleniach zawsze będzie informować” – wyjaśnia Jacek Kujawa z Omnilogy.

Obserwowalność zapewnia też proaktywne podejście do bezpieczeństwa ponieważ umożliwia rozpoczęcie procesu naprawy usterki jeszcze przed jej wystąpieniem – zanim nawarstwiający się problem przekroczy „masę krytyczną” i dotknie użytkowników aplikacji.

Ważna jest nie tylko wiedza na temat ewentualnej podatności, ale również kontekst w jakim na występuje, to w jakim stopniu może wpływać na bezpieczeństwo infrastruktury, aplikacji i danych. Taka wiedza pozwala nam podjąć właściwe działania.

Możemy mieć kilka podatności i niekoniecznie „zabierzemy się” za tę właściwą nie mając kontekstu – a ta najgroźniejsza luka pozostanie niezaadresowana – wskazuje Marek Walczak.

Sec i DevOps w jednym stały domu
Uczestnicy spotkania zgodzili się, że bezpieczeństwo musi być immanentną częścią procesów DevOps – bez uwzględnienia tego aspektu szybkie dostarczanie i wdrażanie oprogramowania jest procesem ułomnym. Tak dochodzimy do SecDevOps.

Druga sprawa to kompetencje – zasób w kontekście bezpieczeństwa wyjątkowo cenny. „O dobrego programistę jest już trudno, ale dobry inżynier bezpieczeństwa to już rzadki gatunek. Dlatego wsparcie platformą automatyzującą diagnostykę jest takie cenne, kiedy problemy z bezpieczeństwem dotykają wszystkich i są coraz bardziej dotkliwie. Bez kompetencji i narzędzi nie jesteśmy w stanie odpowiednio szybko analizować sygnałów płynących z licznych źródeł i na ich podstawie wyciągać wnioski” – ocenił Marek Walczak.

W firmowym dziale IT mogą pracować setki osób, ale zazwyczaj nieliczna grupa – na przykład architekt czy programista o unikatowych kompetencjach – muszą uczestniczyć w każdym ważnym projekcie. I to właśnie ich, jak wskazuje Marek Walczak, odrywa się od innych zadań w wypadku awarii czy zagrożenia, gdyż posiadają wiedzę, która może być pomocna w zdiagnozowaniu problemu. To z kolei oznacza, że ich tzw. okienka w projektach biznesowych są opuszczane, projekty się przesuwają, budżety rosną, korzyści biznesowe są oddalane w czasie, co często stawia pod znakiem zapytania sens realizacji tych projektów.

W SecDevOps nie chodzi o to, by zespoły ds. bezpieczeństwa i programistyczne współpracowały ze sobą w całym procesie wytwórczym – tłumaczył Marek Walczak – ale o to, by komponent „Sec” był stałym elementem tego procesu, również w warstwie narzędziowej.

Idea SecDevOps oznacza walidację wydajności i bezpieczeństwa w całym cyklu życia aplikacji, tak szybko, jak to tylko możliwe. Pozwala to wcześnie wykrywać problemy wydajnościowe, funkcjonalne czy luki w zabezpieczeniach – im później wykryta usterka, tym większe koszty jej usunięcia i wyższe ryzyko przestojów w świadczeniu usługi.