Co to są testy syntetyczne?
Test syntetyczny to zaplanowane sprawdzenie usługi wykonywane z zewnątrz przez maszynę, według scenariusza ustalonego wcześniej i zawsze tak samo. Słowo „syntetyczny” znaczy tu tyle, że ruch jest sztuczny: nie pochodzi od klienta, tylko od narzędzia, które udaje klienta o stałej porze i w stały sposób.
Z tej jednej cechy wynika wszystko inne. Skoro ruch jest sztuczny, to test działa również w nocy, kiedy nikt nie kupuje, i wykryje awarię, zanim trafi na nią pierwsza prawdziwa osoba. Skoro przebieg jest zawsze taki sam, to wynik da się porównywać w czasie i liczyć z niego dostępność. I skoro sprawdzenie idzie z zewnątrz, to widzi usługę tak, jak widzi ją internet, a nie tak, jak widzi ją serwer sam siebie.
Testy syntetyczne dzielą się w praktyce na trzy warstwy, coraz bliższe temu, co robi człowiek. Warstwa sieci sprawdza, czy maszyna odpowiada. Warstwa aplikacji sprawdza, czy odpowiada właściwie. Warstwa procesu sprawdza, czy da się przez usługę przejść od początku do końca. Ping jest najprostszą postacią pierwszej warstwy, a scenariusz przeglądarkowy najbogatszą postacią trzeciej.
Czym test syntetyczny różni się od pingu i od sprawdzenia HTTP?
Różnica sprowadza się do pytania, na które sprawdzenie odpowiada. Im wyżej w tej liście, tym bliżej pieniędzy i tym drożej jest wykonać jedno sprawdzenie.
Ping, port TCP, DNS: czy maszyna żyje
Odpowiedź przychodzi w kilka milisekund i mówi tylko tyle, że coś po drugiej stronie jest. Serwer może w tym czasie zwracać błąd na każdej podstronie.
HTTP i HTTPS: czy strona odpowiada poprawnie
Sprawdzenie patrzy na kod odpowiedzi, czas i opcjonalnie na obecność konkretnego tekstu. To odsiewa większość awarii całkowitych, ale nie widzi tego, co dzieje się po zalogowaniu.
Pełna strona z zasobami: czy wszystko się doładowało
Sprawdzenie pobiera stronę razem z jej zasobami i zapisuje listę żądań. Widać z niego skrypt zewnętrzny, który przestał odpowiadać, choć sama strona wygląda zdrowo.
Scenariusz przeglądarkowy: czy klient przejdzie ścieżkę
Prawdziwa przeglądarka klika, wypełnia pola, czeka na element i czyta tekst. Dopiero to sprawdzenie zauważy, że koszyk nie przelicza dostawy, a bramka płatności nie odpowiada.
Czym testy syntetyczne różnią się od monitoringu prawdziwych użytkowników?
Monitoring prawdziwych użytkowników, spotykany pod skrótem RUM, mierzy to, co przeżyli ludzie, którzy właśnie byli na stronie: ich czasy ładowania, ich przeglądarki, ich łącza. Test syntetyczny mierzy to, co przeżył sztuczny użytkownik w kontrolowanych warunkach. To są dwa różne narzędzia i żadne nie zastępuje drugiego.
Pomiar prawdziwego ruchu ma jedną wielką zaletę: pokazuje rzeczywistość, całą jej różnorodność, także problemy widoczne wyłącznie na starym telefonie w słabym zasięgu. Ma też dwie wady. Po pierwsze, nie zobaczy niczego, gdy nikogo nie ma, więc awaria o czwartej nad ranem zostanie odkryta rano razem z pierwszym klientem. Po drugie, wymaga skryptu na stronie i zgody odwiedzającego, bo zbiera dane o ruchu ludzi.
Test syntetyczny jest odwrotnością obu tych cech: nie zbiera danych o niczyjej wizycie, bo wizyta jest sztuczna, i działa dokładnie tak samo w środku nocy. Za to nigdy nie powie, że komuś nie działa płatność w konkretnym banku, jeżeli nie ma tego banku w scenariuszu. Uptimo robi wyłącznie tę drugą rzecz, czyli monitoring syntetyczny, i nie wstawia żadnego skryptu na Twoją stronę.
Kiedy ping wystarcza, a kiedy przestaje?
Sprawdzanie samego adresu wystarcza wtedy, gdy usługa jest jednym elementem i nie ma w niej procesu: strona wizytówka, blog, dokumentacja. Jeśli taka strona odpowiada, to znaczy, że robi wszystko, co miała robić. Dokładanie tam scenariusza przeglądarkowego byłoby wydatkiem bez wyniku i mówimy to wprost, także we własnym cenniku, w którym bezpłatny plan Solo ma sprawdzenia lekkie i nie ma scenariuszy.
Ping przestaje wystarczać w momencie, w którym między wejściem a pieniędzmi pojawiają się kroki. Logowanie, koszyk, formularz zamówienia, płatność, rezerwacja terminu, wysyłka zgłoszenia. Każdy taki krok to osobne miejsce, w którym może pęknąć coś, czego strona główna nie odczuje: wygasły token do bramki, zmiana w zewnętrznym API, wdrożenie, które podmieniło identyfikator przycisku.
Praktyczny test na to, czy jesteś już po tej drugiej stronie, jest jednozdaniowy. Zadaj sobie pytanie, czy Twoja strona może zwracać kod 200 na wszystkich adresach i jednocześnie nie da się na niej kupić. Jeżeli odpowiedź brzmi „tak”, to samo sprawdzanie adresów mierzy coś, co nie jest Twoim problemem. Rozpisaliśmy to osobno w tekście o tym, dlaczego kod 200 to za mało.
Jak często powinien uruchamiać się test syntetyczny?
Odpowiedź zależy od warstwy, bo koszt jednego sprawdzenia różni się między nimi setki razy. Sprawdzenie HTTP albo ping zajmuje kilka milisekund pracy, więc może chodzić co minutę bez rozsądnego powodu, żeby tego nie robić. Przejście ścieżki w prawdziwej przeglądarce zajmuje około 2,7 sekundy procesora, czyli mniej więcej tysiąc razy więcej.
Dlatego w Uptimo scenariusz przeglądarkowy uruchamia się co 5 minut i jest to podłoga w każdym planie, niezależna od tego, ile płacisz. Częstsze uruchamianie nie dałoby lepszego monitoringu, a zajęłoby kolejkę wspólną ze wszystkimi sprawdzeniami. Interwał od 1 minuty, a w instancji dedykowanej od 30 sekund, dotyczy sprawdzeń lekkich: strony, DNS, pingu, portu TCP.
Dobrze zbudowany zestaw łączy jedno z drugim. Sprawdzenie lekkie co minutę jest czujnikiem dymu: wyłapie awarię całkowitą prawie natychmiast. Scenariusz co 5 minut jest kontrolą jakości: wyłapie awarię częściową, czyli tę, której czujnik dymu nie widzi. Razem dają czas reakcji liczony w minutach przy jednej i drugiej klasie problemów.
Co powinno zostać po nieudanym teście syntetycznym?
Sam alert „scenariusz nie przeszedł” jest niewiele wart, bo zaczyna się od niego godzina zgadywania. Wartość testu syntetycznego mierzy się tym, ile pracy zostawia po sobie zrobionej, gdy padnie o trzeciej w nocy i nikt tego nie odtworzy ręcznie o dziewiątej rano.
Minimum to numer kroku, na którym przebieg się zatrzymał, i czas każdego kroku, bo z nich widać, czy coś przestało działać, czy tylko zwolniło. Do tego zrzut ekranu z momentu porażki, który w kilka sekund odróżnia komunikat o błędzie od pustej strony. I zapis żądań sieciowych, czyli plik HAR, z którego widać, które wywołanie zwróciło błąd i ile trwało.
Uptimo zapisuje ten materiał sam i tylko przy niepowodzeniu: nagranie przebiegu, zrzut z każdego kroku i pełen HAR, przechowywane 14 dni. HAR powstaje bez treści odpowiedzi, więc materiał diagnostyczny nie staje się kopią danych z Twojego serwisu. Historia incydentów zostaje na dłużej, bo to z niej liczy się dostępność.
Czego testy syntetyczne nie zobaczą?
Nie zobaczą niczego, czego nie ma w scenariuszu. To jest ich największe ograniczenie i jednocześnie powód, dla którego warto zacząć od ścieżki, która przynosi pieniądze, a nie od dwudziestu scenariuszy dla wszystkich zakątków serwisu. Jeden dobrze wybrany przebieg wart jest więcej niż dziesięć przypadkowych.
Nie zobaczą też awarii widocznej tylko dla części odbiorców. Sprawdzenie wychodzi z konkretnego miejsca w sieci, a w Uptimo jest to dziś jedno miejsce w Unii Europejskiej i mówimy o tym wprost. Problem u jednego operatora albo w jednym kraju może stamtąd wyglądać jak zdrowa usługa.
Nie zobaczą wreszcie tego, co dzieje się między sprawdzeniami. Awaria krótsza niż interwał ma szansę przejść niezauważona, i to samo dotyczy każdego narzędzia, które sprawdza cyklicznie. Uczciwa odpowiedź brzmi więc tak: test syntetyczny skraca czas do wykrycia z godzin do minut, ale nie do zera, i nikt, kto obiecuje zero, nie mówi prawdy.
Od pojęcia do włączonego sprawdzenia
Scenariusz układa się z kroków wybieranych z listy, bez pisania kodu, albo opisuje zdaniami, które kreator wykona na Twojej stronie i pokaże wynik każdego kroku ze zrzutem ekranu, zanim cokolwiek zostanie zapisane. Pierwsza ścieżka zakupowa zajmuje zwykle kilkanaście minut.