Monitoring sklepu internetowego: jak wykryć awarię, zanim zauważą ją klienci

W piątek o osiemnastej synchronizacja stanów magazynowych przestaje chodzić. Nikt tego nie widzi, bo sklep wygląda normalnie: produkty są, ceny są, zamówienia wpadają. W poniedziałek rano okazuje się, że przez weekend sprzedało się kilkanaście sztuk towaru, którego nie ma na magazynie, a część pozycji stoi na cenie sprzed piątkowej podwyżki w hurtowni.

Na tym polega różnica między pracą ręczną a automatem. Człowiek, który przepisuje cennik, wie, kiedy go nie przepisał. Automat, który padł, nie mówi nic. Zostawia po sobie dane wyglądające dokładnie tak samo jak wczoraj i to jest cała informacja, jaką dostajesz.

Dlatego ostatnią warstwą każdego wdrożenia jest nadzór. Nie dlatego, że coś jest źle zbudowane, tylko dlatego, że wszystko, co ma zależności na zewnątrz, kiedyś się o nie potknie.

Cztery sposoby, na jakie pada automatyzacja

Awaria rzadko wygląda jak awaria. W praktyce spotykamy cztery scenariusze i tylko pierwszy jest oczywisty:

• proces nie wstał: serwer poszedł w restart, zapełnił się dysk, ktoś posprzątał zadania cykliczne. Automat po prostu nie istnieje i nigdy się nie odezwie,
• źródło się zmieniło: hurtownia dołożyła kolumnę do pliku, przestawiła kodowanie albo przeniosła plik pod inny adres. Automat czyta i nie rozumie tego, co czyta,
• dostęp wygasł: zmienione hasło, token API po roku, wygasły certyfikat. Klasyk, bo o terminie ważności pamięta wyłącznie system, który go wystawił,
• automat działa, ale kłamie: najgroźniejszy przypadek. Plik przyszedł ucięty w połowie, serwer odpowiedział poprawnie pustą listą, a integracja posłusznie zapisała tę pustkę do sklepu. Formalnie wszystko przeszło. Faktycznie właśnie zniknęła połowa katalogu.

Czwarty scenariusz ma swoją wersję w każdej technologii i to on decyduje o tym, jak trzeba budować nadzór. Asystent AI, którego pilnujemy na tej stronie, przy awarii modelu językowego dalej odpowiada poprawnym kodem, tylko treść odpowiedzi jest zastępcza. Monitoring patrzący wyłącznie na kod odpowiedzi zapali zielone światło nad botem, który od trzech dni mówi klientom, że coś się posypało. Nadzór musi czytać treść, nie nagłówek.

Trzy poziomy nadzoru

Monitoring to nie jedna rzecz, tylko trzy pytania zadawane osobno:

• puls: czy to w ogóle odpowiada. Najtańsze, najszybsze i najmniej mówiące. Wyłapuje wyłączony serwer i praktycznie nic poza tym,
• przebieg: czy zadanie ruszyło o czasie i skończyło się bez błędu. Tu wychodzi zadanie cykliczne, które nie wystartowało po restarcie, i skrypt przerwany w połowie,
• sens danych: czy wynik wygląda rozsądnie. Czy liczba zaktualizowanych pozycji nie spadła nagle do zera, czy plik nie schudł o połowę, czy cena zakupu nie zmieniła się o rząd wielkości.

Gotowe narzędzia z półki obsługują zwykle poziom pierwszy i to w zupełności wystarcza stronie wizytówce. Przy automatyzacji, która realnie przestawia coś w firmie, cokolwiek gwarantuje dopiero poziom trzeci. Jest też najtrudniejszy, bo wymaga wiedzy o tym, jak wygląda normalny dzień: ile pozycji zwykle się zmienia, o której kończy się przebieg, jaki rozrzut cen jest naturalny dla danej branży. Tej wiedzy nie da się kupić w abonamencie, ona bierze się z konkretnego wdrożenia.

Dobrze zbudowane integracje z hurtowniami mają zresztą część tej logiki wbudowaną od środka, w postaci bezpieczników wstrzymujących aktualizację przy podejrzanych danych. Nadzór z zewnątrz jest drugą parą oczu, która patrzy na to samo z innej strony i wyłapuje sytuacje, w których nie zadziałał sam bezpiecznik.

Alert, który ktoś przeczyta

Wykrycie awarii jest tylko połową roboty. Druga połowa to doprowadzenie informacji do człowieka, który może coś z nią zrobić. Trzy rzeczy decydują o tym, czy alert zadziała:

• kanał, w który ludzie i tak patrzą: komunikator firmowy, mail, przy zdarzeniach krytycznych SMS. Powiadomienie lądujące w panelu otwieranym raz w tygodniu nie jest powiadomieniem,
• treść z konkretem: co padło, od kiedy, co z tego wynika dla sprzedaży i od czego zacząć. Sam komunikat o błędzie zmusza do śledztwa, zanim ktokolwiek ruszy z naprawą,
• tłumik na powtórki: bez niego jedna awaria oznacza dwieście identycznych wiadomości w ciągu nocy i wyciszony kanał następnego dnia.

