Zapewniaj jakość dzięki obserwowalności

W tym wydaniu chciałbym was zabrać w podróż do krainy obserwowalności. Na tej wycieczce pokażę, jak praktyki dookoła monitoringu i prewencji pozwalają dbać o wysoką jakość waszych aplikacji.

Jak obserwowalność zapewnia jakość

W ramach poprzedniego newsletteru pisałem czym jest obserwowalność i jak można ją rozwijać w swoim produkcie - Niezawodność i obserwowalność. Dziś nieco pogłębimy te tematy.

Jeśli czytałeś mojego ebooka „Drivery architektoniczne" to pewnie znasz tę grafikę – atrybuty jakościowe.

Jednym z wspominanych atrybutów tutaj jest obserwowalność. I możesz zadać słuszne pytania:

• Czy obserwowalność wpływa w ogóle na jakość?

• Jak miałaby zapewniać jakość?

• Jak obserwowalność wpływa na mój produkt i klientów?

I owszem, obserwowalność bezpośrednio nie wpływa na jakość. Jednak pośrednio może wpływać tak mocno, że w ostateczności nie będzie Ci brakowało niczego poza obserwowalnością.

Spójrzmy najpierw na standardowe zapewnianie jakości – przez testy.

Testy jako jedyna metoda zapewniania jakości

Często w zespołach pokutuje myślenie, że jakość = testy. Kiedyś nawet takie było postrzeganie roli testera w zespole – że to on/ona dba o jakość, cała reszta zaś klepie kod.

Nawet przyjmując, że w zespole testują wszyscy (mam nadzieję, że tak właśnie postępujecie) to można zwrócić uwagę na cały szereg problemów z tym związanym:

Nie wszystko jesteś w stanie przetestować

Istnieje szereg sytuacji w których nie da się przetestować wszystkich przypadków, lub jest to zbyt drogie do implementacji. Przykładowo:

• Testy musiałyby iść po E2E, które są wolne.

• Przypadków jest za dużo, aby napisać do nich wszystkich testy.

• Systemy zewnętrzne mogą działać niedeterministycznie i rozwalać nam testy.

• Trudno jest zasymulować skrajne warunki – np. DDoS, awarię środowiskową.

Weźmy na tapet przypadek z życia wzięty:

• Zakładając, że posiadamy 12 flag konfiguracyjnych, z których każda ma 4 wartości.

• A jednocześnie to są konfiguracje z 3 różnych zewnętrznych serwisów.

• Ostatecznie mamy 4^12 = 16 777 216 scenariuszy testowych.

• Uruchomienie tych scenariuszy do końca zależy od nas, bo konfigurowane są poza naszym systemem.

Całościowe testy takiego scenariusza mogą być albo bardzo kosztowne do napisania, albo „kruche" – drobna zmiana rozsypie cały system.

Testujemy to, o czym wiemy

Rozwińmy zjawisko, które zacząłem opisywać wyżej.

Poza przypadkami, o których wiemy, istnieje szereg zdarzeń, które umykają naszej percepcji. Nie można nie zacytować tutaj Donalda Rumsfelda i jego Unknown Unknows 😃

To doskonale wyjaśnia, dlaczego nie przetestujemy tych przypadków przed wdrożeniem. Tutaj oczywiście pomóc może solidna doza analizy, eksploracji i brainstormingu. Ale jedynie do pewnego stopnia. Nie siedzimy w głowie naszych klientów. Tym bardziej, jeśli jest ich 10/100/1000 razy więcej niż “naszych”.

To sprawia, że przypadki użycia przeciekają nam przez sito testowe i ostatecznie to dopiero klienci zweryfikują je na produkcji.

Testujemy funkcjonalnie, atrybuty jakościowe nam umykają

To co testujemy manualnie i automatycznie w 95% przypadków będzie skupione na pracy funkcjonalnej. Jednak konia z rzędem temu, kto będzie w stanie za pomocą testów przed wdrożeniem przetestować:

• Konfigurowalność– jak wiele czasu użytkownicy poświęcają na to by dokonfigurować system pod swoje potrzeby.

