Kod 200: co znaczy i dlaczego nie dowodzi, że strona działa

Czy kod 200 oznacza, że strona działa?

Najprostszy monitoring dostępności sprawdza właśnie ten kod. Odpowiedź z rodziny 2xx albo 3xx zwykle daje zielony wskaźnik, 4xx i 5xx czerwony. To użyteczny sygnał, bo kod 5xx prawie zawsze oznacza prawdziwą awarię, a 404 na stronie głównej to błąd, którego nie da się przeoczyć.

Kłopot leży w odwrotnym kierunku. Czerwony kod dowodzi awarii, ale zielony nie dowodzi, że wszystko działa. Kod 200 odpowiada na pytanie, czy serwer odesłał stronę, a nie na pytanie, czy klient może na niej zrobić to, po co przyszedł. Reszta tego tekstu jest o tej różnicy.

Co dokładnie sprawdza narzędzie, które pinguje stronę?

Klasyczny monitoring dostępności zadaje serwerowi jedno krótkie pytanie i mierzy czas odpowiedzi. Ping sprawdza, czy maszyna jest w sieci. Sprawdzenie portu TCP potwierdza, że usługa nasłuchuje. Zapytanie DNS mówi, czy domena wciąż wskazuje na właściwy adres. Sprawdzenie HTTP wysyła żądanie i patrzy na kod odpowiedzi.

Te sprawdzenia są tanie i szybkie, więc można je uruchamiać często, na wielu adresach naraz. Uptimo też je ma, razem z pilnowaniem terminu ważności certyfikatu, i to zwykle od nich zaczyna się konfiguracja. Warto tylko wiedzieć, na co dokładnie odpowiadają: potwierdzają, że serwer żyje i jest osiągalny. To nie to samo co „usługa działa”.

Dlaczego kod 200 potrafi kłamać?

Kod 200 znaczy dokładnie tyle: serwer przyjął żądanie i wygenerował odpowiedź. Nie mówi nic o tym, co w tej odpowiedzi jest. Strona z komunikatem o przerwie technicznej, pusta lista produktów po nieudanej migracji, formularz, który przyjmuje dane i wyrzuca je do kosza, potrafią przyjść z kodem 200 i idealnym czasem odpowiedzi.

Drugi powód jest techniczny. Coraz więcej serwisów buduje treść dopiero w przeglądarce. Serwer oddaje wtedy prawie pusty dokument i zestaw skryptów, a błąd pojawia się sekundę później, już po stronie klienta. Narzędzie, które czyta tylko odpowiedź serwera, tego nie zobaczy, bo ono nigdy nie uruchamia strony.

Trzeci powód jest najprostszy. Zakup to nie jeden adres, tylko kilkanaście żądań pod rząd: karta produktu, koszyk, dane dostawy, sesja, bramka płatności. Sprawdzanie jednego adresu z tego łańcucha mówi o jednym ogniwie, a klient traci pieniądze wtedy, gdy pęknie dowolne.

Jakie awarie przechodzą przez takie sprawdzenie niezauważone?

To nie są przypadki teoretyczne, tylko lista rzeczy, które psują sprzedaż przy zielonym pulpicie monitoringu.

• Płatność odrzucona po stronie integracji

  Strona sklepu odpowiada normalnie, ale przekierowanie do bramki kończy się błędem. Widać to dopiero po kliknięciu „Zapłać”.

• Koszyk gubiący zawartość

  Po zmianie ustawień sesji albo pamięci podręcznej produkty znikają między krokami. Każde pojedyncze żądanie jest poprawne.

• Logowanie po aktualizacji

  Formularz się wyświetla, poprawne hasło jest odrzucane. Kod odpowiedzi strony logowania cały czas wynosi 200.

• Skrypt zewnętrzny, który blokuje stronę

  Czat, analityka albo baner zgody przestają odpowiadać i zasłaniają przycisk. Serwer nie ma z tym nic wspólnego.

• Pusty wynik wyszukiwania

  Po ponownym indeksowaniu wyszukiwarka w sklepie zwraca zero produktów. Strona wyników działa bez zarzutu.

• Certyfikat, który wygasa w nocy

  Do ostatniej minuty wszystko odpowiada poprawnie, a potem przeglądarka pokazuje ostrzeżenie zamiast strony.

Jak sprawdzić stronę tak, jak sprawdza ją klient?

