Monitoring sklepu PrestaShop: jak wykryć awarię, zanim zrobi to klient

Najgorsza wiadomość o awarii to ta, która przychodzi od klienta. Znaczy, że sklep nie działał już od jakiegoś czasu, że ktoś próbował kupić i nie mógł, i że dopiero jego frustracja uruchomiła reakcję. Między momentem, w którym coś się psuje, a momentem, w którym się o tym dowiadujesz, uciekają zamówienia. Monitoring istnieje po to, żeby ten odstęp skrócić do minimum, a najlepiej do zera. Dlatego monitoring sklepu PrestaShop jest pierwszą linią obrony.

W sklepie na PrestaShop „działa” to nie jest stan zero-jedynkowy. Strona główna może się otwierać, gdy koszyk jest zepsuty. Sklep może odpowiadać, ale tak wolno, że klient wychodzi. Płatność może być odrzucana tylko dla jednej metody. Dobry monitoring rozumie te odcienie i pilnuje nie tego, czy serwer żyje, tylko tego, czy klient może kupić.

Dlaczego klient zauważa awarię pierwszy

Bez monitoringu sklep obserwuje się przez zamówienia i telefony. To najwolniejszy z możliwych czujników. Jeśli zamówienia spływają nierówno, spadek do zera przez godzinę nie od razu wygląda alarmująco, bo bywały już ciche godziny. Zanim ktoś nabierze podejrzeń, sprawdzi sklep i potwierdzi awarię, mija czas, w którym każda minuta to utracona sprzedaż i klienci, którzy poszli gdzie indziej.

Jest jeszcze gorszy wariant: awaria, która nie kładzie sklepu, tylko go nadgryza. Formularz płatności ładuje się o kilka sekund za długo, jedna metoda dostawy znika z checkoutu, wyszukiwarka przestaje zwracać wyniki dla części fraz. Sklep sprzedaje, więc nic nie krzyczy, a mimo to konwersja spada. Takich usterek nie wychwyci żaden telefon, bo klient nie dzwoni, tylko po cichu wychodzi. Wychwyci je tylko system, który patrzy na sklep bez przerwy i porównuje jego zachowanie z normą.

Warto nazwać ten koszt wprost. Odstęp między awarią a jej wykryciem to nie tylko utracone w tym czasie zamówienia. To także klienci, którzy trafili na niedziałający sklep i już nie wrócą, bo kolejny raz zaczną zakupy gdzie indziej. To budżet reklamowy przepalony na ruch prowadzący donikąd, bo kampania działała, gdy sklep nie sprzedawał. Każda minuta zwłoki mnoży te straty, a jedynym sposobem, żeby je ściąć, jest skrócenie samego odstępu. Do tego właśnie sprowadza się sens monitoringu: nie do tego, żeby awarie się nie zdarzały, bo to niemożliwe, tylko do tego, żeby trwały minuty zamiast godzin.

Monitoring sklepu PrestaShop w czterech warstwach

Sensowny monitoring nie jest jednym narzędziem, tylko zestawem warstw, z których każda patrzy na sklep z innej strony. Dopiero razem dają pełny obraz.

Sklepy, które mają tylko pierwszą warstwę, żyją w złudnym poczuciu bezpieczeństwa. Widzą, że serwer odpowiada, i uznają, że wszystko gra. Tymczasem najkosztowniejsze awarie mieszkają w warstwie poprawności i biznesu, bo tam psuje się to, co bezpośrednio dotyka pieniędzy, a co jest niewidoczne dla prostego sprawdzenia „czy strona się otwiera”.

Monitoring dostępności to dopiero początek

Monitoring dostępności odpowiada na najprostsze pytanie: czy sklep w ogóle odpowiada. Narzędzie odpytuje adres sklepu co kilkadziesiąt sekund z kilku lokalizacji i sprawdza, czy dostaje poprawną odpowiedź. Gdy sklep milknie, wysyła alert. To fundament, bez którego nie ma sensu budować reszty, ale sam w sobie jest wąski.

Pierwsza pułapka to sprawdzanie tylko strony głównej. Strona główna bywa mocno cache'owana i potrafi się wyświetlać nawet wtedy, gdy reszta sklepu leży. Dlatego warto monitorować kilka punktów: stronę główną, kartę produktu, koszyk i wybrany adres, który wymusza połączenie z bazą. Druga pułapka to sprawdzanie z jednej lokalizacji, bo problem sieciowy u jednego dostawcy potrafi wyglądać jak awaria sklepu. Sprawdzanie z kilku miejsc odróżnia realny przestój od lokalnego zakłócenia.

Dostępność warto raportować w procentach w skali miesiąca, bo dopiero wtedy staje się parametrem umowy, a nie wrażeniem. To ta sama liczba, o którą opiera się umowa opieki i SLA: bez pomiaru dostępności nie da się powiedzieć, czy gwarancja z umowy jest dotrzymywana.

