O awarii nie powinien informować klient. Prosty skrypt sprawdzający co kilka minut kosztuje niewiele i wyprzedza pierwsze zgłoszenie.
Co sprawdzać
Nie samą odpowiedź serwera, tylko obecność konkretnej treści na stronie. Serwer potrafi zwracać poprawny kod przy zupełnie pustej stronie.
Dobrym znacznikiem jest fragment pochodzący z bazy: nazwa produktu, pozycja menu, liczba w stopce. Taki tekst pojawia się tylko wtedy, gdy działa cała droga od zapytania do wyświetlenia. Stały napis wpisany w szablon świadczy jedynie o tym, że serwer oddał plik.
Ścieżki krytyczne
Strona główna to za mało. Warto sprawdzać logowanie, koszyk, wyszukiwarkę — miejsca, których awaria kosztuje najwięcej.
Poza samą stroną są jeszcze usługi, których klient nie widzi, a które zatrzymują pracę firmy: wymiana danych z systemem magazynowym, pobieranie zamówień, wysyłka poczty. Ich awaria bywa cichsza i droższa, bo wychodzi na jaw dopiero przy porównaniu stanów.
Sprawdzanie ścieżki wymagającej logowania warto oprzeć na osobnym koncie kontrolnym o minimalnych uprawnieniach. Konto pracownika użyte do tego celu prędzej czy później zostanie zablokowane albo zmieni hasło i kontrola przestanie działać.
Sprawdzanie z zewnątrz
Skrypt uruchamiany na tym samym serwerze nie wykryje awarii sieci ani samego serwera. Kontrola musi przychodzić z innego miejsca.
Do tego potrzeba drugiego, taniego środowiska i uzgodnienia jednej rzeczy: adres kontrolny nie może być blokowany przez zabezpieczenia przed nadmiernym ruchem. Inaczej po kilku dniach zaczną się alarmy o awarii, której nie ma.
Ograniczanie fałszywych alarmów
Powiadomienie dopiero po dwóch lub trzech nieudanych próbach z odstępem. Alarm przy każdym chwilowym przerwaniu połączenia szybko przestaje być czytany.
Warto też rozróżnić rodzaj niepowodzenia. Brak odpowiedzi, błąd serwera i poprawna strona bez oczekiwanej treści to trzy różne sytuacje i prowadzą do różnych działań. Jak formułować takie wiadomości, opisuje tekst o powiadomieniach z serwera.
Termin ważności certyfikatu
Sprawdzany razem z dostępnością. Wygasły certyfikat blokuje dostęp równie skutecznie jak awaria i zdarza się częściej.
Ostrzeżenie ma sens z wyprzedzeniem kilkunastu dni, a nie w dniu wygaśnięcia. Dotyczy to także odnawiania automatycznego — mechanizm bywa sprawny do momentu zmiany adresu albo konfiguracji serwera i wtedy przestaje działać po cichu. Ta sama kontrola powinna objąć terminy ważności domeny.
Czas odpowiedzi
Warto zapisywać, nie tylko sprawdzać. Narastające spowolnienie zapowiada awarię z kilkudniowym wyprzedzeniem.
Przyczyna bywa prozaiczna: rosnąca tabela bez indeksu, zadanie cykliczne, które wydłuża się z tygodnia na tydzień, albo kończące się miejsce. Zestawienie czasów odpowiedzi obok wpisów z dzienników zdarzeń zwykle wskazuje moment, w którym coś się zmieniło. Bez zapisu historii zostaje wrażenie, że „ostatnio jakby wolniej działa", którego nie da się sprawdzić.
