Jeżeli strona działa u Ciebie, a nie działa u klientów, problem najczęściej nie jest wyimaginowany. Internet jest systemem rozproszonym, a jego zachowanie zależy od lokalizacji, infrastruktury pośredniej i konfiguracji bezpieczeństwa.

Jak to możliwe, skoro internet to “jedna sieć”?

Internet nie wygląda tak samo z każdego miejsca

To, że strona działa w Twojej przeglądarce w Polsce, nie oznacza, że działa identycznie w Niemczech, Norwegii czy w sieci komórkowej innego operatora. Użytkownicy łączą się z różnych adresów IP, przez różne trasy sieciowe, a czasem przez różne centra danych.

Jeśli masz błędną konfigurację firewalla, blokadę geograficzną albo problem z routingiem w jednym z regionów, efekt będzie dokładnie taki: część użytkowników zobaczy stronę, część - błąd 502, timeout albo całkowity brak odpowiedzi.

Właśnie dlatego “u mnie działa” nie jest testem dostępności.

DNS potrafi wprowadzić w błąd

Szczególnie często problem pojawia się po migracji serwera. Zmieniasz hosting, aktualizujesz rekordy DNS i widzisz, że wszystko jest w porządku. Ale serwery DNS na świecie aktualizują się stopniowo. Przez pewien czas część użytkowników trafia jeszcze na stary adres IP.

Jeżeli poprzedni serwer został już wyłączony albo działa niestabilnie, klient może widzieć niedostępną stronę, podczas gdy Ty - nową, poprawnie działającą wersję.

To klasyczny scenariusz przy przenosinach strony.

Cache i warstwy pośrednie

Kolejna pułapka to cache. Przeglądarki, systemy operacyjne, CDN-y i reverse proxy przechowują odpowiedzi, aby przyspieszyć działanie strony. Problem w tym, że czasem przechowują również błędy.

Może się zdarzyć, że Ty widzisz już poprawioną wersję, a klient nadal ładuje zapamiętaną odpowiedź z błędem 500. Albo odwrotnie - u Ciebie działa wersja z cache, a nowy użytkownik trafia w świeży błąd.

W takich sytuacjach warto sprawdzić stronę w trybie incognito (prywatnym). Dlaczego? Ponieważ przeglądarka nie korzysta wtedy z zapisanych ciasteczek, lokalnego cache ani aktywnej sesji użytkownika. Otwierasz stronę tak, jak zobaczyłby ją nowy użytkownik - bez zapisanych danych logowania, bez zapamiętanych zasobów i bez rozszerzeń ingerujących w treść.

Bardzo często problem “magicznie znika” albo - przeciwnie - dopiero wtedy się ujawnia.

Użytkownicy korzystają ze strony inaczej niż jej autor

To jedna z najczęstszych, a jednocześnie najbardziej niedocenianych przyczyn problemów.

Jako autor, właściciel lub programista znasz swoją stronę. Wiesz, gdzie kliknąć. Wiesz, jak wygląda poprawna ścieżka użytkownika. Testujesz „książkowy” scenariusz.

Tymczasem realni użytkownicy zachowują się zupełnie inaczej.

Klikają w mniej oczywiste miejsca. Otwierają stronę na telefonie z małym ekranem. Używają starszej wersji przeglądarki. Mają zainstalowane rozszerzenia blokujące skrypty. Próbują wykonać akcje w innej kolejności, niż zakładał projekt.

Może się okazać, że:

  • formularz działa poprawnie, ale tylko przy określonej szerokości ekranu,
  • przycisk jest widoczny na desktopie, ale zasłonięty na telefonie,
  • JavaScript przestaje działać w konkretnej wersji przeglądarki,
  • walidacja blokuje nietypowy, ale poprawny przypadek użycia.

Właściciel strony nigdy tego nie zobaczy, bo nie używa jej w ten sam sposób co użytkownik końcowy.

Dlatego tak ważne jest testowanie w różnych przeglądarkach, na różnych urządzeniach i przy różnych rozmiarach ekranu. Czasem wystarczy zmniejszyć okno przeglądarki albo otworzyć stronę na telefonie, aby zobaczyć problem, który przez miesiące pozostawał niewidoczny.

Blokady i zabezpieczenia

Czasem strona “nie działa” tylko dlatego, że system bezpieczeństwa uznał użytkownika za zagrożenie. Firewalle aplikacyjne, ochrona przed botami czy reguły geolokalizacyjne mogą zablokować określone zakresy IP.

Właściciel strony tego nie zauważy, bo jego adres IP nie jest objęty blokadą. Klient - już tak.

To szczególnie częste przy agresywnych konfiguracjach ochrony przed atakami DDoS.

Przeciążenie serwera

Bywa też, że strona działa poprawnie przy niewielkim ruchu, ale zaczyna zwracać błędy w momentach obciążenia. Kampania reklamowa, newsletter czy promocja w sklepie mogą nagle zwiększyć liczbę zapytań.

Jeżeli serwer lub baza danych nie radzą sobie z obciążeniem, użytkownicy zobaczą błędy 503 albo 504. Ty, testując stronę kilka minut później, możesz już nie trafić na problem.

To sprawia wrażenie “losowej niedostępności”.

Jak sprawdzić, gdzie leży problem?

Największym błędem jest opieranie się wyłącznie na własnym teście w przeglądarce. Potrzebne są dane z różnych lokalizacji i z różnych momentów w czasie.

Dopiero wtedy można odpowiedzieć na pytania: czy problem jest lokalny czy globalny, czy dotyczy całej strony czy tylko konkretnego endpointu, czy występuje stale, czy pod obciążeniem.

Dlatego w Ping.pl umożliwiamy monitorowanie strony z wielu lokalizacji jednocześnie. Dzięki temu wiesz, czy niedostępność dotyczy konkretnego regionu, czy jest problemem globalnym. Otrzymujesz informacje o kodach HTTP, czasie odpowiedzi i możesz reagować zanim klienci zaczną pisać, że “coś nie działa”.