Przeczytaj wersję webową.

Dług obserwowalności

Cześć!

Dzisiaj przygotowałem dla Ciebie krótszy odcinek. Opowiem o długu obserwowalności. 💸 Jest to problem, który pojawia się w wielu organizacjach, a o którym stosunkowo niewiele się mówi.

Standardowo czeka na Ciebie też świeżutki spis najgorętszych artykułów z polskich i zagranicznych internetów.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀

Inżynierska prasówka

1. How I Used Event-Driven Architecture in the Wrong Way - shiiyan
   Najlepiej się uczyć na cudzych błędach, prawda? A w świecie Event-Driven Architecture łatwo o pomyłki.
   Autor shiiyan (nie znalazłem imienia 😉) dzieli się swoimi problemami z wdrożenia tej architektury. Opisuje problemy dookoła transakcyjności, kolejności zdarzeń, czy dwustronnej komunikacji. Warto mieć to na uwadze, ponieważ łatwo wdrożyć EDA i po kilku miesiącach cierpieć mocno z tego powodu.
   https://medium.com/@shiiyan/how-i-failed-in-event-driven-architecture-86eb493082fa

2. Queues invert control flow but require flow control - Gregor Hohpe
   Gregor opowiadał o tym temacie na AWS re:Invent, ale warto wspomnieć, że pojawił się też podsumowujący zagadnienie artykuł.
   Łatwo wdrażając kolejki myśleć, że to rozwiązanie nie ma wad. Wrzucamy temat na kolejkę, ktoś inny odbiera. Znika nam gdzieś czasowe złączenie pomiędzy systemami. Niestety, każde rozwiązanie wiąże się z pójściem na kompromisy.
   Musimy zarządzać przepływem tak, by tempo wysyłki wiadomości odpowiadało tempu odbierania. Inaczej wysyłający przytłoczy wysyłającego. I skończy się to upadkiem systemu.
   https://www.enterpriseintegrationpatterns.com/ramblings/queues_flow_control.html

3. TBM 305: Stop the (Goal) Cascade Madness – John Cutler
   Kaskady celów są popularne w wielu organizacjach, ale czy na pewno działają tak dobrze, jak nam się wydaje? John Cutler przekonuje, że niekoniecznie.
   Zwraca uwagę na problemy związane z wielopoziomowymi kaskadami celów, które często odzwierciedlają strukturę organizacyjną, zamiast faktycznych zależności przyczynowo-skutkowych. John proponuje alternatywne podejście, skupiające się na połączeniu celów do modelu metryk zespołów.
   To ciekawy model mentalny nawet jeśli nie pracujemy produktowo – zamiast myśleć o kaskadach, myśleć w luźnych połączeniach.
   https://cutlefish.substack.com/p/tbm-305-stop-the-goal-cascade-madness

4. Spotkania to praca, którą trzeba zarządzać - Tomasz Bienias
   Tomasz Bienias, kwestionuje wnioski z badań Microsoftu o negatywnym wpływie spotkań na produktywność. Argumentuje, że spotkania są integralną częścią pracy, szczególnie w procesach kreatywnych i zarządczych.
   Zamiast unikać spotkań, Tomek proponuje nauczyć się nimi efektywnie zarządzać. Sugeruje, by menedżerowie wzięli odpowiedzialność za produktywność spotkań – rozpoczynać poprawę od regularnych spotkań.
   Bardzo mi to pasuje do mojego ulubionego podejścia Game Storming, gdzie projektujemy aktywności grupowe tak by były jak najbardziej efektywne.
   https://www.linkedin.com/posts/tomasz_wniosek-z-bada%C5%84-microsoftu-%C5%BCe-spotkania-activity-7219942134802489345-Hwwe/

5. Use Wayvwords – Michael Feathers
   Nowoczesne problemy wymagają nowoczesnych rozwiązań. Michael Feathers jest w trakcie tworzenia książki “AI Assisted Programming”. I dzieli się ciekawą koncepcją “waywords” - specjalnych słów kluczowych ułatwiających komunikację z AI podczas programowania.
   Michael pokazuje, jak tworzyć i używać takich słów do generowania kodu czy refaktoryzacji. Waywords pozwalają zwięźle opisywać złożone operacje, jak na przykład “intralate” do konwersji typów wewnątrz metod.
   To niesamowite, jak może wyglądać przyszłość programowania wspomaganego przez AI.
   https://www.linkedin.com/posts/michaelfeathers_use-waywords-ugcPost-7227367323878187008-RNZL/

Gdy brakuje obserwacji

Dług techniczny to zagadnienie, które od niepamiętnych czasów jest na tapecie u liderów technicznych. W poprzednim newsletterze Inżynierski wkład w roadmapę produktu omawialiśmy już różne rodzaje długu, które mogą wystąpić w produktach:

• Klasyczny dług techniczny
• Biznesowy - zmiany modelu działania firmy, które nie zostały uwzględnione w produkcie.
• Organizacyjny – problemy komunikacyjne czy strukturalne, które wpływają na produkt.
• Użyteczności - błędny model działania, do którego przyzwyczaił się klient, przez co zmiana jest problematyczna.