Odpowiedź jest jedna: przejść tę samą drogę co klient, w prawdziwej przeglądarce, tyle że automatycznie i regularnie. Nazywa się to testem syntetycznym albo scenariuszem przeglądarkowym. Zamiast pytać serwer o kod odpowiedzi, uruchamiamy stronę, klikamy, wypełniamy pola i na końcu sprawdzamy, czy pojawił się konkretny tekst.

To ostatnie sprawdzenie jest sednem całego pomysłu. Warunek „na stronie po zamówieniu widnieje potwierdzenie” nie da się spełnić przez przypadek. Strona błędu z kodem 200 go nie spełni, pusty koszyk go nie spełni, zawieszony skrypt też nie. Dopiero taki warunek zamienia monitoring z pytania o serwer w pytanie o proces.

W Uptimo scenariusz układa się z gotowych kroków: przejdź, kliknij, wypełnij, poczekaj, sprawdź tekst. Można też opisać scenariusz własnymi słowami, a asystent zamienia opis na kroki. Nie trzeba pisać kodu ani utrzymywać własnego środowiska testowego.

Co powinno zostać po nieudanym sprawdzeniu, żeby dało się je naprawić?

Alert, który mówi tylko „scenariusz nie przeszedł”, przenosi całą pracę na człowieka: trzeba odtworzyć awarię, zgadnąć, w którym kroku pękło, i mieć nadzieję, że akurat wtedy zdarzy się jeszcze raz. Najdroższe awarie to te, które przy próbie odtworzenia znikają.

Dlatego nieudany przebieg powinien zostawiać dowód. Nagranie pokazuje, co widziała przeglądarka. Zrzut z każdego kroku wskazuje moment, w którym scenariusz się zatrzymał. Zapis żądań sieciowych, czyli plik HAR, mówi, które żądanie zwróciło błąd, ile trwało i co odpowiedział serwer. Z takim kompletem rozmowa z programistą albo z dostawcą hostingu zaczyna się od faktów, a nie od zdania „czasem nie działa”.

Jak często sprawdzać i co z tego liczyć?

Częstotliwość wynika z kosztu minuty przestoju, nie z ambicji. Lekkie sprawdzenia, jak HTTP czy ping, są tanie i mogą chodzić bardzo często. Scenariusz przeglądarkowy uruchamia prawdziwą przeglądarkę, więc kosztuje wielokrotnie więcej i sensowny interwał liczy się w minutach. Zwykle najlepiej działa połączenie obu: gęsta siatka lekkich sprawdzeń plus scenariusz na jednej, najważniejszej ścieżce.

Z historii sprawdzeń liczy się kilka rzeczy naraz: dostępność w procentach, łączny czas przestoju, liczbę incydentów i średni czas naprawy. Te liczby są potrzebne nie tylko do rozmowy z zespołem. Raport SLA wysyłany co tydzień albo co miesiąc zamienia dyskusję o jakości usługi w rozmowę o pomiarze, także z klientem i z dostawcą.

Zaplanowane przerwy warto obsłużyć osobno. Okno serwisowe wycisza alerty na czas wdrożenia, a decyzja, czy wyłączyć ten okres z wyliczeń dostępności, powinna być świadoma. Inaczej albo budzi się dyżur bez powodu, albo raport przestaje być uczciwy.

Czego żaden monitoring nie załatwi?

Monitoring nie naprawia awarii, tylko skraca czas do jej zauważenia. Nie zastąpi testów przed wdrożeniem, bo działa na tym, co już jest na produkcji. Nie wykryje też błędu, którego nie umie zobaczyć: zła cena w katalogu albo pomyłka w treści przejdą przez scenariusz tak samo gładko jak poprawne dane, o ile strona się otwiera i zawiera oczekiwany tekst.

Jest jeszcze jedno ograniczenie, o którym rzadko się pisze. Sprawdzenie wychodzi z konkretnego miejsca w sieci. Awaria widoczna tylko dla części odbiorców, na przykład problem u jednego operatora, może stąd wyglądać jak zdrowa strona. W Uptimo sprawdzenia wychodzą dziś z jednego miejsca i mówimy to wprost, zamiast obiecywać mapę świata.

Wniosek praktyczny jest prosty: monitoring wykrywa dokładnie to, co kazano mu sprawdzać. Jeżeli kazano mu sprawdzać, czy serwer odpowiada, to właśnie tego się dowiesz. Jeżeli ma sprawdzać, czy klient może kupić, trzeba mu opisać tę drogę krok po kroku.