Monitoring transakcyjny: czy klient może kupić

Najważniejsza warstwa monitoringu udaje klienta. Zamiast pytać „czy strona odpowiada”, pyta „czy da się kupić”. Zautomatyzowany scenariusz co jakiś czas przechodzi ścieżkę zakupu: wchodzi na kartę produktu, dodaje do koszyka, przechodzi do checkoutu i sprawdza, czy dochodzi do etapu płatności. Jeśli w którymś kroku coś się zatnie, alarm rusza natychmiast, choć strona formalnie działa.

To właśnie ten rodzaj monitoringu wychwytuje awarie najkosztowniejsze i najbardziej podstępne. Zmiana w module płatności po aktualizacji, wygasły certyfikat na bramce, błąd w konfiguracji dostawy, koszyk, który przestał się przeliczać przy jednej walucie. Każda z tych rzeczy zostawia stronę główną nietkniętą, a mimo to zamyka drogę do zakupu. Bez testu transakcyjnego dowiadujesz się o nich z reklamacji, czyli najdrożej, jak się da.

W PrestaShop warto objąć takim testem kilka wariantów ścieżki, bo sklep rzadko ma jeden scenariusz zakupu. Inaczej zachowuje się zamówienie z płatnością online, inaczej za pobraniem, inaczej dla klienta zalogowanego, a inaczej dla gościa. Monitoring, który sprawdza tylko jedną drogę, przeoczy awarię na pozostałych.

Błędy aplikacji i logi, które warto czytać

Pod powierzchnią każdego sklepu płynie strumień zdarzeń: zapytania, błędy, ostrzeżenia. Większość jest nieszkodliwa, ale w tym szumie kryją się wczesne objawy poważnych problemów. Monitoring błędów aplikacji zbiera te zdarzenia w jedno miejsce i pomaga oddzielić tło od sygnału, zanim sygnał stanie się awarią.

Rosnąca liczba błędów bazy danych zapowiada problem z wydajnością albo z integracją. Powtarzające się błędy w jednym module wskazują, że coś się posypało po ostatniej aktualizacji. Nagły wysyp błędów uprawnień albo timeoutów potrafi być pierwszym śladem ataku lub przeciążenia. Żadnego z tych sygnałów nie widać na froncie sklepu, dopóki nie urosną na tyle, by położyć konkretną funkcję.

Sztuka polega na tym, żeby logów nie tyle zbierać, ile z nich korzystać. Sam plik pełen zdarzeń, do którego nikt nie zagląda, niczego nie chroni. Wartość pojawia się wtedy, gdy z logów płyną alerty na progach, które coś znaczą, a regularny przegląd wychwytuje trendy, których pojedynczy alarm nie pokaże.

Progi i alerty: jak nie utonąć w powiadomieniach

Monitoring, który krzyczy o wszystkim, szybko przestaje cokolwiek znaczyć. Gdy alertów jest za dużo, zespół uczy się je ignorować, a wtedy ten jeden ważny ginie w tłumie nieważnych. Nazywa się to zmęczeniem alarmami i jest realnym powodem, dla którego awarie bywają przegapiane mimo działającego monitoringu.

Lekarstwem są dobrze ustawione progi i priorytety. Nie każdy skok czasu odpowiedzi to awaria, więc alarm powinien ruszać dopiero po przekroczeniu progu, który realnie boli, i po utrzymaniu się problemu przez chwilę, a nie po jednym odczycie. Alerty warto dzielić na te, które wymagają natychmiastowej reakcji w nocy, i te, które spokojnie poczekają do rana. Kanał też ma znaczenie: sprawa krytyczna to telefon, sprawa drobna to wpis w raporcie.

Dobrze nastrojony monitoring milczy, gdy wszystko gra, i odzywa się rzadko, ale trafnie. To cisza, która coś znaczy, bo każdy alarm ma wagę. Dojście do tego stanu wymaga trochę pracy nad progami i regularnego korygowania ich w miarę, jak poznaje się rytm konkretnego sklepu.

Powolne pogarszanie: najtrudniejszy przypadek

Najłatwiej wykryć awarię nagłą: sklep działał, po czym przestał. Znacznie trudniej złapać pogarszanie się rozłożone na tygodnie. Baza danych obrasta w dane i zapytania idą coraz wolniej. Kolejny doinstalowany moduł dokłada ułamek sekundy do czasu ładowania. Katalog rośnie, a wraz z nim czas generowania strony kategorii. Każda z tych zmian z osobna jest niezauważalna, a ich suma po kilku miesiącach potrafi podwoić czas ładowania sklepu.

Pojedynczy alarm tego nie złapie, bo w żadnym momencie próg nie zostaje przekroczony gwałtownie. Łapie to dopiero monitoring, który pamięta historię i pokazuje trend. Wykres czasu odpowiedzi z ostatniego kwartału mówi więcej niż setka pojedynczych odczytów: widać na nim, że sklep, który dziś jeszcze mieści się w normie, zmierza w stronę, w której za dwa miesiące norma zostanie przekroczona. To pozwala zadziałać wyprzedzająco, zanim powolne pogarszanie zamieni się w nagły problem w szczycie sprzedaży.

