Czym jest observability w DevOps? Praktyczny przewodnik

Czym jest observability w DevOps? Praktyczny przewodnik

09/12/2022
Podziel się

W ostatnich latach DevOps stał się najpopularniejszą metodyką rozwoju oprogramowania w cyfrowym świecie. Wiele firm z powodzeniem zaadoptowało praktyki DevOps do tworzenia i dostarczania wysokiej jakości oprogramowania, szybko i bezpiecznie. Jest jednak pewien ważny element znacząco wpływający na skuteczność DevOps, którego nie można przeoczyć – observability (obserwowalność). W artykule wyjaśniamy, jaką rolę pełni observability w DevOps i jak może pomóc w wykorzystaniu pełnego potencjału tej metodyki.

Spis treści:

Czym jest observability?

Observability jest zdolnością do definiowania stanu wewnętrznego złożonych systemów, na podstawie ich zewnętrznych danych wyjściowych. Określeniem ‘system’ posługujemy się, opisując zbiór elementów tworzących środowisko informatyczne lub aplikację oraz zależności między nimi.

Można powiedzieć, że system jest obserwowalny, kiedy zbieranie i przetwarzanie pochodzących z niego danych daje możliwość zbadania i zrozumienia:

  • jak ten system działa;
  • jakie problemy występują w systemie;
  • jak występujące problemy wpływają na działanie systemu.

Trzy filary observability

Logi, metryki i ślady (ang. traces) nazywane są trzema filarami observability – każdy z nich zapewnia wgląd w stan systemu z innej perspektywy. Łączne wykorzystanie wspomnianych trzech filarów, pozwala zobrazować stan całego systemu we wszystkich jego warstwach: aplikacyjnej, integracyjnej, bazodanowej, systemowej oraz sprzętowej. Zapewnia także skuteczne wykrywanie oraz rozwiązywanie pojawiających się w nim problemów.

Logi

Observability jest stosowane przede wszystkim w celu zrozumienia stanu wewnętrznego systemu oraz procesów w nim zachodzących. Pozwalają na to zebrane logi, czyli chronologicznie uporządkowane informacje o zdarzeniach, które miały miejsce w systemie. Składają się one ze znacznika czasowego (ang. timestamp) oraz opisu zdarzenia.

Metryki

Obok logów, ważną rolę odgrywają również metryki. Metryka jest opisem ogólnego zachowania danego komponentu systemu. Dane z metryk zapisywane są w postaci klucz – wartość oraz etykieta, która nadaje im kontekst.

Ślady (ang. traces)

Ostatnim elementem dającym wgląd w procesy zachodzące w systemie są ślady (ang. traces). Dzięki nim możliwe jest określenie drogi, którą dane pokonują w systemie.

Observability w DevOps

DevOps jest kulturą pracy, opartą na stałej komunikacji zespołów zajmujących się wytwarzaniem oprogramowania (ang. development) oraz zarządzaniem systemem (ang. operations). Zespoły DevOps, które chcą efektywnie rozwijać swoje produkty muszą posiadać pełny wgląd w ich stan – zarówno podczas ich tworzenia, jak i wdrażania.

W celu skutecznej realizacji metodyki CI/CD (ang. Continuous Integration and Continuous Delivery) potrzebna jest wiedza, jaki wpływ na aplikację mają wprowadzane do niej zmiany. Systematyczne przechodzenie z prostych, monolitycznych struktur aplikacji, na rozproszone, oparte o wiele serwisów, sprawia, że zwykły monitoring podstawowych metryk przestaje wystarczać. Błędy pojawiają się znacznie częściej, a jednocześnie znacznie rzadziej ich przyczyna jest łatwa do określenia.

Głównym założeniem metodyki DevOps jest szybkie dostarczanie wytworzonego oprogramowania. Jeśli błąd w systemie nie jest rozumiany, nie można go sprawnie rozwiązać, co przekłada się na opóźnienia w dostarczaniu nowych, innowacyjnych rozwiązań. Aby podejście DevOps było skuteczne, zespoły powinny mieć pełny wgląd w system. Tylko możliwość kontroli zdarzeń w momencie umożliwiającym naprawę błędu lub prewencję, daje pełną kontrolę nad rozproszonymi systemami – na tym właśnie pomaga observability.

