Obserwowalność
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Obserwowalność [TEN ARTYKUŁ]
W ostatnim artykule przyglądaliśmy się temu, jak na stabilność i niezwodność produktu wpływa niezawodność. Dziś kontynuujemy ten temat od strony obserwowalności.
Gdy produkt nie ma podstaw
W świecie technologii, produkty cyfrowe wymagają solidnych podstaw zarówno w zakresie niezawodności, jak iobserwowalności. Brak tych fundamentów sprawia, że tworzenie projektu zaczyna przypomina budowanie domu na piasku: prędzej czy później, wszystko zacznie się walić.
Produkty, którym brakuje niezawodności nieodmiennie borykają się z przestojami, błędami i innymi nieoczekiwanymi zdarzeniami. System przestaje działać nagle, pozornie bez konkretnego powodu za tym stojącego. Zawieszki zdarzają się podejrzanie często, a błędy się nawarstwiają. Małe opóźnienie eskaluje do poważnego i trudnego do naprawienia zatrzymania pracy systemu.
W takich sytuacjach zespoły inżynierskie spędzają nieproporcjonalnie dużo czasu na gaszeniu pożarów, zamiast na rozwijaniu produktu. Jak opowiadał Aaron Rinehart w ramach Chaos Days:
Zespoły produktowe są zmuszone do ciągłego rozwiązywania problemów. Każda aktualizacja lub nowa funkcjonalność wiążą się z potencjalnym ryzykiem. A to tworzy atmosferę niepewności i strachu przed wprowadzaniem zmian.
Z drugiej strony brak obserwowalności powoduje sytuację przypominającą prowadzenie samochodu z opaską zawiązaną na oczach. Organizacja nie wie, co się dzieje w ich systemie. Identyfikowanie i rozwiązywanie problemów stają się niemal niemożliwe. Zespoły nie reagują efektywnie ani nie uczą się na błędach. Klienci doświadczają problemów, których nikt nie wykrył. Albo, co gorsza, problemy są ignorowane, aż do momentu, gdy stały się na tyle duże, że ich rozwiązanie wymaga znacznych zasobów.
Brak tych praktyk nie tylko utrudnia codzienną pracę, ale również odbija się na zyskach organizacji. Wydaje nam się, że pracujemy na 100%, a jednak - wyniki są prawie zerowe. Brak niezawodności i obserwowalności nie jest więc tylko problemem technicznym, ale staje się problemem biznesowym - może decydować o przetrwaniu firmy na rynku.
Wspaniale oddaje to cytat z State of DevOps Report z 2022:
When reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes.
Firmy dobrymi praktykami postępują inaczej.
Przykład z branży
W dzisiejszym wydaniu newsletteru, przykładem podzielił się Paweł Dawidowicz - Head of SRE w Ramp:
Q: Jakie macie praktyki dookoła niezawodności i obserwowalności?
A: Na początku skupiliśmy się, aby zrozumieć jakie procesy biznesowe są kluczowe dla osiągnięcia wymaganej wysokiej niezawodności. A następnie dla nich poznać pożądaną jakość, jakiej oczekują klienci i biznes. Wtedy wypracowaliśmy praktyki infrastrukturalne (np. Multi-Zone), programistyczne (np. Graceful Shutdown), wdrażania (np. pełny Continuous Deployment), które wbudowaliśmy w nasze rozwiązania. Wszystko to jest otoczone szeroką siecią metryk i logów, dzięki czemu widzimy i możemy zawczasu obserwować co nie działa.
Aby to zrealizować, poświęcamy dużo czasu pracy typowo zespołowej. Przeprowadzamy sesje brainstormingu z zespołami developerskimi, aby wbudowywać niezawodność w aplikację. Procesy zarządzania incydentami pozwalają nam stabilnie rozwiązywać nieprzewidywalne problemy. Inżynierzy jakości współpracują przy definiowaniu odpowiednich wymagań jakościowych. Uczymy osoby techniczne i biznesowe jak korzystać z narzędzi obserwowalności.
Nie wszystkie praktyki można od razu wdrożyć, więc mierzymy siły na zamiary. Wdrażamy to co jest aktualnie największą bolączką niezawodności systemu.Q: Jakie to benefity daje dla zespołu i organizacji?
A: Powyższe praktyki pozwoliły nam przyśpieszyć rozwiązywanie awarii i im zapobiegać w przyszłości. Mniej awarii zaś sprawia, że mamy więcej czasu na development funkcji biznesowym. Proces wdrażania na produkcję jest prawie bezbolesny – chcemy mieć nową funkcję to ją wdrażamy. Możemy też wychodzić na szersze rynki i proponować klientom jeszcze lepszą jakość i dostępność.
Prywatnie zaś największy benefit jest taki, że mogę spać spokojnie. Wiemy, że nasz system obsłuży 99% problemów jakie się pojawią. Robię update i wierzę, że nic się nie wywali. Z aplikacją żyje się łatwiej.
Praktyki dookoła obserwowalności
Rozpoczniemy od mema:
Obserwowalność trzeba zaplanować i wdrożyć. No niestety, taka jest prawda, nie da się jej kupić na straganie. Gdy na ślepo wdrażamy narzędzie do obserwowalności, to nasze koszta rosną znacząco, ale nic nie zyskujemy. Pozdrawiam wszystkich użytkowników DataDog😉.
Jeśli odrobiliśmy naszą lekcję o ścieżce krytycznej, to wiemy, co jest dla nas istotne. Jeśli odrobiliśmy lekcję o pożądanym poziomie niezawodności, to rozumiemy, jak ocenić, czy najważniejsze procesy działają, czy nie. Pozostaje nam tylko zaplanować obserwowalność dookoła tych procesów.
Obserwowalność – Observability
Aby lepiej nakreślić, czym charakteryzuje się obserwowalność, posłużymy się inną osobistością z branży. Dookoła obserwowalności nie sposób przecież nie zacytować CTO Honeycomb Charity Majors. W wywiadzie „What is observability…" , opisała ją w ten sposób:
Observability was just the ability to understand what’s going on in the inner workings of the system by observing it from the outside.
Czyli, w mowie ojczystej, obserwowalność to zdolność do zrozumienia stanu wewnętrznego systemu na podstawie tego, co widać z zewnątrz. Patrzymy na naszt system i na podstawie tylko i wyłącznie zaobserwowanych informacji jesteśmy w stanie zrozumieć, co i jak.
Idąc dalej można zacytować jeszcze definicję ze strony Honeycomb Learn about Observability:
We say that a system is “observable” to the extent that you can explain what is happening on the inside just from observing it on the outside, preferably without having to add new, special-case instrumentation to get your new question answered.
Czyli: przy wysokim poziomie obserwowalności, do diagnozy pracy systemu, nie potrzebujemy żadnego specjalnego hakowania. Patrzymy i już - mamy pełen pakiet informacji, które pokazują nam, co się dzieje. Zamiast działać post-factum, działamy więc pre-factum.
Do tematu można jeszcze dodać słowa z książki Achieving Observability:
Observability isn’t just for operations folks or just for “production incident response.” It’s also for answering the day-to-day questions we have about our systems, so the people who build and maintain the systems can form hypotheses, validate hunches, and make informed decisions all the time and not just when an exception is thrown, or a customer complains.
Czyli obserwowalność jest skupiona również na tym, aby pomóc nam w codziennych pracach zespołowych. Dzięki obserwowalności możemy budować lepsze zrozumienie tego w jaki sposób nasi klienci wykorzystują nasz system.
Praktyki dookoła obserwowalności
Wybór elementów mierzenia
Warto rozpocząć od kategoryzacji tego, jakie informacje możemy analizować. Na informacje zbierane można spojrzeć z dwóch stron – wewnętrznej i zewnętrznej tzw. white-box i black-box:
White box – dane oparte na metrykach udostępnianych przez elementy wewnętrzne systemu (event logs, interfaces, RAM, HTTP errors). Pozwalają wykryć bezpośrednie problemy, awarie maskowane przez ponowne próby i tak dalej.
Black box – informacje oparte na zachowaniach widocznych z zewnątrz, z perspektywy użytkownika. To podejście jest zorientowane na objawy i przedstawia aktywne, a nie przewidywane problemy: „System nie działa obecnie poprawnie”.
W kolejnym kroku chcemy dokładnie zrozumieć, jakie elementy wchodzą w skład naszej ścieżki krytycznej. Celowo mówię tutaj szeroko o elementach – to mogą być aspekty programistyczne (serwisy aplikacyjne, fasady zapytania zewnętrzne), ale też infrastrukturalne (baza danych, aplikacja, klaster).
W pojęciu tego konceptu, pomaga odpowiednia wizualizacja. Przykład takiej, w kontekście aplikacji do zarządzania produktami, znajdziesz w artykule Health modeling and observability od Microsoftu:
Już na pierwszy rzut oka możemy dostrzec zależności pomiędzy poszczególnymi elementami ścieżki krytycznej.
Następnie łączymy oba zbiory informacji (co możemy zbierać i co chcemy obserwować) i przekładamy na konkretne aspekty procesu, które chcemy monitorować. Zwykle są to aspekty:
Programistyczne – czasy wykonania, parametry procesu, błędy, zapytania zewnętrzne i czasy oczekiwania.
Infrastrukturalne – dostępność, wykorzystywane zasoby, błędy, latencja pomiędzy serwisami, przepustowość.
Na koniec łączymy je w bardziej ogólne metryki np.:
Pożądane zużycie dysku / CPU / RAM.
Maksymalny czas przejścia przez proces.
Limit na liczbę wiadomości do obsłużenia.
To podsumowanie niezawodności naszej ścieżki krytycznej.
Następnym krokiem jest wdrożenie mierzenia wybranych aspektów. Rozpoczniemy od prostszej ścieżki:
Wdrażanie mierzenia infrastruktury
Dzisiejsze serwisy infrastrukturalne (czy to chmurowe, czy to dookoła Kubernetesa), w większości pozwalają udostępnić dalej dane o wykonanym działaniu. Możemy je skonfigurować tak, by przesyłały te dane do odpowiedniego narzędzia monitoringu – poniżej przykład dla:
O czym należy pamiętać, wprowadzając to rozwiązanie?
(Przynajmniej na początku) Nie monitorować wszystkiego , co mamy w infrastrukturze, a jedynie to co jest na ścieżce krytycznej.
Dla danych serwisów od razu określić, jakie są pożądane zakresy działania np. aby CPU nie przekroczyło 90%.
Starać się grupować określone logi – zamiast 5 dotyczących uruchamiania serwisu może nam wystarczyć 1 bardziej ogólny.
Więcej wysiłku czeka nas z mierzeniem pracy elementów programistycznych.
Wdrożenie mierzenia aplikacji
Pierwszą i najważniejszą kwestią jest monitorowanie tego, czy w ogóle aplikacja żyje i odpowiada. Zwykle nazywa się to mierzeniem zdrowia aplikacji (health checks). Zgodnie ze standardami Kubernetesa, wyróżniamy tutaj 3 wartości (sondy – probes):
Startup – czy aplikacja w ogóle została została uruchomiona?
Readiness – czy aplikacja jest gotowa do odbierania żądań?
Liveness – czy aplikacja jest w dobrym stanie?
W 95% przypadków odpowiedzi na te pytania są związane z naszą ścieżką krytyczną. Więc, aby zwracać te odpowiedzi do serwisów monitorujących, musimy odpowiednio zaprogramować odpowiedź z naszej aplikacji. Bez tego będziemy zwracać wartości domyślne – nieskupione na tym, jaki cel realizujemy.
Następnie przychodzi kolej na mierzenie procesu biznesowego. W tym celu musimy dodać odpowiednie informowanie w naszym kodzie. Zwykle jest to związane z dodawaniem tzw. . O czym warto pamiętać?
Zadbaj o unikalne identyfikatory żądań – aby dało się połączyć różne informacje w jedną ścieżkę realizacji procesu.
Dodaj do logów dodatkowe informacje techniczne – pozwoli to szybciej znaleźć problemy dotyczące sprzętu, maszyn, serwisów, przeglądarek, wersji SDK.
Dodaj do logów dodatkowe informacje dotyczące procesu – ułatwi to późniejsze grupowanie i poszukiwanie biznesowych przyczyn problemów.
Informuj o wywołaniu zewnętrznej usługi – pozwoli zauważyć jak wiele tych połączeń jest, czasy trwania i potencjalne błędy.
Mogą pojawić się głosy, że zwykle narzędzia do obserwowalności w aplikacjach automatycznie logują informacje o przeprowadzanych procesach. Ale prawdą jest też, że zwykle jest to zdecydowanie za mało, by odpowiadać na kluczowe pytania dotyczące systemu. Może i żyjemy w erze AI, ale w tym wypadku automat wciąż nie odrobi za nas roboty. 🤖
Dashboardy i alerty
Do tworzenia dashboardów i alertów można usiąść dopiero, gdy zadbaliśmy już wszystko opisane wyżej. Inaczej narażamy się na przetestowanie w praktyce niezawodnej reguły shit-in -> shit-out 💩.
Tworzone dashboardy powinny w założeniu natychmiastowo odpowiadać na kluczowe pytania dotyczące niezawodności:
Czy proces działa? Jeśli nie, to co w nim nie działa?
Jaka jest wydajność procesu? Czy jest zgodna z oczekiwaną?
Ile trwa proces? Co w nim trwa najdłużej?
Jakie są najczęstsze błędy i gdzie się znajdują?
Jakie są tendencje i wzorce w wydajności i błędach?
Jeśli odpowiednio logowaliśmy informacje dotyczące procesów, to powinniśmy być również w stanie pogrupować je pod względem wspólnych wymiarów. To natomiast pozwoli zauważyć, że np.
Procesy na konkretnej maszynie idą wolniej.
Procesy z konkretnego kraju się wywalają.
Procesy konkretnego klienta / firmy zwracają błędy.
Pracę z alertami warto rozpocząć od przyswojenia sobie niesamowicie trafnego zdania z książki Site Reliability Engineering:
Monitoring should never require a human to interpret any part of the alerting domain. Instead, software should do the interpreting, and humans should be notified only when they need to take action.
Jeśli chcemy kogoś powiadomić, to powinniśmy przekazać mu dokładną informację, na co zwrócić uwagę. Nie ma chyba nic gorszego niż alerty, które są zbyt ogólne – otwieramy zgłoszenie i wzruszamy ramionami.
O czym jeszcze nie powinniśmy zapominać?
Alerty powinny być połączone z metrykami – limit wiadomości w kolejce to 100, więc informujmy, gdy przekroczyliśmy tą liczbę.
Alertów nie powinno być zbyt dużo – nie można wysyłać alertu na każde jedno drgnięcie metryki. Ludzie się zobojętniają i przestają reagować. Alerty powinny być piorytetyzowane – nie każdy alert musi sprawiać, że od razu porzucamy naszą pracę. Ale część jest dokładnie takimi i trzeba je odpowiednio zaznaczyć.
Na koniec do omówienia pozostają nam praktyki zespołowe.
Jak współpracować
Propagowanie wiedzy
Bardzo trudno jest pracować nad niezawodnością i obserwowalnością, jeśli członkowie zespołu nie znają tych pojęć, oraz tego, co się z nimi wiąże. A także zysków jakie one mogą generować.
Wracając do SLI/SLO/SLA. Członkowie zespołu i interesariusze muszą rozumieć jak ich codzienna praca przekłada się na te miary. Inaczej staje się to pustą praktyką, która nie jest w stanie realizować celów biznesowych. By temu zapobiec, warto skorzystać z branżowych case studies, czy szkoleń poświęconych mierzeniu procesu przez dokładne wskaźniki w produkcie.
Warto też pamiętać, że duża część praktyk dookoła niezawodności nie jest oczywista z perspektywy członków zespołu, a bez pełnego zrozumienia może sprawiać wrażenie uciążliwej. Odpowiednie wyjaśnienie, jak te praktyki wdrożyć i jak nam pomagają, pomoże przekonać do nich zespoły.
Last, but not least, zaskakująco liczna grupa osób nie potrafi korzystać z dashboardów, ani interpretować zawartych tam danych. Aby zacząć sprawnie się nimi posługiwać, potrzebują przynajmniej kilku przykładów, jeśli nie cyklu szkoleń. Nie zastanawiaj się jednak, czy warto. Inwestycja w edukację zwraca się przez większą samodzielność członków zespołu. I większą ilość czasu, kiedy nie musimy za każdym razem klikać i im pokazywać 😉.
Kultura organizacyjna
Podsumowując temat, warto jeszcze dodać dwa słowa o kulturze organizacyjnej dookoła niezawodności i obserwowalności.
Niezawodność i obserwowalność nie są dane raz na zawsze. Trzeba o nie stale dbać i rozwijać. Pojawiają się nowe procesy do wdrożenia. Wykonujemy kolejną integrację z systemem zewnętrznym. Przepisujemy serwisy infrastrukturalne na inne. Każda z tych zmian powoduje istotną zmianę w sposobie działania systemu.
W tak dynamicznym środowisku, każdy pracujący i wykorzystujący produkt członek zespołu, musi być świadomy znaczenia niezawodności. Gdy niezawodność jest powszechnie ceniona, pracujemy, by aktywnie zapobiegać powstawaniu błędów, a nie tylko reagować na ich wystąpienie. To podejście wymaga inwestowania w ciągłe doskonale narzędzi i technik pracy i otwartej komunikacji. Ostatecznie w obliczu awarii, staramy się dojść do sedna problemu, a nie zwalić winę i pójść dalej.
Długofalowa niezawodność wymaga czegoś co często nazywamy „incentive system” – systemem zachęt, nagród, czy bodźców. Praca dookoła niezawodności i obserwowalności powinna być tak samo nagradzana i poważana, jak każda inna. Przecież tak samo dowozi wartość dla ostatecznego klienta.
Jeśli brakuje takiej, przyjaznej niezawodności, kultury, możemy próbować wdrażać omawiane rozwiązania, ale rezultaty będą nikłe. Organizacja będzie działać w opozycji do naszych, nawet najlepszych chęci. Członkowie zespołu będą się skupiać na dowożeniu „ficzerków", a niezawodność będzie spadać w dół 📉.
A ja chciałbym Wam tego scenariusza oszczędzić. 😎
Materiały
Standardowo, dla zainteresowanych, mam do polecenia kilka materiałów pogłębiających temat:
Artykuł – Learn About Observability https://docs.honeycomb.io/concepts/learning-about-observability/
Książka - Achieving Observability https://www.honeycomb.io/wp-content/uploads/2021/09/Guide-to-Achieving-Observability-2021-v2.pdf
Podsumowanie
Wbudowanie obserwowalności w produkt pozwala nam stabilnie dostarczać wartość klientom. Dzięki temu biznes ma z tego większe zyski, a my możemy spokojnie pracować.
A jak to wygląda u Ciebie? Ciągłe awarie, czy raczej spokój na produkcji?
PS. Autor oświadcza, że nie jest sponsorowany przez Google, Microsoft ani Honeycomb 😃. Po prostu mają świetne materiały dookoła niezawodności i obserwowalności.
🤦 Postmortem - nauka na błędach
W kolejnym (finalnym) wydaniu serii przyjrzymy się fenomenowi kultury postmortem (lub jej braku) i jak dbanie o zapewnienie nauki o błędach przyczynia się do sukcesu organizacji: