Stronę firmową mam od lat i przez większość z nich moja wiedza o tym, czy działa, opierała się na dwóch źródłach: własnej przeglądarce i telefonie od kogoś, kto akurat chciał coś na niej znaleźć. Oba mają tę samą wadę - działają tylko wtedy, kiedy ktoś patrzy. Dodatkowo każdorazowe, ręczne sprawdzenie strony po aktualizacji jest raczej monotonnym zajęciem i często nie da się wyłapać wszystkich błędów. Jeśli ktoś nie ma automatycznych testów, albo nawet nie wie jak się do tego zabrać to warto mieć świadomość, że można do strony podpiąć monitoring, który sam automatycznie ogarnie za nas część rzeczy i będzie działał nawet wtedy, kiedy my pójdziemy spać.

Powodem, przez który zacząłem poważniej zastanawiać się nad automatycznym monitoringiem strony, była zwykła aktualizacja. Zaktualizowałem wtyczki, przeklikałem stronę główną, wyglądało dobrze, poszedłem spać. Trzy dni później okazało się, że formularz kontaktowy nie wysyłał maili, a strona wczytywała się dwa razy wolniej niż wcześniej. Nikt mi tego nie zgłosił..

Uruchomiłem więc monitoring i ustawiłem go sam. Poniżej opisuję, co dokładnie mam włączone i po co, bo to nie jest oczywiste na pierwszy rzut oka: samo „strona się otwiera" to najmniej użyteczna informacja z całego zestawu.

Dostępność, ale z historią

Zacząłem od najprostszej rzeczy: monitor HTTP na stronę główną, sprawdzany co minutę. Do tego osobne monitory na dwie podstrony, które mają dla mnie znaczenie - ofertę i stronę z formularzem kontaktowym. Bo strona główna potrafi działać, kiedy reszta serwisu już nie.

Interwał ustawia się osobno dla każdego monitora, od jednej minuty do dwunastu godzin. Rzeczy krytyczne mam co minutę, mniej ważne co pięć albo piętnaście. Nie ma sensu wszystkiego sprawdzać co minutę tylko dlatego, że można.

Najważniejsze jednak nie jest to, że dostanę alert. Najważniejsza jest historia. Mam oś dostępności z ostatnich 90 dni, listę zdarzeń z konkretnymi godzinami i powodami, oraz procent uptime za okres. To jest ta rzecz, która zmienia rozmowę z hostingiem: zamiast „mam wrażenie, że coś się dzieje po nocach", pokazuję listę przerw z datami i czasem trwania. Trudno z tym dyskutować.

Alerty wysyłane są e-mailem, jako powiadomienia push w przeglądarce i na telefon przez ntfy. Ja mam wszystkie trzy, bo każdy działa w innej sytuacji. Godziny w mailach są w mojej strefie czasowej, więc nie muszę w głowie przeliczać UTC o drugiej w nocy.

Jest jeszcze jeden ekran, na który patrzę codziennie rano: „Wymaga uwagi". Jeśli nic nie leży i żaden certyfikat nie wygasa w najbliższym czasie, jest pusty. To zaskakująco przyjemne uczucie.

Szybkość, czyli to, czego alert o awarii nie złapie

Awaria jest łatwa. Gorsza jest sytuacja, w której strona odpowiada, tylko coraz wolniej - po aktualizacji, po dodaniu wtyczki, po tym jak hosting dołożył sąsiadów na tym samym serwerze.

Do tego służy pomiar czasu odpowiedzi serwera (TTFB, czyli czas do pierwszego bajtu). Mierzony jest co minutę, a nie raz na jakiś czas z jednego kliknięcia, i pokazywany jako mediana i P95 dzień po dniu. Dzięki temu mam baseline - wiem, ile moja strona odpowiada „normalnie", i widzę na wykresie moment, w którym to się zmieniło.

Kiedy TTFB rośnie i tak zostaje, zwykle znaczy to jedną z trzech rzeczy: przeciążony serwer, wolne zapytania do bazy albo wyłączony cache. Nie zawsze wiem od razu którą, ale wiem, kiedy się zaczęło - a to zwykle wystarczy, żeby dojść do przyczyny.

Regresje po wdrożeniach i po zmianach SEO

To dla mnie najważniejsza część i powód, dla którego w ogóle to uruchomiłem.

Raz dziennie strona przechodzi audyt kondycji. Sprawdzanych jest kilkadziesiąt rzeczy w pięciu kategoriach: dostępność, bezpieczeństwo, SEO, dobre praktyki i wydajność (ta ostatnia na podstawie Core Web Vitals z realnych pomiarów użytkowników Chrome, czyli danych CrUX od Google). Wynik jest porównywany z poprzednim audytem.

Z rzeczy, które faktycznie zmieniają mi życie po wdrożeniu:

  • Indeksowanie - czy nie wleciał noindex w meta robots albo w nagłówku X-Robots-Tag. To jest ten jeden błąd, który potrafi wyciąć stronę z Google i nie zostawić po sobie żadnego widocznego śladu.
  • Tytuł, meta description, adres kanoniczny, H1, atrybut lang - czyli rzeczy, które ktoś potrafi nadpisać przy okazji zmiany szablonu.
  • Mixed content - zasoby ładowane po HTTP na stronie HTTPS. Klasyk po wgraniu obrazków ze starego adresu, kończy się zniknięciem kłódki.
  • Łańcuch przekierowań - czy do strony nie prowadzą dwa skoki zamiast jednego.
  • Nagłówki bezpieczeństwa (HSTS, CSP, X-Frame-Options, flagi cookies) - te zwykle nie znikają same, ale znikają przy zmianie konfiguracji serwera i dobrze wiedzieć o tym od razu.

Kluczowa jest jednak forma, w jakiej to dostaję. Historia audytów to nie lista uruchomień, tylko dziennik zmian: wpis powstaje wtedy, gdy coś się zepsuło, naprawiło albo zmieniło, plus wpis kontrolny raz na tydzień, żeby było widać, że nadal patrzymy. Nie przekopuję się więc przez trzydzieści identycznych raportów miesięcznie - widzę pięć dat, w których coś się realnie ruszyło.

Do każdej wykrytej regresji dostaję kontekst z tego samego okna czasowego: czy zmieniła się treść strony, czy zniknęły jakieś nagłówki, czy zmienił się serwer, o ile urósł HTML, czy doszło przekierowanie. To zamienia „coś się popsuło" w „popsuło się wtedy, kiedy zmieniłeś X".

Osobno liczony jest wynik samej strony, bez CrUX. Ma to sens: Core Web Vitals potrafią się ruszyć bez żadnej zmiany po mojej stronie, więc alerty o regresji wyzwala tylko ta część wyniku, na którą naprawdę mam wpływ.

Monitoring treści, czyli wykrywanie „działa, ale nie do końca"

Serwer potrafi odpowiadać kodem 200 i wyświetlać komunikat o błędzie bazy danych. Dla klasycznego monitoringu wszystko jest w porządku, dla odwiedzającego zdecydowanie nie.

Dlatego na stronę oferty mam włączony monitoring treści. Możesz podać tutaj do pięciu fraz i wybrać jeden z trybów:

  • musi zawierać - u mnie to fragment tekstu z sekcji, która renderuje się dynamicznie. Jak znika, coś nie doładowało.
  • nie może zawierać - „Error establishing a database connection", „Fatal error", „Warning:". Po nieudanej aktualizacji PHP albo wtyczki to jest dokładnie to, co się pojawia na stronie.

Kosztuje mnie to jedną minutę konfiguracji i wyłapało już dwie sytuacje, których nie zauważyłbym przez kilka dni.

DNS, czyli strona i poczta

Rekordy DNS to rzecz, którą ustawia się raz i o której się zapomina - do momentu, w którym ktoś (czasem hosting, czasem rejestrator, czasem ja sam o północy) coś w nich zmieni.

Mam trzy monitory DNS:

  • rekord A dla domeny - żeby wiedzieć, że strona wskazuje na ten serwer, na który ma wskazywać. Przydaje się szczególnie przy migracji, kiedy chcę widzieć, kiedy zmiana faktycznie się rozeszła.
  • rekord MX - poczta. To był mój najbardziej bolesny brak. Zniknięcie MX nie objawia się niczym widocznym: strona działa, panel działa, tylko maile przestają przychodzić i człowiek dowiaduje się o tym po tygodniu, przypadkiem.
  • rekord TXT z SPF - żeby moje maile nadal trafiały do skrzynek, a nie do spamu.