Dlaczego obserwowalność jest kluczowa dla DevOps?

Tworzone dawniej systemy o strukturze monolitycznej były stosunkowo proste w nadzorowaniu. Przewidywanie potencjalnych obszarów awarii nie stanowiło większego problemu. Zbieranie danych z podstawowych metryk systemowych, takich jak zużycie dysku czy procesora, w większości przypadków wystarczało do tego, żeby zlokalizować i rozwiązać usterkę.

Złożoność współczesnych systemów informatycznych sprawia, iż coraz trudniej wykryć, zrozumieć, naprawić, a także zapobiegać występującym w nich awariom. W przeciągu ostatnich lat wiele systemów zostało przekształconych na oparte o chmurę mikroserwisy. Są one rozwijane i wdrażane przez zespoły DevOps w bardzo szybkim tempie. Takie działanie jest wygodne oraz innowacyjne, ale sprawia, że pojawia się wiele nowych, często zupełnie niezrozumiałych błędów.

W systemach opartych o cloud native również występują wcześniej niespotykane utrudnienia, którym muszą sprostać zespoły DevOps. Do najczęstszych należą problemy w komunikacji między serwisami aplikacji oraz różnica pomiędzy wersjami oprogramowania w poszczególnych segmentach systemu. W dzisiejszych czasach możliwych przyczyn problemu jest wiele i znalezienie ich źródła bez zastosowania odpowiednich metod i narzędzi często mija się z celem.

Observability pozwala znaleźć odpowiedzi na pytania dotyczące systemu. Wykrywa trudne do wychwycenia błędy i przyspiesza ich naprawę. Szybkie rozwiązywanie problemów z systemem jest niezwykle istotne. Pojedyncza usterka, która nie zostanie naprawiona, może za sobą pociągnąć kolejne, a pozostawiony w systemie błąd sprawia, że efektywność praktyk DevOps w organizacji maleje.

Korzyści z observability w DevOps

Wdrożenie observability systemu zapewnia wiele korzyści.

Pełny wgląd w działanie systemu i zachodząc w nim procesy

Dla zespołów DevOps najważniejsze jest zrozumienie systemów produkcyjnych, a w tym obszarze observability jest niezwykle pomocne. Główną korzyścią i celem stosowania observability jest bowiem uzyskanie pełnego wglądu w działanie systemu, a także zachodzące w nim procesy.

Zapobieganie problemom w systemie i zmniejszenie czasu potrzebnego na ich rozwiązanie

Kolejną wartością płynącą z observability, niezwykle istotną dla zespołów DevOps jest  skrócenie czasu potrzebnego na rozwiązywanie problemów w systemie oraz możliwość zapobiegania im. Przekłada się to na zmniejszenie parametrów MTTD (ang. Mean Time To Detection) oraz MTTR (Mean Time To Resolve). Jest to możliwe dzięki dogłębnej analizie danych systemowych. Anomalie występujące na przykład w wartościach metryk, mogą świadczyć o tym, że będzie miała miejsce usterka, a wykrycie anomalii odpowiednio wcześniej, pozwala na odpowiednią prewencję. Cecha ta jest niezwykle istotna w kontekście ciągłości działania systemu.

Zrozumienie dlaczego problem wystąpił i jak go rozwiązać

Jeśli jednak nie uda się zapobiec wystąpieniu awarii i trzeba ją naprawić, kluczowe jest zrozumienie problemu. Observability daje nie tylko możliwość sprawdzenia, w którym miejscu problem wystąpił, ale także pozwala zrozumieć, dlaczego problem wystąpił i jak można go rozwiązać. Zespoły DevOps mogą dzięki temu skupić się na rozwiązywaniu problemu w systemie, zamiast angażować swój czas w poszukiwanie jego przyczyn.

Zwiększenie automatyzacji i wydajności

Observability pozwala na lepszą kontrolę systemu, co przekłada się na zwiększenie automatyzacji i wydajności.

Przydatne rozwiązania w zakresie technik inżynieryjnych

Przykładowe techniki inżynieryjne, w których observability jest niezwykle ważnym elementem.

1. Feature toggles