Jednak lista typów długu może być dłuższa. Nasze produkty stają się coraz bardziej złożone i odnoszą się do coraz większej szerokości zagadnień.

Dziś chciałbym zaproponować jeszcze jedno spojrzenie na temat długu i wprowadzić koncept długu obserwowalności (observability debt).

Przyjrzyjmy się bliżej temu zagadnieniu:

• Zdefiniujmy czym taki dług jest
• Określmy, jak wpływa na prace produktowe i techniczne
• Zaproponujmy sposoby stopniowego radzenia sobie z długiem obserwowalności

Definicja długu obserwowalności

Zanim zagłębimy się w szczegóły, spróbujmy zdefiniować, czym właściwie jest dług obserwowalności. Pozwólcie, że ukuję tu nowy termin - bo choć zjawisko to istnieje od dawna, to chyba nikt jeszcze nie nazwał go wprost. 😉

Dług obserwowalności - sytuacja, w której mamy działający produkt przynoszący wartość biznesową, ale jednocześnie nie rozumiemy w pełni, jak funkcjonuje “pod maską”.

Może to przypominać prowadzenie samochodu z zaparowanymi szybami - niby jedziemy do przodu, ale nie widzimy dokładnie drogi.

Ten rodzaj długu może przybierać dwie formy.

• Po pierwsze, może dotyczyć aspektów technicznych - nie wiemy, jak nasz system działa.
• Po drugie, może odnosić się do aspektów biznesowych - nie rozumiemy, jak użytkownicy wchodzą w interakcję z naszym produktem.

W obu przypadkach brak wiedzy prowadzi jednak do równiepoważnych konsekwencji. Spójrzmy więc na te problemy – rozpoczynając od aspektów biznesowych.

Problemy biznesowe

Brak obserwowalności biznesowej to jak prowadzenie firmy z zawiązanymi oczami. Niby działamy, ale umyka nam pełny obraz tego, jak nasz produkt jest używany i jaki ma wpływ na klientów.

Przyjrzyjmy się kilku kluczowym obszarom, w których ten problemdaje się we znaki.

Przede wszystkim, o wiele łatwiej jest stracić z oczu nietypowe przypadki użycia. Nie widzimy klientów, którzy zachowują się inaczej niż większość - a to często właśnie oni mogą być źródłem cennych insightów. Gojko Adzic świetnie to opisał w swojej prezentacji Lizard Optimization, jak udało mu się powiększyć swój produkt aż 500 razy, zauważając właśnie takie nietypowe zachowania. 🐍

Kolejną problematyczną kwestią jest brak różnicowania grup klientów czy rynków. Jeśli traktujemy wszystkich jednakowo, skończymy oczywiście ze sporym uproszczeniem. Różne segmenty mogą mieć odmienne potrzeby i wzorce korzystania z produktu, ale bez odpowiedniej obserwowalności, te niuanse nam umykają.

Brakuje też sposobu by dokładnie sprawdzić, w którym momencie klienci rezygnują zproduktu. Ta informacja jest natomiast kluczowa dla poprawy user experience i redukcji churn rate. A klienci zanim podejmą ostatni krok,często:

• Przestają się logować.
• Kupują mniej niż zwykle.
• Rzadziej procesują swoje dokumenty.

Te wszystkie zachowania można odpowiednio wcześniej wyłapać. Jednak bez konkretnej wiedzy, odnotujemy tylko ostateczne zerwanie umowy.

Warto ponadto pamiętać, że obserwowalność nie jest jedynie kołem ratunkowym. Gdy sprawy idą dobrze, to jej brak też boli. 😅 Trudno nam zidentyfikować, co dokładnie przyczynia się do sukcesu. Brak precyzyjnych danych o zachowaniach użytkowników przeszkadza też w umacnianiu dobrych wzorców. Pracujemy na ślepo.

Te systemowe luki sprawiają, że podejmujemy decyzje bazując bardziej na intuicji niż konkretach. A to niestety prosta droga do błędnych decyzji strategicznych i niewykorzystanych szans rynkowych.

Na tym nie koniec bolączek - problemy z obserwowalnością nie ograniczają się tylko do aspektów biznesowych. Równie istotne (i potencjalnie kosztowne) są kwestie techniczne. Przyjrzyjmy się im bliżej w kolejnej części. 🛠️

Problemy techniczne

Wprowadzanie usprawnień w systemie bez obserwowalności technicznej to jak próba naprawy skomplikowanej maszyny nie mając do dyspozycji instrukcji i narzędzi diagnostycznych.

Niby system działa, ale brakuje pełnego wglądu w jego funkcjonowanie. Prowadzi to do szeregu problemów zarówno technicznych jak i operacyjnych.

Jednym z największych zagrożeń jest ryzyko, że nie wyłapujemy błędów, dopóki nie uderzą bezpośrednio w naszych klientów.

