Ciągły monitoring i obserwowalność w CI/CD
Wdrożenie procesu CI/CD (ang. CI/CD pipeline) to dopiero połowa drogi. Do pełnego sukcesu konieczne jest zapewnienie ciągłego monitoringu i obserwowalności (ang. continuous monitoring and observability), dzięki którym będzie można gromadzić szczegółowe metryki i podejmować na ich podstawie odpowiednie działania. W tym artykule przedstawię, jakie są założenia ciągłego monitoringu i obserwowalności, w jaki sposób oba pojęcia są ze sobą komplementarne oraz jak automatyzacja może ułatwić cały cykl wdrożenia oprogramowania.
Model DevOps
Pojęcie DevOps będzie dobrym punktem wyjścia dla naszych dalszych rozważań. Zrozumienie założeń DevOps pozwoli nam na umieszczenie pojęć ciągłego monitoringu i obserwowalności w odpowiednim kontekście. Z punktu widzenia biznesowego model DevOps oznacza poprawę komunikacji i współpracy między wszystkimi stronami biorącymi udział w projekcie, aby w ten sposób przyspieszyć wdrażanie oprogramowania, zapewnić jego wysoką jakość i umożliwić dodawanie nowych funkcjonalności zgodnie z potrzebami klienta.
W modelu DevOps można wyróżnić pięć głównych obszarów stanowiących zbiór zasad lub dobrych praktyk dotyczących procesu CI/CD. Zasady te to:
- Likwidacja barier w komunikacji między zespołami — wszystkie zespoły (programiści, zespoły operacyjne itp.) powinny współpracować między sobą oraz z działami biznesowymi, aby tworzony produkt czy usługa były zgodne z wymaganiami biznesowymi oraz nie powodowały problemów w fazie utrzymania.
- Uczenie się na błędach — występowanie awarii w złożonych systemach należy uznać za coś normalnego. Ważne jest, aby nauczyć się wyciągać z nich wnioski.
- Stopniowe wprowadzanie zmian — nowe wersje oprogramowania są publikowane często, ale mają formę małych aktualizacji tak, aby nie zmieniać zbyt wielu rzeczy jednocześnie.
- Wykorzystanie narzędzi i automatyzacji, aby zmniejszyć ryzyko popełnienia błędu i zaoszczędzić czas.
- Mierzenie wszystkiego — gromadzenie wszelkich dostępnych metryk dotyczących wydajności aplikacji, doświadczeń użytkowników, wykorzystywanych zasobów sprzętowych itp.
Ciągły monitoring i obserwowalność w procesie CI/CD
Szybkie publikowanie nowych wersji oprogramowania ma swoje niewątpliwe zalety biznesowe. Jednak ciągłe wprowadzanie zmian, nawet zgodne z założeniami DevOps, będzie stanowić niewątpliwe wyzwanie w dłuższym okresie. Cały proces należy dokładnie przeanalizować i kontrolować, ponieważ zaniedbanie tego może nas drogo kosztować w dłuższej perspektywie czasu. Jednym ze sposobów zminimalizowania ryzyka jest wdrożenie
rozwiązania zapewniającego ciągły monitoring i obserwowalność. Takie rozwiązanie będzie stanowić dopełnienie procesu ciągłej integracji i ciągłego wdrażania (ang. Continuous Integration and Continuous Delivery — CI/CD). Gdy mówimy o ciągłym monitoringu, odnosimy się bezpośrednio do jednej z zasad DevOps mówiącej, że należy mierzyć wszystko. Zastosowanie tej zasady w praktyce przełoży się na szereg korzyści.
Po pierwsze, dzięki niej będzie można analizować trendy w długim okresie, np. sprawdzać ilość wykonywanych dziennie kompilacji teraz i miesiąc temu, czy zdecydować o zwiększeniu lub zmniejszeniu zasobów (przeskalowaniu infrastruktury) w zależności od aktualnych potrzeb.
Po drugie, zbieranie wszelkich dostępnych metryk umożliwi nam przeprowadzenie analizy porównawczej danych na przestrzeni określonego czasu. Będziemy mogli na przykład sprawdzić, czy aktualnie przeprowadzone wdrożenie jest szybsze niż to wykonane w poprzednim tygodniu czy miesiącu.
Możliwość utworzenia alertów to trzecia korzyść wynikająca bezpośrednio z zastosowania założeń DevOps w praktyce. Takie alerty będą nas powiadamiać o tym, że coś przestało działać albo wkrótce przestanie działać. Ponadto możemy zdefiniować alerty, które będą nas informować, czy wdrożony właśnie proces CI/CD przechodzi testy, czy może należy wycofać ostatnie wdrożenie.
Nikogo nie trzeba również przekonywać, że bezpieczeństwo naszych aplikacji ma kluczowe znaczenie. Przeprowadzenie statycznej analizy bezpieczeństwa aplikacji w celu wykrycia potencjalnych luk w zabezpieczeniach czy krytycznych błędów w kodzie może nam zaoszczędzić poważnych problemów technicznych, ale również finansowych i biznesowych. Taka analiza umożliwia wykrycie takich potencjalnych zagrożeń bezpieczeństwa, jak na przykład używanie komponentów z lukami w zabezpieczeniach, niewystarczające zabezpieczenie danych wrażliwych, czy niewystarczającego monitoringu i zbieranie informacji będące przyczyną późnego wykrycia naruszeń bezpieczeństwa.
Wreszcie po piąte, równie ważna dla nas będzie także możliwość wykonywania doraźnych analiz retrospektywnych i sprawdzania, na przykład, czy opóźnienie nagle wyraźnie się zwiększyło i czy to zwiększenie opóźnienia jest jakoś związane z innymi zdarzeniami, które miały miejsce w tym samym czasie.
Ciągłe monitoring i obserwowalność powinny stanowić podstawę przy wdrażaniu procesu CI/CD. W ten sposób można zapewnić właściwe działanie, niezawodność i wydajność aplikacji i infrastruktury w każdej fazie cyklu operacyjnego DevOps.
Monitoring a obserwowalność
Rozmawiając o monitoringu, trzeba zestawić ten termin z obserwowalnością. Nie jest ona na pewno substytutem monitoringu, ani tym bardziej nie sprawia, że ciągły monitoring przestaje być potrzebny. Te pojęcia są komplementarne względem siebie i służą osiągnięciu różnych celów.
Monitoring polega na zbieraniu, przetwarzaniu, grupowaniu i wyświetlaniu w czasie rzeczywistym danych jakościowych na temat danego systemu. Ma to na celu określenie, czy ten
system działa poprawnie i rozwiązanie ewentualnych problemów. Można gromadzić różne typy danych: ilość i typ zapytań, ilość i typ błędów, czas przetwarzania/działania, zdarzenia, logi. Monitoring nie jest jednak ważny tylko ze względu na zbierane dane, ale również dlatego, że dane wygenerowane przez systemy i aplikacje można przełożyć na konkretną wartość biznesową.
Jeśli monitoring jest prowadzony poprawnie, dzięki niemu jesteśmy w stanie uzyskać dane na temat doświadczeń użytkownika. Można je następnie przełożyć na działania biznesowe, aby mieć pewność, że klienci otrzymają dokładnie to, czego oczekują. Obserwowalność to właściwość pozwalająca określić stan wewnętrzny systemu na podstawie jego zewnętrznych wskaźników. Aby ją zapewnić, podczas projektowania, tworzenia, testowania, wdrażania, działania, monitorowania i utrzymywania takiego systemu należy uwzględnić następujące założenia:
- Żaden skomplikowany system nie działa w 100% poprawnie.
- Systemy rozproszone są trudne do przewidzenia.
- Nie można przewidzieć wszystkich potencjalnych usterek, które mogą wystąpić w systemie.
- Usterki są czymś normalnym w każdej fazie cyklu projektowania oprogramowania.
- Łatwość debugowania to postawa przy utrzymywaniu i rozbudowie niezawodnych systemów.
Biorąc pod uwagę powyższe założenia, można śmiało powiedzieć, że o zapewnieniu obserwowalności należy pamiętać już na wczesnym etapie projektowania systemu. Dzięki temu można będzie uzyskać dokładny wgląd w działanie systemu wraz z odpowiednim kontekstem, który ułatwi debugowanie.
Monitoring i obserwowalność
Jak widać z powyższych definicji, obserwowalność stanowi element komplementarny w stosunku do monitoringu. Umożliwia ona uzyskanie nie tylko dokładnego wglądu w stan systemu, ale również szczegółowych informacji na temat niejawnego trybu awaryjnego. Ponadto, jeśli obserwowalność jest właściwością danego systemu, to można uzyskać osadzone w szerokim kontekście dane na temat jego działania. Dane te pozwolą nam wykryć potencjalne głębsze, systemowe problemy.
Rys. 1 Ciągły monitoring i obserwowalność w procesie CI/CD
Korzystanie z monitoringu i obserwowalności jako nierozłącznych elementów daje jeszcze jedną, bardzo znaczącą korzyść. Tylko system, który jest obserwowalny umożliwia zbieranie danych za pomocą narzędzia do monitoringu. Następnie dane te można poddać ręcznej lub automatycznej analizie. Bez prawidłowo przeprowadzonej analizy monitoring i obserwowalność nie mają sensu. Im większe mamy możliwości analizy, tym większy zwrot z inwestycji w budowanie obserwowalnego systemu, który można monitorować.
Różne podejścia do monitoringu
Podczas oceniania, na ile dane rozwiązanie do monitoringu jest dojrzałe, często można natknąć się na takie określenia jak „reaktywny‟ (ang. reactive) lub „proaktywny‟ (ang. proactive). Nie musi to oznaczać, że jedno z nich jest lepsze niż drugie. Chodzi tutaj raczej o określenie tego, jak bardzo skomplikowane jest wdrożenia każdego z tych podejść. Jeśli celem jest stworzenie efektywnego rozwiązania, należy zastosować kombinację obu tych podejść, wybierając ich najlepsze cechy.
Przed pojawieniem się modelu DevOps monitoring reaktywny był tworzony i wdrażany przez zespoły operacyjne (ang. operations teams). Samo rozwiązanie do monitoringu było zazwyczaj oparte na mechanizmach automatyzacji, ale duża część komponentów systemu lub aplikacji nie była nimi objęta. Z tego powodu wiele czynności musiało być wykonywanych
ręcznie, np. trzeba było pisać niestandardowe skrypty, które z czasem stawały się trudne do utrzymywania. Duża liczba zaległych powiadomień, reguły alertów oparte na prostych wartościach progowych, niezmienne konfiguracje do sprawdzania i niezmienna architektura — to wszystko było powszechnie uważane za standard.
W podejściu reaktywnym aktualizacje systemu do monitoringu wynikały z reakcji na zdarzenia i awarie. Takie podejście było więc użyteczne po tym, jak doszło do zdarzenia, ponieważ umożliwiało ono zgromadzenie i zapisanie metryk w czasie rzeczywistym. Tych metryk można było później użyć do analizy danych historycznych. Na podstawie takiej analizy wprowadzano usprawnienia, które miały zapobiec powtórzeniu się tej sytuacji w przyszłości.
Podejście proaktywne jest natomiast powszechnie stosowane przez organizacje, które już wdrożyły kulturę DevOps. Jest ono typowe dla firm opierających swoją działalność na obecności w sieci, jak Netflix czy Amazon, oraz dla wielu startupów.
Monitoring proaktywny jest wciąż wykonywany głównie przez zespół operacyjny. Jednak odpowiedzialność za zapewnienie odpowiedniego poziomu monitoringu aplikacji i usług powinna należeć do programistów. To oni mają najlepszy wgląd w tworzone przez siebie produkty. Co więcej same produkty nie powinny być wdrażane do produkcji bez upewnienia się, że zapewniono im obserwowalność i możliwość monitoringu.
Włączenie programistów do procesu definiowania celów monitoringu zapewne doprowadzi do tworzenia testów, które będą bardziej koncentrować się na aplikacjach. Programiści będą raczej kłaść nacisk na wydajność i efekt biznesowy niż na standardowe problemy, takie jak pojemność dysku czy użycie procesora. Zebrane dane będą częściej używane do analizy i rozwiązywania problemów. Proces generowanie alertów będzie posiadał odpowiedni kontekst i prawdopodobnie obejmie eskalacje, odpowiedzi automatyczne, podręczniki z opisem rozwiązania poszczególnych problemów, czy nawet uruchamianie funkcji samoleczenia.
Proaktywność przynosi również wartość dodaną, która na pierwszy rzut oka nie jest oczywista. Chodzi o możliwość skupienia się na mierzeniu jakości usługi i doświadczeń klienta. Dane zebrane dzięki rozwiązaniu do monitoringu można przy pomocy narzędzi do wizualizacji przedstawić głównym interesariuszom, na przykład działom biznesowym lub zespołom zajmującym się aplikacjami. W dłuższej perspektywie tych danych można użyć jako uzasadnienia wydatków budżetowych, kosztów czy nowych projektów.
Automatyzacja w ciągłym monitoringu i obserwowalności
Automatyzacja jest jednym z kluczowych składników efektywnego procesu CI/CD. Z tego powodu zautomatyzowanie monitoringu i obserwowalności ma jak najbardziej sens. Idee te stanowią logiczne następstwo filozofii stojącej za CI/CD. Należy je zautomatyzować w taki sam sposób, w jaki zostały zautomatyzowane integracja, testowanie i wdrożenie. W dynamicznych i skalowalnych środowiskach cały proces monitoringu musi dostosowywać się do ciągłych zmian bez konieczności każdorazowej ręcznej konfiguracji. Aby to osiągnąć, należy zdefiniować, jakie możliwości muszą posiadać użyte technologie.
Trzeba tutaj przede wszystkim wspomnieć o automatycznym wykrywaniu i rejestrowaniu usług (ang. automatic service registration and discovery), Służą do tego takie
narzędzia, jak na przykład Consul, Apache Zookeeper, Eureka. Protokół wykrywania usług (ang. service discovery protocol — SDP) jest standardem sieciowym i wykrywa urządzenia oraz usługi w sieci. Zasadniczo wykrywanie usług pozwala na zmniejszenie liczby błędów popełnianych przez człowieka podczas ręcznej konfiguracji. Istnieją dwa typy wykrywania usług: po stronie serwera i po stronie klienta. Wykrywanie usług po stronie serwera umożliwia aplikacjom klienckim znalezienie usług za pośrednictwem routera lub load balancera. Z kolei wykrywanie usług po stronie klienta umożliwia aplikacjom klienckim znalezienie usług poprzez wyszukiwanie w rejestrze usług, w którym znajdują się instancje serwera i punkty końcowe.
Następną rzeczą jest automatyczna instrumentacja i monitoring komponentów aplikacji (OpenTracing i OpenCensus, po scaleniu z OpenTelemetry). Instrumentacja to proces, w wyniku którego kod aplikacji jest rozszerzany tak, aby gromadzić i raportować dane (ang. trance spans) dotyczące interesujących nas konkretnych operacji, takich jak zapytania użytkownika lub transakcje.
Automatyczna instrumentacja jest zwykle wdrażana przez dodanie oprogramowania pośredniczącego umożliwiającego dodanie mechanizmu instrumentacji do ważnych części kodu. Typowym przykładem jest oprogramowanie pośredniczące związane z żądaniem HTTP, które mierzy czas spędzony na wygenerowaniu odpowiedzi, jak również zawiera informacje na temat samego żądania i odpowiedzi, takie jak kod statusu i fragment przesyłanych danych. Dzięki temu można łatwo zebrać dane telemetryczne i rozproszone ślady (ang. distributed traces) z usług.
Ostatnią rzeczą, o której trzeba wspomnieć, to automatyczne alerty dotyczące problemów z infrastrukturą i wydajnością aplikacji (AlertManager, PagerDuty). Efektywny mechanizm alertów stanowi dopełnienie procesu ciągłej integracji i ciągłego dostarczania. Ma on kluczowe znaczenie przy tworzeniu produktu i szybkim jego wdrażaniu. Użycie wbudowanych alertów pozwala wykrywać usterki lub nietypowe zdarzenia, zaś połączenie alertów z elementami webhook umożliwia proaktywne rozwiązywanie problemów po ich wykryciu.
Dodanie automatyzacji do rozwiązania zapewniającego ciągły monitoring to sprawne i płynne działanie procesów CI/CD. Będziemy mogli szybciej wdrażać kod, mając pewność, że usługi są monitorowane. Dzięki temu inżynierowie będą mogli szybko rozwiązywać pojawiające się problemy.
Podsumowanie
Trendy w biznesie i technologii zmieniają się obecnie bardzo szybko. Lepsza komunikacja między wszystkimi osobami zaangażowanymi będąca jednym z postulatów metodologii DevOps może przełożyć się na konkretne korzyści biznesowe. Chodzi tutaj przede wszystkim o szybsze wdrażanie oprogramowania i zapewnienie jego wysokiej jakości.
Ciągły monitoring i obserwowalność zapewniają odpowiedni wgląd w infrastrukturę i proces CI/CD przez cały cykl rozwoju oprogramowania. W ten sposób można w dowolnym momencie sprawdzić, czy środowisko działa poprawnie. Dzięki temu również zlikwidowaniu ulegają bariery w komunikacji między zespołami programistów i operacyjnymi, co oznacza praktyczną realizację założeń modelu DevOps.
O autorze
Damian Fedeczko - pracuje w CodiLime na stanowisku DevOps Engineer. Zajmuje się automatyzacją infrastruktury i utrzymywaniem systemów informatycznych. Jego pasją jest piłka nożna oraz uczenie się nowych technologii. Marzy o zwiedzeniu świata.