Wchodzisz na stronę firmy i zamiast oferty widzisz biały ekran, komunikat o błędzie albo stronę, która ładuje się bez końca. W sklepie sytuacja może być mniej oczywista. Strona główna działa, ale nie można dodać produktu do koszyka, przejść do płatności albo złożyć zamówienia.
W takiej sytuacji najważniejsze jest szybkie ustalenie, co dokładnie przestało działać, od kiedy trwa problem i czy bezpośrednio przed nim coś się zmieniło. Te trzy informacje często skracają diagnostykę bardziej niż kolejne próby naprawy.
Pierwsze 15 minut warto wykorzystać przede wszystkim na zawężenie przyczyny i ograniczenie skutków awarii.
Najpierw sprawdź, co właściwie nie działa
„Strona nie działa” może oznaczać kilka zupełnie różnych sytuacji. Domena może w ogóle się nie otwierać. Strona może wyświetlać błąd. Może działać strona główna, ale nie działać formularz. W sklepie można przeglądać produkty, a problem pojawia się dopiero podczas składania zamówienia.
Dlatego pierwszym krokiem powinno być sprawdzenie strony z innego urządzenia i innego połączenia z internetem. Najprościej otworzyć ją na telefonie z wyłączonym Wi-Fi. Warto również sprawdzić kilka najważniejszych podstron oraz wykonać podstawową czynność, dla której strona istnieje.
Jeżeli prowadzisz sklep, dodaj produkt do koszyka i przejdź do checkoutu. Jeżeli strona pozyskuje klientów, otwórz formularz kontaktowy. Jeżeli użytkownicy logują się do systemu, sprawdź logowanie.
To ważne, ponieważ działająca strona główna nie oznacza jeszcze, że działa sprzedaż.
Sprawdź, czy problem dotyczy wszystkich użytkowników
Jeżeli strona działa na telefonie, ale nie otwiera się na komputerze, problem może dotyczyć lokalnej sieci, przeglądarki albo zapisanych danych. Jeżeli nie działa niezależnie od urządzenia i połączenia, można przejść dalej.
Warto również sprawdzić pocztę działającą w tej samej domenie. Jeżeli jednocześnie przestała działać strona i poczta, przyczyna może znajdować się po stronie domeny lub DNS, a nie samej aplikacji.
Sprawdź też panel firmy hostingowej i jej stronę ze statusem usług. Kilka minut wystarczy, aby wykluczyć awarię infrastruktury dostawcy.
Zapisz dokładnie to, co widzisz
Komunikat błędu jest przydatną informacją diagnostyczną. Nie zamykaj go i nie ograniczaj zgłoszenia do wiadomości „strona padła”.
Zrób zrzut ekranu. Zapisz adres strony, na której wystąpił problem, godzinę oraz czynność wykonywaną bezpośrednio przed błędem.
Informacja „o 14:37 po kliknięciu Zapłać strona zwraca błąd 500” jest dla osoby technicznej znacznie bardziej użyteczna niż „od jakiegoś czasu sklep nie działa”.
Jeżeli problem pojawia się tylko czasami, również warto to zaznaczyć. Awaria występująca przy co piątej próbie może wskazywać na zupełnie inną przyczynę niż strona niedostępna bez przerwy.
Sprawdź, co wydarzyło się tuż przed awarią
Jedno z pierwszych pytań podczas diagnostyki powinno brzmieć: co zmieniło się przed wystąpieniem problemu?
Czy ktoś aktualizował stronę? Czy została zainstalowana nowa wtyczka? Czy programista wdrożył nową wersję? Czy zmieniana była konfiguracja hostingu, domeny albo poczty? Czy rozpoczęła się kampania reklamowa i na stronę trafiło znacznie więcej użytkowników niż zwykle?
W przypadku sklepu warto sprawdzić również zmiany dotyczące płatności, dostaw, integracji z magazynem, systemem ERP lub zewnętrznym API.
Jeżeli strona działała przez kilka miesięcy bez problemu i przestała działać kilka minut po aktualizacji, jest to jedna z najważniejszych informacji dla osoby rozpoczynającej diagnostykę.
Nie każda awaria wygląda jak awaria
Najbardziej widoczny przypadek to całkowicie niedostępna strona. Z punktu widzenia firmy znacznie groźniejsza może być jednak sytuacja, w której witryna wygląda poprawnie, ale przestał działać jeden z procesów odpowiedzialnych za sprzedaż.
Formularz może wyświetlić komunikat o poprawnym wysłaniu, mimo że wiadomość nie trafia do firmy. Klient może zapłacić za zamówienie, ale informacja o płatności nie wróci do sklepu. Zamówienia mogą wpadać do WooCommerce, ale nie być przekazywane dalej. Kod rabatowy może przestać działać. System może nie aktualizować stanów magazynowych.
Dlatego podczas awarii warto sprawdzić nie tylko dostępność strony, ale również najważniejszą ścieżkę prowadzącą do przychodu.
Jeżeli to sklep, sprawdź ostatnie zamówienia
W e-commerce jednym z pierwszych miejsc do sprawdzenia jest lista zamówień.
Jeżeli sklep zwykle otrzymuje kilka zamówień na godzinę, a od dwóch godzin nie pojawiło się żadne, nie musi to jeszcze oznaczać problemu, ale jest to sygnał wymagający sprawdzenia.
Zobacz, czy pojawiają się nowe zamówienia, jakie mają statusy i czy nie rośnie liczba płatności rozpoczętych, ale niedokończonych. Jeżeli korzystasz z zewnętrznej bramki płatniczej, sprawdź również jej panel.
Może się okazać, że płatności są przyjmowane prawidłowo, ale sklep nie otrzymuje informacji zwrotnej. Wtedy problem wygląda zupełnie inaczej niż awaria samej bramki.
Na stronie usługowej odpowiednikiem zamówienia jest zwykle formularz kontaktowy, rezerwacja albo inne zgłoszenie.
Wyślij testowe zapytanie i sprawdź cały proces. Nie wystarczy zobaczyć komunikat „wiadomość została wysłana”. Sprawdź, czy zgłoszenie rzeczywiście pojawiło się na właściwej skrzynce, w CRM albo w systemie obsługującym leady.
Jeżeli reklamy nadal kierują użytkowników na stronę, a formularz od kilku godzin nie dostarcza wiadomości, firma może płacić za ruch prowadzący do niedziałającego procesu sprzedażowego.
Sprawdź, czy problem nie zaczął się po aktualizacji
W WordPressie i WooCommerce częstą przyczyną awarii jest konflikt po aktualizacji wtyczki, motywu, samego WordPressa albo wersji PHP.
Nie oznacza to, że należy od razu wyłączać wszystkie wtyczki. Najpierw warto ustalić, czy aktualizacja faktycznie odbyła się w czasie, w którym pojawił się problem.
Jeżeli awaria zaczęła się bezpośrednio po konkretnej zmianie, bezpieczniejsze jest sprawdzenie i ewentualne wycofanie właśnie tej zmiany niż modyfikowanie kolejnych elementów strony.
Nie przywracaj od razu kopii zapasowej
Backup daje poczucie bezpieczeństwa, ale jego przywrócenie nie powinno być pierwszą reakcją.
Jeżeli przyczyna leży po stronie domeny, certyfikatu, hostingu albo zewnętrznej usługi, kopia niczego nie naprawi. Może za to cofnąć dane zapisane od momentu jej wykonania.
W sklepie oznacza to potencjalnie zamówienia, klientów i zmiany stanów magazynowych. Na stronie usługowej mogą to być zgłoszenia, rezerwacje lub nowe treści.
Przed odtworzeniem kopii trzeba wiedzieć, z którego momentu pochodzi i jakie dane zostaną cofnięte.
Nie próbuj kilku napraw jednocześnie
Podczas awarii łatwo wpaść w schemat kolejnych prób. Wyłączyć wtyczkę, zmienić ustawienie, zrestartować usługę, przywrócić plik i sprawdzić, czy już działa.
Problem pojawia się wtedy, gdy kilka zmian zostanie wykonanych jednocześnie. Nawet jeśli strona wróci, trudno później ustalić przyczynę. Przy kolejnej awarii cały proces zaczyna się od początku.
Dobra diagnostyka polega na zawężaniu problemu. Najpierw ustala się warstwę odpowiedzialną za awarię, następnie przyczynę, a dopiero później wykonuje możliwie małą zmianę potrzebną do przywrócenia działania.
Kiedy wyłączyć reklamy
Jeżeli prowadzisz płatne kampanie, decyzja o ich zatrzymaniu zależy od rodzaju awarii.
Przy całkowicie niedostępnej stronie dalsze kierowanie płatnego ruchu zwykle nie ma sensu. Podobnie jest wtedy, gdy nie działa checkout, formularz kontaktowy albo inny proces będący celem kampanii.
Nie zawsze trzeba jednak zatrzymywać wszystko. Jeżeli problem dotyczy jednej części serwisu, można ograniczyć tylko kampanie prowadzące do niedziałających stron lub funkcji.
Warto pamiętać o tym punkcie szczególnie wtedy, gdy budżet reklamowy jest wysoki. Naprawa techniczna może potrwać godzinę, ale przez tę godzinę kampanie nadal mogą generować koszt.
Po przywróceniu strony sprawdź, czy sprzedaż również wróciła
Moment, w którym strona ponownie się otwiera, nie zawsze jest końcem awarii.
Po naprawie trzeba ponownie przejść najważniejszy proces. W sklepie będzie to dodanie produktu do koszyka, checkout i płatność. Na stronie usługowej wysłanie formularza. W aplikacji logowanie i wykonanie jednej z podstawowych operacji.
Warto również sprawdzić, co wydarzyło się podczas przerwy. Czy powstały zamówienia wymagające ręcznej obsługi? Czy płatności zostały pobrane bez utworzenia zamówień? Czy zgłoszenia oczekują w zewnętrznym systemie? Czy integracja powinna ponownie przesłać pominięte dane?
Przywrócenie strony i uporządkowanie skutków awarii to dwa osobne etapy.
Co powinno wydarzyć się w pierwszych 15 minutach
Po pierwszym kwadransie nie zawsze trzeba znać przyczynę awarii. Powinno być jednak wiadomo znacznie więcej niż na początku.
Czy problem dotyczy całej strony czy jednej funkcji. Czy użytkownicy mogą nadal składać zamówienia lub wysyłać zapytania. Kiedy pojawił się pierwszy błąd. Czy wcześniej została wykonana aktualizacja lub wdrożenie. Czy problem występuje u wszystkich użytkowników. Czy trzeba ograniczyć kampanie reklamowe. Kto ma dostęp potrzebny do dalszej diagnostyki.
Na tej podstawie można zdecydować, czy problem da się szybko usunąć, czy potrzebna jest pomoc techniczna.
Najwięcej czasu podczas awarii traci się przed jej wystąpieniem
Brzmi przewrotnie, ale czas naprawy często zależy od rzeczy, które powinny zostać przygotowane dużo wcześniej.
Jeżeli podczas awarii trzeba dopiero ustalać, kto ma dostęp do hostingu, gdzie zarządzana jest domena, kto posiada konto do bramki płatniczej i gdzie znajdują się kopie zapasowe, pierwsze kilkadziesiąt minut znika bez rozpoczęcia właściwej diagnostyki.
Podobnie jest z monitoringiem. Jeżeli jedynym źródłem informacji o problemie jest telefon klienta, nie wiadomo nawet dokładnie, kiedy awaria się rozpoczęła.
Monitoring powinien wykrywać nie tylko całkowity brak odpowiedzi strony. W zależności od serwisu warto kontrolować również błędy aplikacji, certyfikat SSL, czas odpowiedzi oraz działanie procesów istotnych dla sprzedaży.
Kiedy warto mieć stałe wsparcie techniczne
Jeżeli strona lub sklep odpowiada za pozyskiwanie klientów i sprzedaż, sposób reagowania na awarię warto ustalić wcześniej.
Znaczenie ma nie tylko to, kto potrafi naprawić stronę. Ważne jest również, kto otrzyma alert, kto ma wymagane dostępy, jaki jest czas reakcji i co dzieje się poza standardowymi godzinami pracy.
W Dock utrzymujemy strony, sklepy i aplikacje oparte między innymi o WordPress, WooCommerce, PrestaShop i Laravel. Przed rozpoczęciem utrzymania zbieramy potrzebne dostępy, poznajemy środowisko i ustalamy sposób reagowania na zgłoszenia. Dzięki temu podczas awarii nie zaczynamy od pytania, gdzie znajduje się serwer i kto ma do niego hasło.
Jeżeli Twoja strona właśnie nie działa, możemy sprawdzić problem i określić kolejne kroki. Jeżeli działa, ale jest ważnym elementem sprzedaży, warto przygotować sposób reagowania zanim pojawi się pierwsza poważna awaria.