• Zamiast: Wyłapujemy błąd -> Naprawiamy -> Klient go nie widzi
• Mamy: Nie wyłapujemy błędu -> Klient go odczuwa -> Zgłasza błąd -> My musimy zobaczyć co się stało -> Naprawiamy -> Przepraszamy

Bez odpowiednich mechanizmów monitorowania drobne usterki będą tylko narastać, aż nie przerodzą się w poważne awarie. A my stracimy wtedy jeszcze więcej czasu.

Kolejnym problemem jest brak wglądu w kwestię wydajności systemu. Nie widzimy, które elementy działają wolno lub gdzie znajdują się wąskie gardła. W efekcie, optymalizacja staje się procesem opartym na zgadywaniu, zamiast na konkretnych danych.

Dalej mamy debugowanie. Proces debugowania wygląda diametralnie inaczej, gdy nasz system jest obserwowalny:

• Jest: Mamy pełen zakres danych, widzimy jaki to klient, z jakimi parametrami i konfiguracją. Dokładnie odtwarzamy przypadek błędu.
• Nie jest: Zastanawiamy się i szukamy wskazówek co właściwie się stało i z jakimi danymi. Na ślepo odtwarzamy przypadek błędu.

Zamiast szybko identyfikować źródło problemu, zespół techniczny traci godziny na rozpoznaniu terenu.

Wreszcie, brak obserwowalności technicznej utrudnia monitorowanie systemów zewnętrznych, od których często zależy działanieproduktu. Nie wiemy, czy problemy leżą po naszej stronie, czy może to zewnętrzne API zawodzi.

Wszystkie te luki w wiedzy technicznej sprawiają, że utrzymanie i rozwijanie systemu staje się coraz trudniejsze. Zamiast proaktywnie reagować na potencjalne problemy, jesteśmy zmuszeni do ciągłego “gaszenia pożarów”.

Mając świadomość problemów wynikających z braku obserwowalności, zarówno biznesowej, jak i technicznej, naturalne wydaje się pytanie: jak możemy temu zaradzić?

Jak wyjść z długu obserwowalności?

Wiemy, jakie problemy niesie ze sobą dług obserwowalności. Czas zastanowić się, jak możemy go spłacić. Oto kilka kluczowych kroków, które pomogą poprawić obserwowalność każdego produktu:

Identyfikacja najważniejszych aspektów

Na początek musimy zdefiniować, co tak naprawdę ma znaczenie. Brzmi banalnie, ale często pomijamy ten krok. Zbierz więc zespół i zastanówcie się wspólnie, jakie metryki biznesowe i techniczne są kluczowe dla waszego produktu.

Może to być czas trwania określonego procesu, liczba błędów krytycznych czy wskaźnik retencji użytkowników.

Pamiętaj, że nie chodzi o to, by mierzyć wszystko - skupcie się na tym, co naprawdę istotne. 🎯

Co mamy -> Do czego dążymy

Kolejnym krokiem jest określenie luki między stanem obecnym a pożądanym.

Tutaj przydatne może być podejście opisane w książce “How to Measure Anything” - zacznij od określenia, co już wiesz iczego potrzebujesz się dowiedzieć.

To pomoże ukierunkować wysiłki na obszary, gdzie brak wiedzy jest najbardziej dotkliwy.

Głębokie łatanie

Teraz czas na konkretne działania.

Zamiast powierzchownych poprawek, zastosuj “głębokie łatanie” – skup się na jednym wąskim zakresie, ale przeprowadź pracę od A do Z. Zaimplementuj rozwiązania, które dadzą możliwie pełen wgląd w krytyczne aspekty działania systemu.

Może to oznaczać na przykład wdrożenie zaawansowanych narzędzi do monitoringu, dodanie szczegółowych logów czy stworzenie dashboardów agregujących kluczowe metryki.

Chcemy osiągnąć szybki zysk, by na jego podstawie adresować kolejne problemy.

Praktyki dnia codziennego

Bardzo łatwo jest coś naprawić, a w następnym sprincie od razu znowu zepsuć.

Ostatni, ale równie ważny krok, to stworzenie praktyk zapobiegających narastaniu długu obserwowalności w przyszłości.

Możesz na przykład wprowadzić zasadę, że każda nowa funkcja musi mieć zdefiniowane metryki sukcesu i sposób ich pomiaru. Albo regularnie przeglądać i aktualizować dashboardy, by upewnić się, że nadal dostarczają wartościowych informacji.

Podsumowanie

Pamiętaj, że spłacanie długu obserwowalności to nie pojedyncze działanie, a proces ciągły. Wraz z ewolucją produktu, zmieniają się też nasze potrzeby w zakresie monitoringu i analizy. Bądź przygotowany, że będziesz musiał usprawniać swoje narzędzia i procesy.

Z czasem zauważysz, że podejmowanie decyzji staje się łatwiejsze, a reagowanie na problemy - szybsze i bardziej precyzyjne. A to przełoży się na lepszą jakość produktu i większe zadowolenie klientów. Win-win! 🏆

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)