Jednym z przykładów jest feature toggles – technika pozwalająca zespołom developerskim na modyfikację działania systemu bez potrzeby zmiany kodu źródłowego. W przypadku jej wykorzystywania observability jest niezbędne, aby dobrze zrozumieć wpływ każdej funkcjonalności, ale również ich zbioru na działanie aplikacji dla każdego użytkownika.

Pojęcie monitorowania zachowania komponent po komponencie nie ma już racji bytu, ponieważ endpoint może wykonywać się na wiele sposobów w zależności od tego, przez którego użytkownika jest wywoływany.

2. Chaos engineering

Chaos engineering to technika polegająca na nieustannym eksperymentowaniu z systemem, w celu nabycia przez niego odporności do pracy w różnych, często ekstremalnych warunkach.

W tym przypadku, aby możliwe było ciągłe monitorowanie stanu systemu w miarę wykonywania na nim eksperymentów, wdrożenie observability również okazuje się niezbędne. Bez observability nie byłoby możliwości stwierdzenia stanu wyjściowego systemu oraz wyjaśnienia odchyleń od oczekiwanego zachowania.

3. Blameless postmortem

Observability jest również kluczowe przy wykorzystywaniu tzw. blameless postmortem –  analizy całego toku postępowania podczas incydentu, który miał miejsce w przeszłości.

Technika ta, dzięki wykorzystaniu observability, pozwala zrozumieć specjalistom DevOps co i dlaczego się wydarzyło, a także przeanalizować reakcję zespołu. Celem jest zapobieganie podobnym incydentom w przyszłości lub poprawa reakcji zespołu w sytuacji ich ponownego wystąpienia.

Wprowadzanie innowacji do systemu

Zbierane dane nie służą jedynie wykrywaniu i eliminowaniu błędów. Można je również wykorzystywać do zidentyfikowania takich przestrzeni w systemie, do których można wprowadzić innowacje.

Narzędzia observability w DevOps

Pod pojęciem ‘narzędzia observability’ kryją się wszystkie aplikacje, programy i platformy, przeznaczone do ciągłego monitorowania systemów i dostarczania na bieżąco informacji zwrotnych o ich stanie. Pomimo tego, że observability jest nowym podejściem i wciąż zyskuje na popularności, rynek oferuje w tym obszarze całkiem sporo narzędzi. W takim razie, które narzędzie jest najlepsze? Na to pytanie nie ma jednoznacznej odpowiedzi. Do każdego systemu należy dobrać narzędzie indywidualnie, uwzględniając wiele czynników, m.in. w jakim stopniu narzędzie będzie pomocne podczas pracy z danymi. Im więcej funkcjonalności oferuje, tym lepiej.

Dowiedz się więcej w artykule: Observability – przegląd najpopularniejszych narzędzi

Wdrażanie observability – na co warto zwrócić uwagę

  1. Skuteczne wdrożenie observability nie jest łatwym zadaniem i wymaga w pierwszej kolejności odpowiedniego przygotowania systemu. Zaleca się odejście od koncepcji tworzenia systemów zorientowanych na poszczególne komponenty i przyjęcie jednolitego podejścia w obrębie całego systemu. Celem observability jest bowiem zrozumienie, jak funkcjonuje system właśnie jako jedna całość.
  2. Kolejnym krokiem jest określenie celu wdrożenia observability. W tym miejscu warto skupić się na zdefiniowaniu typów i źródeł danych, które są najistotniejsze dla funkcjonowania systemu – to znaczy takich, których analiza umożliwia skutecznie zapobieganie błędom, a także ich wykrywanie i naprawianie (gdy błędy wystąpią).
  3. Dla zespołów DevOps ważne również te dane, dzięki którym można przeprowadzać ulepszenia systemu i pozytywnie wpływać na jego wydajność. Należy przy tym właściwie ocenić czy dane, które są zbierane, mają jakąkolwiek wartość dla systemu. Gromadzenie dużej ilości niepotrzebnych danych jest niepożądaną praktyką, która znacząco zmniejsza efektywność observability.
  4. Po określeniu, które dane będą zbierane i analizowane, można przystąpić do opracowania skali pożądanych wartości oraz progów, po których przekroczeniu, dany wskaźnik będzie uznany za nieprawidłowy. Zbierane dane powinny być odpowiednio indeksowane, tak aby indywidualny rekord mógł być szybko odnajdywany, bez konieczności przeglądania setek lub tysięcy niepowiązanych rekordów.
  5. Podczas zbierania danych, należy położyć nacisk na istotny aspekt, jakim jest sam sposób przesyłu danych. Dane pobierane ręcznie nie informują o aktualnym stanie systemu tak dobrze jak te przekazane na przykład za pomocą data forwardera, który przesyła dane na bieżąco w czasie działania systemu, stosując odpowiedni format.
  6. Co więcej, zbierane dane muszą być odpowiednio analizowane pod kątem zapobiegania i wykrywania błędów, a także lokalizacji miejsc w systemie, które warto ulepszyć pod względem wydajności.
  7. Przy interpretacji danych pomocne okazują się wizualizacje, na przykład w postaci tabel, wykresów czy diagramów, a także odpowiednie przefiltrowanie danych w celu wyłuskania rekordów, które dotyczą kluczowych przestrzeni w systemie.