Dlatego monitoring warto czytać nie tylko w trybie alarmowym, ale też w regularnym przeglądzie. Alarm broni przed tym, co dzieje się teraz. Przegląd trendów broni przed tym, co dopiero nadchodzi, i daje czas na spokojną reakcję zamiast gaszenia pożaru.

W praktyce: czym monitorować sklep

Warstwy monitoringu realizuje się kilkoma rodzajami narzędzi, które się uzupełniają. Zewnętrzne usługi kontroli dostępności odpytują sklep z sieci i sprawdzają, czy odpowiada. Scenariusze syntetyczne udają klienta i przechodzą ścieżkę zakupu. Narzędzia obserwujące aplikację zbierają błędy i mierzą czas odpowiedzi poszczególnych fragmentów sklepu. Osobno pilnuje się metryk serwera: obciążenia procesora, pamięci, miejsca na dysku i zachowania bazy danych.

Jest przy tym jedna zasada, o której łatwo zapomnieć: część monitoringu musi stać poza serwerem sklepu. Jeśli cały system obserwacji działa na tej samej maszynie co sklep, to w chwili, gdy maszyna padnie, milknie razem z nim i nikt nie dostanie alertu. Niezależny punkt obserwacji z zewnątrz jest tym, co odróżnia monitoring realny od pozornego. W PrestaShop dużo można wyczytać z własnych logów sklepu i serwera, ale samo w sobie to za mało, bo te źródła giną razem z awarią, którą miały wykryć.

Dobór narzędzi jest wtórny wobec tego, kto na nie patrzy i jak reaguje. Najlepszy zestaw czujników nic nie da, jeśli alerty lądują w skrzynce, do której nikt nie zagląda. Dlatego monitoring ma sens jako część opieki z realnymi czasami reakcji, a nie jako osobna usługa, która tylko generuje powiadomienia. Innymi słowy, wartość monitoringu powstaje dopiero na styku z reakcją: czujnik jedynie wykrywa, a dopiero człowiek albo ustalona procedura zamienia sygnał w naprawę, zanim drobny problem urośnie w awarię widoczną dla klienta.

Monitoring biznesowy: spadek zamówień jako alarm

Najwyższa warstwa monitoringu patrzy nie na technikę, tylko na sprzedaż. Liczba zamówień w danej godzinie ma swój powtarzalny rytm: inny w poniedziałkowy poranek, inny w niedzielny wieczór. Gdy ten rytm nagle się załamie, a technika pozornie działa, to często pierwszy i jedyny sygnał awarii ukrytej głęboko w konfiguracji.

Przykład z życia: sklep po drobnej zmianie w szablonie przestaje poprawnie wyświetlać przycisk zakupu na telefonach, choć na komputerze wszystko gra. Monitoring dostępności milczy, bo strona odpowiada. Monitoring wydajności milczy, bo jest szybko. Dopiero nagły spadek zamówień z urządzeń mobilnych zdradza, że połowa klientów właśnie straciła możliwość zakupu. Warstwa biznesowa łapie to, co przecieka przez wszystkie pozostałe.

Ten poziom monitoringu wymaga poznania sklepu, bo alarm o „zbyt małej sprzedaży” ma sens tylko wtedy, gdy wiadomo, ile jej być powinno o danej porze. To argument za tym, żeby monitoring prowadził ktoś, kto zna Twój sklep i jego sezonowość, a nie anonimowe narzędzie z domyślnymi progami.

Monitoring a umowa SLA

Monitoring i opieka to dwie strony tej samej monety. Umowa SLA obiecuje czas reakcji i poziom dostępności, ale bez monitoringu te obietnice wiszą w próżni. To monitoring uruchamia zegar reakcji w momencie awarii, a nie dopiero wtedy, gdy zdążysz zadzwonić. To on dostarcza też liczb, którymi mierzy się, czy gwarantowana dostępność została dotrzymana.

Dlatego przy wyborze opieki warto traktować monitoring jako warunek, nie dodatek. Pełny obraz tego, co powinna zawierać dobra umowa, opisujemy w przewodniku o opiece powdrożeniowej PrestaShop i umowie SLA. Monitoring jest w nim sercem całości: bez niego reszta parametrów jest tylko deklaracją.

Sprowadza się to do jednej zasady: chcesz dowiadywać się o problemach ze sklepem wcześniej niż Twoi klienci. Dobrze ułożony monitoring, wpięty w opiekę z realnymi czasami reakcji, zamienia awarię z dramatu w rutynowe zgłoszenie obsłużone, zanim ktokolwiek z zewnątrz je zauważy. Tak właśnie działa Sellision Care: sklep jest oglądany bez przerwy, a nie doglądany po fakcie.