• Odporność– ile sumarycznie jest niedokończonych procesów biznesowych przez błędy systemów zależnych.

• Dostępność– w jak wielu sytuacjach system nie odpowiadał na żądania użytkownika.

• Wielojęzyczność– ile treści nie zostało przetłumaczonych dla użytkowników.

Moglibyśmy tak dalej.

Bez obserwowania systemu nie jesteśmy w stanie uzyskać dokładnej informacji o tym jak pracuje. To sprawia, że:

• Zamiast posługiwać się konkretami, jesteśmy zdani na własne przeczucie.

• Możemy łatwo przeoczyć stopniowy spadek jakości.

Nowoczesne zapewnianie jakości

Szersze spojrzenie na zapewnianie jakości się po prostu opłaca. Aby uzyskać tę perspektywę, możesz wykorzystać Agile Testing Quadrants autorstwa Janet Gregory i Lisa Crispin:

Po lewej stronie mamy opisane znane nam techniki testowania. Jednak to są praktyki, które prowadzą nas podczas procesu dostarczania oprogramowania. Pomagają nam zadbać o jakość, zanim jeszcze kod pojawi się na produkcji.

Zwykle jednak zapominamy o drugiej stronie – o praktykach, które powiedzą nam jak pracuje nasz produkt.

Cytując autorów:

Even with this testing, there is no way to replicate every possible scenario that customers will do with your application. So, teams also need to keep an eye on production usage with monitoring dashboards and observability tools, so they can find and fix issues before customers are affected by them.

Monitoring i obserwowalność są kluczowymi praktykami, które budują jakość naszych produktów – przejdźmy więc ponownie przez argumenty przytoczone wyżej.

Testujemy co warto testować i obserwujemy resztę

Na etapie projektowania można podjąć decyzję, kiedy i w jaki sposób przetestować dany przypadek użycia:

• Część przypadków testujemy automatycznie, ponieważ czujemy, że są dla nas kluczowe.

• Część przypadków obserwujemy, bo są zbyt drogie do przetestowania bądź zbyt nieliczne by się nimi przejmować.

Dopiero gdy nasza hipoteza dookoła częstotliwości występowania przypadków okaże się nieprawdziwa, zaczynamy się skupiać na nich bardziej.

Obserwujemy to czego nie przewidzieliśmy

Dodatkową zaletą tej metody jest to, że jesteśmy w stanie szybko wychwycić przypadki nietypowe, o których sami nigdy byśmy nie pomyśleli. Dowiemy się, że użytkownicy klikają tam, gdzie nie trzeba, wpisują dziwne dane, czy crashują system w zupełnie abstrakcyjny sposób.

Gojko Adzic przygotował swego czasu niesamowitą prezentację o tym jak powiększył swój produkt 500 razy tylko dzięki temu, że zauważył nietypowe zachowania swoich użytkowników.

Tego nie da się przetestować. To trzeba zobaczyć 😃

Obserwujemy atrybuty jakościowe

Obserwowalność jest dosknałą bazą do badania wskaźników jakościowych naszego produktu:

• Konfigurowalność – zbieramy informacje co konfigurowano i ile to trwało.

• Odporność – monitorujemy system zewnętrzny i liczbę problemów przez niego spowodowanych.

• Dostępność – liczymy czasy odpowiedzi na zapytania klienta i timeouty.

• Wielojęzyczność – znajdujemy wszystkie klucze, które zostały wyświetlone bez tłumaczenia.

Dostajemy więc dokładną informację o tym jak nasz system pracuje i czy z wymaganą jakością.

Zyskujemy na prędkości

Dodatkowym plusem jest zauważalne przyspieszenie prac.

W przypadku błędów na produkcji jesteśmy w stanie o wiele szybciej je zauważyć i od razu zareagować, np. cofnąć zmianę w całości.

Jak to pisali autorzy książki Continuous Delivery:

Assume that you may break something that will take more than a few minutes and know what to do to revert the changes and get back to the known-good revision in version control.