Przy każdym monitorze wybiera się tryb dopasowania. „Zawiera" oznacza, że wymagane wartości muszą być obecne, a dodatkowe rekordy są w porządku - to bezpieczne ustawienie na co dzień. „Dokładnie" wymaga, żeby odpowiedź była dokładnie taka, jak zadeklarowana, i tylko ten tryb wykryje dodany rekord, czyli to, jak wygląda cudza ingerencja w strefę. Dla MX i SPF trzymam tryb dokładny.

Jak coś nie zgadza się z oczekiwaniem, w alercie i w szczegółach monitora widzę wprost, czego się spodziewałem i co odpowiedział resolver. To jest cała diagnostyka awarii DNS w jednym zdaniu.

NAS i inne rzeczy, które nie są stroną WWW

Mam w firmie NAS-a, na którym trzymam kopie zapasowe. Nie ma sensu odpytywać go jak strony internetowej, więc korzystam z monitora portu TCP: aplikacja po prostu otwiera połączenie na wskazany port i mierzy, ile trwało nawiązanie. Odpowiedział - działa.

Ma to jedną praktyczną przewagę nad sprawdzaniem panelu przez HTTP: interfejs webowy NAS-a potrafi budzić się wolno i wtedy zwykłe sprawdzenie HTTP potrafi zgłosić fałszywy alarm, mimo że urządzenie jest całe czas dostępne. Port odpowiada od razu, więc alerty są prawdziwe zamiast nerwowe.

Jeżeli mimo wszystko coś siedzi na wolnym łączu i zdarzają się pojedyncze fałszywe alarmy, jest opcja obniżonej czułości - monitor daje wtedy urządzeniu więcej czasu na odpowiedź, zanim uzna je za niedostępne.

Nie muszę być jedyną osobą, która to widzi

To była ostatnia rzecz, którą ustawiłem, i szkoda, że nie pierwsza. Wcześniej wszystkie alerty szły wyłącznie do mnie, więc kiedy byłem na urlopie albo po prostu poza zasięgiem, awaria czekała na mój powrót.

Teraz jeden z pracowników ma własne darmowe konto i jest dodany do mojego zespołu. Wygląda to tak:

  • Jego konto jest niezależne od mojego. Nie dzielimy się loginem, nie muszę mu dawać dostępu do swoich ustawień ani rozliczeń.
  • Udostępniam mu wybrane monitory, nie wszystko. Widzi statusy i statystyki tych stron i usług, za które faktycznie odpowiada.
  • Ustawia sobie własne alerty i własne kanały powiadomień. Ja mam ntfy na telefonie, on woli e-mail i push w przeglądarce. Nie musimy się w tej sprawie dogadywać.
  • Domyślnie może tylko przeglądać - nie usunie ani nie przestawi mi monitora. Jeśli komuś chcę dać więcej, jest osobne uprawnienie edytora: może zmieniać ustawienia udostępnionych monitorów, ale nadal nie dodaje nowych i nie kasuje istniejących.

Efekt jest prosty: alert o niedostępności w środku dnia trafia do dwóch osób naraz i reaguje ta, która akurat może. Awaria, o której obie osoby wiedzą w minutę, przestaje być kryzysem.

Gdybym zaczynał od nowa

Kolejność, którą bym powtórzył:

  1. Monitor HTTP na stronę główną i dwie najważniejsze podstrony, co 1-5 minut, z alertem na e-mail i telefon.
  2. Monitoring certyfikatu SSL z ostrzeżeniem na 30, 14 i 7 dni przed wygaśnięciem. Certyfikaty wygasają wyłącznie w weekend.
  3. Monitoring kondycji z alertem o regresji - to jest ta rzecz, która pilnuje wdrożeń i zmian SEO.
  4. Monitory DNS na A, MX i SPF. Zwłaszcza MX.
  5. Monitor treści z frazą, która musi być na stronie, i z komunikatem błędu, którego być nie może.
  6. Monitor portu TCP na NAS-a i inne urządzenia, które nie są stroną WWW.
  7. Drugie konto w zespole z dostępem do monitorów i własnymi alertami.

To jest jakieś pół godziny konfiguracji łącznie. W zamian przestaję zgadywać, czy „coś się zmieniło po tej aktualizacji" - po prostu to widzę, z datą i godziną.