Otrzymujesz alert SMS i e-mail: scenariusz „Przelew” – nie działa. Pierwszym etapem incydentu często jest ustalenie, czego właściwie dotyczy alert. A to czas, który mógłbyś przeznaczyć na jego naprawę. Monitoring całościowo odpowiada na pytanie co nie działa. Jeśli jeden scenariusz ma odpowiadać na cały zestaw pytań naraz, zrodzi się szereg problemów. Każdy z nich powinien dotyczyć konkretnego obszaru, aby minimalizować alerty false-positive. W tym tekście wyjaśnię, dlaczego warto dzielić odtwarzanie scenariuszy na etapy i łączyć go z monitoringiem sieciowym.
Rozłóżmy przykładowy proces na etapy
W tak długim scenariuszu, w praktyce monitorujemy działanie aż 3 różnych procesów:
– odzyskanie konta (z udziałem zewnętrznego dostawcy, do wysłania SMS z kodem OTP)
– zalogowanie do konta
– zlecenie i autoryzacja przelewu na koncie bankowym
Każdy z tych procesów może mieć innego właściciela a nawet backend. Niektóre korzystają dodatkowo z zewnętrznego dostawcy — jak wysyłka SMS-a z kodem OTP. Aby to zobrazować: Niedostarczony na czas SMS z kodem zasygnalizuje niepowodzenie całego sceanriusza. W takiej styuacji nie wiemy, który z monitorowanych etapów (nie kroków) uległ awarii.
Co gubi jeden długi scenariusz
Przede wszystkim miejsce wystąpienia błędu.
Case: monitoring, który sam wywołał awarię monitoringu
Wróćmy do przykładu z autoryzacją SMS-em. Mieliśmy sytuację, w której dostawca ze względów bezpieczeństwa nie pozwalał na więcej niż pięć prób odzyskania hasła na godzinę. Scenariusz ustawiony na odtwarzanie co 10 minut przekraczał ten limit. W efekcie szóste i każde kolejne odtworzenie scenariusza generowało, alert już na samym początku całego procesu.
Awaria odzyskiwania konta oznaczała więc zupełny brak wiedzy o realizacji płatności mimo że w tym czasie klienci bez przeszkód wykonywali transakcje.
To działa w dwie strony. Co, jeśli przelew miał trwać sekundę, a trwał osiem? System zgłasza awarię odzyskiwania konta, a ty tracisz wgląd w pozostałe parametry. Aplikacje składają się z wielu elementów. Nie masz wpływu na poprawność działania wszystkich z nich, możesz jednak je monitorować. Więcej na ten temat znajdziesz w tekście o monitorowaniu usług third-party.
Im bardziej złożony proces zbudujesz, tym większe prawdopodobieństwo awarii. To uruchamia opisany wyżej efekt kaskadowy: wszystko co kryje się za pierwszym błędem, pozostaje niesprawdzone.
Długi scenariusz wywołuje alert przy każdej, nawet drobnej awarii. To oznacza alerty false-positive, a wraz z nimi rosnący koszt obsługi. Nadmiar alertów sprawia, że przestają one cokolwiek znaczyć. W efekcie dojdzie do sytuacji, w której nie zostaną obsłużony jak trzeba albo zignorowane.
Rozbicie na etapy ułatwia nie tylko zlokalizowanie problemu, ale też przypisanie go właścicielowi, założenie ticket-u, a w efekcie skrócenie czasu potrzebnego na naprawę.
Czy klient może zrobić przelew? Czy serwer odpowiada?
To dwa zupełnie różne pytania.
Scenariusz odpowiada na konkretne pytanie biznesowe: czy dany proces jest wykonalny. Mierzy doświadczenie użytkownika.
Monitoring sieciowy bada infrastrukturę: czy usługa działa tak szybko, jak chcemy, czy serwer zwraca prawidłową odpowiedź, którędy idzie ruch i tak dalej.
Jeśli nie da się połączyć z serwerem, to jaki ma sens odtwarzanie scenariusza? Zobacz, jeśli nie działa scenariusz, a serwer nie odpowiada z czterech lokalizacji, to znamy przyczynę w pierwszej minucie od otrzymania alertu. Nie ma sensu odtwarzać samego scenariusza z kilku lokalizacji, skoro można to zrobić sprawniej i szybciej za pomocą monitoringu sieciowego. Wystarczy zebrać adresy IP lub adresy usług, z którymi łączy się aplikacja.
Różnica jest w interpretacji tego, co pokazuje twój dashboard. Pomiar zapytania i odpowiedzi serwerów to informacja o stanie usługi. Odtworzenie scenariusza to pytanie o jakość.
Co widzi sieć, a czego nie zobaczy scenariusz?
„U mnie działa” — skoro tu jesteś, pewnie słyszysz to hasło regularnie. Poniżej lista awarii, przy których to zdanie bywa jednocześnie prawdziwe i zupełnie bezużyteczne. Co warto monitorować, i to z kilku lokalizacji?
Traceroute pokazuje, jaką trasą ruch dociera do serwera z poszczególnych lokalizacji i czy nie jest po drodze przekierowywany.
Wygasające certyfikaty kiedy certyfikat wygasł tylko na jednym z serwerów. Load balancer lub WAF kieruje ruch na losowy serwer, a ty musisz ustalić, na który bo awaria objawia się losowo.
Geofencing i reguły WAF to powtarzający się problem po zmianach w konfiguracji lub aktualizacjach.
Degradacja u operatora lub w peeringu — klienci jednej sieci mobilnej mają timeouty, pozostali nie.
Wspólny mianownik tych awarii jest taki, że z jednego punktu pomiarowego wyglądają albo na „wszystko padło”, albo na nic.
Jak podzielić scenariusz na etapy?
Nie dziel ich wyłącznie na podstawie właścicieli procesu.
Potraktuj etapy jak statusy, które przeprowadzają użytkownika do kolejnego działania. Ostatecznie scenariusz odtwarza właśnie jego doświadczenie. Przyjmij etap jako punkt od, którego użytkownik może przejść dalej w całym procesie.
Używaj tego samego konta testowego do odtworzenia całego scenariusza.
Ustaw osobne alerty dla każdego etapu. Niech trafiają od razu do właściwych osób.
Jeśli bardzo chcesz monitorować pełny proces w jednym scenariuszu — odtwarzaj go rzadziej, np. co godzinę.
Sprawdź różne limity po stronie dostawców, zanim ustawisz częstotliwość odtwarzania. Zwróć uwagę na case z OTP powyżej.
Odtwarzanie scenariuszy jest kluczowym elementem badania doświadczenia użytkowników twojej aplikacji. Dopełnieniem jest monitoring usług internetowych, dodaje wgląd do mierzenia poprawności z różnych lokalizacji i typów łącz. Daje to wiedzę o problemach twoich użytkowników, nawet jeśli scenariusze odtwarzają się prawidłowo.