Efekt? Błędy na produkcji będą mniej wpływać na klientów. A to wpłynie pozytywnie na postrzeganą jakość.

Ale, aby to osiągnąć, trzeba mieć dobrą obserwowalność produktu.

Rozwiązania

Nie chcąc zostawiać Cię bez praktycznego zastosowania, omówmy przykład e-commerce i 2 obszary jakościowe:

• Internacjonalizacja - chcemy by klienci mogli bez problemu korzystać z systemu w swoim języku.

• Odporność na błędy - system obsłuży proces zakupowy, nawet jeśli bramka płatności nie zadziała.

Przejdziemy przez 3 elementy:

• Kryteria

• Monitoring

• Prewencja

Miary i kryteria

Pierwszym obszarem, na którym nam zależy jest określenie, co chcemy obserwować i jak określimy, że to co obserwujemy jest zagrożeniem dla jakości.

Miarami będą więc:

• Internacjonalizacja

  • Braki w tłumaczeniach tytułów i labelek - idealnie 0.

  • Braki w tłumaczeniach produktów - maksymalnie 1/100.

• Odporność na błędy

  • Niedostępność bramki zewnętrznej - system zaproponuje inną bramkę, lub płatność później.

  • Churn klientów - w przypadku błędów, proces będzie kontynuować przynajmniej 95% klientów.

Monitoring i alerty

Następnym krokiem jest zdefiniowanie i wbudowanie odpowiedniego systemu monitorowania jakości. Możemy to robić w formie aktywnej i pasywnej:

• Aktywnie – samemu sprawdzamy i symulujemy określone przypadki na produkcji, a następnie zbieramy dane.

• Pasywnie – zbieramy informacje o tym jak pracują nasi użytkownicy.

Gdy tylko przekroczymy zdefiniowane progi, powinniśmy poinformować zespół i przystąpić do rozwiązywania problemu.

Można tutaj też zwrócić uwagę na błąd przeżywalności – jakich informacji nam brakuje i na ich podstawie wnioskować.

Przenosząc to na omawiamy e-commerce:

• Odporność na błędy

  • Testy procesu zakupowego z wykorzystaniem dummy usera.

  • Dashboard z wyliczaniem % klientów, którzy kontynuują pracę / odpadają.

  • Logi z informacjami, kiedy nie zadziałał system płatności.

  • Alerty, gdy system zewnętrzny spowodował więcej niż 5% błędów w zdefiniowanym zakresie czasu.

• Tłumaczenia

  • Zbieranie informacji jakie klucze nie mają wartości.

  • Dashboard z brakami w tłumaczeniach do kategoryzacji – obszar funkcjonalny, język, rynek.

  • Policzenie ilości kluczy/języków/rynków, które nie są wykorzystywane.

  • Alertowanie braków w tłumaczeniach.

Prewencja

Na końcu można się jeszcze zastanowić w jaki sposób możemy automatyzować prewencję. W większości przypadków lepiej jest pokazać / zrobić cokolwiek, nawet coś niedoskonałego niż nie zrobić niczego.

W przypadku e-commerce może to wyglądać następująco:

• Odporność na błędy

  • Przełączamy się na innego providera płatności + ukrywamy niedziałającego.

  • W przypadku większej awarii wyłączamy funkcję ponawiania płatności i dajemy możliwość zapłacenia po zakupie.

• Tłumaczenia

  • Uruchamiamy moduł automatycznego tłumaczenia na podstawie klucza i tłumaczenia bazowego.

  • Dodajemy flagę z informacją, że treść jest przetłumaczona maszynowo + opcja by użytkownik ręcznie ją zaakceptował.

Podsumowanie

Dróg do osiągania jakości za pomocą obserwowalności jest wiele. Ale pierwszym krokiem jest zawsze zaakceptowanie tego, że obserwowalność może wpływać na jakość. I mam nadzieję, że do tego Cię przekonałem 😊

Daj znać w odpowiedzi jakie są Twoje osobiste praktyki dookoła obserwowalności i w jaki sposób wspierają ulepszanie jakości!