Wdrażanie observability – jak uniknąć typowych błędów

  1. Najczęstszym błędem jest stosowanie podejścia observability bez wykorzystania odpowiednich narzędzi – tylko praca z odpowiednim narzędziem zapewnia efektywne observability.
  2. Oprogramowania przeznaczone do pracy z danymi powinny oferować szeroki zakres funkcjonalności, co daje użytkownikom swobodę działania. Do najważniejszych należą:
    • niezawodny system zbierania danych;
    • możliwość dowolnego przeszukiwania zebranych danych przy pomocy filtrowania, kategoryzowania czy priorytetyzowania;
    • wizualizacja danych;
    • mechanizmy alertujące w przypadku wystąpienia błędów w systemie.
  3. Niezwykle ważnym ogniwem wpływającym na to, w jakim stopniu narzędzia observability będą pomocne w zarządzaniu systemem, są korzystający z tych narzędzi pracownicy. Brak odpowiednich szkoleń dla zespołu sprawia, że pełny potencjał observability nie jest wykorzystywany.
  4. Dobrą praktyką jest również wykorzystywanie i posiłkowanie się danymi wyjściowymi z narzędzi observability na spotkaniach firmowych, a co za tym idzie podnoszenie umiejętności i świadomości zespołu w tym zakresie.
  5. Kolejnym błędem przy wdrażaniu observability jest niewłaściwa dystrybucja danych w organizacji. Dane z systemu powinny być przekazywane nie tylko zespołom DevOps, ale również wszystkim developerom pracującym przy systemie. Takie działanie poprawia  dystrybucję danych w firmie, co przekłada się na szybsze rozwiązywanie problemów.
  6. Innym, często popełnianym błędem jest ignorowanie zgłoszeń alertów. Przyczyną tego może być dostarczanie wszystkich alertów dotyczących całego zespołu jedną drogą, jak również słaba jakość systemu ostrzegania. Zapobiec temu można np. poprzez używanie różnych dróg przekazywania informacji o alarmach do zespołu.
  7. Ponadto odradzaną praktyką jest ignorowanie alertów mówiących o przyczynie problemu i priorytetyzacja alertów wskazujących, których miejsc problem dotyczy. Niewskazane jest też pisanie alertów dla każdego możliwego błędu w systemie z równoczesnym pominięciem ich możliwej przyczyny.

Podsumowanie

Rozwój systemów informatycznych sprawia, że coraz trudniej jest je kontrolować. Wdrożenie podejścia observability i wykorzystanie odpowiednich narzędzi pomaga zespołom DevOps:

  • zbierać, korelować i analizować duże ilości danych dotyczących wydajności pochodzących z rozproszonych aplikacji;
  • uzyskiwać wgląd w funkcjonowanie aplikacji w czasie rzeczywistym.

Dzięki temu, zespoły DevOps mogą skuteczniej monitorować, modernizować i ulepszać aplikacje, w celu szybszego dostarczania nowych produktów i poprawy doświadczeń klientów.

Jeśli chcesz dowiedzieć się więcej, jak observability może pomóc w wykorzystaniu pełnego potencjału DevOps, skontaktuj się z naszymi ekspertami

Zobacz również

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

    Skontaktuj się z nami