Zasada, do której doszliśmy przez lata, brzmi: alarm ma być rzadki. Powiadomienie przychodzące codziennie przestaje być alarmem i staje się tapetą, którą przewija się bez czytania. Lepiej pilnować pięciu rzeczy naprawdę ważnych i reagować na każdą, niż mieć sto czujników i wyrobiony odruch ignorowania ich wszystkich.

Ile kosztuje pilnowanie

Nadzór jest tańszy, niż większość ludzi zakłada, bo znakomita większość sprawdzeń nic nie kosztuje. Zapytanie o kod odpowiedzi, porównanie rozmiaru pliku z logiem błędów, sprawdzenie godziny ostatniego udanego przebiegu: to wszystko można powtarzać co godzinę przez rok i nie wygenerować żadnego kosztu poza prądem.

Płatny bywa wyłącznie test najgłębszy, czyli przejście całej ścieżki tak, jak zrobiłby to klient. Przy asystencie AI oznacza to jedną prawdziwą rozmowę dziennie, kosztującą grosze. Stąd układ, który sprawdza się najlepiej: tanie sprawdzenie często, kosztowny test raz na dobę.

Osobna sprawa, o której prawie nikt nie pamięta, to terminy. Klucze API, hasła i certyfikaty mają daty ważności i wygasają zwykle w najgorszym możliwym momencie. Prosty rejestr terminów z przypomnieniem tydzień wcześniej kosztuje godzinę pracy przy wdrożeniu i oszczędza cały dzień gaszenia pożaru w środku sezonu.

Co się zmienia po wdrożeniu

Nadzór nie sprawia, że nic się nie psuje. Sprawia, że przestajesz dowiadywać się o awariach ostatni:

• o awarii mówi system, nie klient: wiadomość przychodzi w minuty, zamiast wychodzić z reklamacji albo ze słabszego tygodnia w statystykach,
• weekend zostaje weekendem: piątkowy pad nie czeka do poniedziałku, bo powiadomienie idzie na telefon niezależnie od tego, gdzie akurat jesteś,
• znika poranne sprawdzanie: przestajesz wchodzić co rano i ręcznie weryfikować, czy na pewno się zsynchronizowało. To zwykle ostatnia czynność, która trzymała człowieka przy zautomatyzowanym procesie,
• naprawa jest krótka: alert z konkretem prowadzi prosto do przyczyny, zamiast zaczynać się od pytania, co właściwie i od kiedy nie działa.

Automatyzacja bez nadzoru działa świetnie do pierwszej awarii. Z nadzorem działa dalej, a o problemach dowiadujesz się pierwszy.

Najczęstsze pytania o monitoring

Czym monitoring automatyzacji różni się od sprawdzania, czy strona działa?

Sprawdzanie dostępności odpowiada tylko na pytanie, czy serwer odpowiada. Automatyzacja potrafi paść przy całkowicie sprawnym serwerze: zadanie cykliczne nie wystartowało, hurtownia zmieniła format pliku, integracja zapisała pustkę. Monitoring automatyzacji pilnuje przebiegów i sensu danych, a nie samego adresu strony.

Jak często sprawdzać, czy automat działa?

Częstotliwość powinna wynikać z rytmu pracy automatu. Synchronizację godzinną warto sprawdzać co godzinę, przebieg nocny raz dziennie tuż po jego zakończeniu. Sprawdzanie rzadsze niż praca automatu zostawia okno, w którym błąd zdąży narobić szkód.

Gdzie powinny trafiać alerty o awarii?

Tam, gdzie zespół i tak patrzy: komunikator firmowy, mail, przy zdarzeniach krytycznych SMS. Alert w miejscu otwieranym raz w tygodniu nie jest alertem. Potrzebny jest też tłumik na powtórki, bo kanał zalany tą samą wiadomością zostaje wyciszony i przestaje pełnić swoją rolę.

Co zrobić z fałszywymi alarmami?

Traktować je jak błąd w monitoringu, a nie jak koszt stały. Każdy fałszywy alarm obniża czujność wobec prawdziwych i po kilku tygodniach powiadomienia przestają być czytane. Progi trzeba dopasować do tego, jak wygląda normalny przebieg w danej firmie, a nie ustawiać z sufitu.

Czy da się objąć monitoringiem automatyzację zbudowaną przez kogoś innego?

Tak i jest to częsty przypadek. Nadzór działa z zewnątrz: sprawdza wyniki, terminy przebiegów i dane wyjściowe, więc nie wymaga przepisywania istniejących skryptów ani wchodzenia w ich środek. Bywa to najtańszy sposób, żeby w ogóle ustalić, czy stara integracja nadal działa. Zapytaj o szczegóły.