Co uruchamiam przed snem

Każdego wieczoru, zanim zamknę laptopa, uruchamiam jedno polecenie. Sprawdza ono 15 000 stron w moim środowisku produkcyjnym: każdy wpis na blogu, każdą stronę firmową, każdy programowy przewodnik, każdy wariant językowy. Dla każdej strony weryfikuje status HTTP, mierzy TTFB, sprawdza status cache Cloudflare i rejestruje wszelkie błędy. Kompleksowe sprawdzenie zajmuje około 6 godzin. Działa w tle, podczas gdy śpię.

Uruchamiam również szybki test ścieżki krytycznej, który kończy się w 2 minuty: endpointy zdrowia, mapy witryn, strony przychodowe, huby firm S-tier, strony rynkowe, indeksy treści programowych, archiwa blogów i18n. Ten obserwuję osobiście. Jeśli cokolwiek zawiedzie, badam problem przed zaśnięciem.

Rutyna generuje raport, który wygląda tak:

NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT

Nikt mnie o to nie prosi. Żaden ticket tego nie wymaga. Żaden sprint nie zawiera „uruchom nightcheck”. Ta rutyna istnieje, ponieważ zależy mi na tym, czy strona działa, kiedy na nią nie patrzę.

Dlaczego co noc

Strona zmienia się każdego dnia. W ciągu jednego dnia mogę wdrożyć 87 commitów: tłumaczenia i18n, aktualizacje dostawców crawlingu, eksperymenty CRO, poprawki wydajności, korekty logotypów. Każdy commit jest testowany indywidualnie. Ale kompozycja 87 commitów może powodować awarie, których żaden pojedynczy commit nie ujawni.

Partia tłumaczeń może przepchnąć mapę witryny bloga poza próg renderowania. Nowy dostawca może wprowadzić stronę firmową, której renderowanie trwa 14 sekund. Zmiana nagłówka cache może sprawić, że Cloudflare przestanie buforować trasę, która wcześniej była szybka. Refaktoryzacja CSS może zepsuć szablon w jednym locale, ale nie w innych.

Nightcheck wyłapuje awarie kompozycji. Nie „czy ten commit coś zepsuł”, lecz „czy strona działa po tym, jak wszystko z dzisiejszego dnia wylądowało”. To rozróżnienie ma znaczenie, ponieważ awarie kompozycji są niewidoczne w CI. Każdy commit przechodzi własne testy. Zagregowane zachowanie 87 commitów przechodzących własne testy nie gwarantuje, że zagregowany system działa.

Co jest mierzone

Sprawdzenie ma cztery poziomy:

P0 Infrastruktura. Endpoint zdrowia zwraca status „healthy” z połączoną bazą danych. Mapy witryn zwracają poprawny XML. Robots.txt i llms.txt są obecne. Kanał RSS jest prawidłowy. To elementy, których awaria czyni witrynę niewidoczną dla wyszukiwarek.

P0 Przychód. Strona główna, kreator CV, analizator i strona cenowa — wszystkie się ładują. To strony, których awaria bezpośrednio kosztuje pieniądze. Kreator CV jest historycznie najwolniejszą stroną i ma próg WARN ustawiony na 5 sekund.

P1 Powierzchnia SEO. Archiwum bloga, strony filarowe hubów, katalog firm, przeglądanie ofert pracy, wszystkie pięć indeksów treści programowych (przewodniki po CV, przewodniki płacowe, przewodniki po listach motywacyjnych, pytania rekrutacyjne, słowa kluczowe ATS), cztery próbki blogów i18n oraz wszystkie 20 hubów firm S-tier. To strony napędzające ruch organiczny. Błąd 404 na stronie Google to incydent SEO.

P2 Kompleksowy. Każdy URL w mapach witryn bloga i firm. To 6-godzinne sprawdzenie w tle. Wyłapuje awarie długiego ogona: pojedynczy wpis na blogu zwracający błąd 500 z powodu nieprawidłowego cytowania, stronę firmową przekraczającą limit czasu z powodu zapytania N+1 dla dużej firmy.

Każda strona jest sprawdzana za pomocą curl z realistycznym nagłówkiem User-Agent. Goły curl otrzymuje błąd 403 od Cloudflare. Nagłówek statusu cache jest przechwytywany obok statusu HTTP i TTFB. Strona może zwrócić 200, ale wykazać DYNAMIC zamiast HIT, co oznacza błędną konfigurację reguły cache. Pomiar TTFB to rzeczywiste opóźnienie po stronie serwera, a nie czas renderowania w przeglądarce.

Trend TTFB

Uruchamiam to sprawdzenie od marca 2026. Trend TTFB opowiada historię wydajności:

Trend uchwycił podróż wydajności stron rynkowych: purge cache obnażył problem (14,3 s), buforowanie brzegowe go zamaskował (89-175 ms HIT), poprawka kształtu zapytania rozwiązała przyczynę źródłową (108 ms origin). Bez nocnego trendu uwierzyłbym, że edge cache był rozwiązaniem. Pomiary TTFB udowodniły, że renderowanie na serwerze origin było nadal wolne podczas rewalidacji, co uzasadniło refaktoryzację zapytania.

Nightcheck nie naprawił problemu wydajności. Sprawił, że problem wydajności stał się mierzalny, a więc możliwy do naprawienia.

Czego nikt nie widzi

Najcenniejszą cechą nightchecku jest to, że działa, gdy nikt nie patrzy. Nie ma powiadomienia na Slacku „16 228 stron przeszło w nocy”. Nie ma dashboardu, który zmienia kolor na zielony. Raport istnieje w pliku logów, który czytam przy porannej kawie.

Brak ceremonii jest sednem sprawy. Nightcheck to nie jakość na pokaz. To nie metryka na standup. To prywatna dyscyplina: czy wszystko działało, kiedy spałem? Jeśli tak — dobrze. Jeśli nie — wiem dokładnie, co zawiodło i kiedy.

Dyscyplina się kumuluje. Sprawdzenie każdej nocy ustanawia linię bazową do porównania następnego dnia. Wzrost TTFB o 50 ms na konkretnej stronie wyzwala dochodzenie — nie dlatego, że 50 ms ma znaczenie dla użytkowników, lecz dlatego, że wzrost wskazuje na zmianę. Być może nowa zależność dodała opóźnienie. Być może reguła cache wygasła. Być może zapytanie do bazy danych urosło wraz ze zbiorem danych. Nocna linia bazowa czyni dryfowanie widocznym, zanim stanie się problemem.

To kontekst złożony zastosowany do operacji. Sprawdzenie każdej nocy deponuje punkt danych. Punkty danych akumulują się w trend. Trend czyni widocznymi problemy, których żadne pojedyncze sprawdzenie nie ujawniłoby.

Rutyna jest standardem

Mógłbym zautomatyzować nightcheck jako zadanie cron i sprawdzać dashboard. Wybieram ręczne uruchamianie, ponieważ sam akt uruchamiania podtrzymuje nawyk dbałości. W momencie, gdy sprawdzenie staje się zadaniem kogoś innego, powiadomieniem do odrzucenia albo dashboardem, na który przestaję zaglądać — standard eroduje.

Standardem nie jest „strona przechodzi zautomatyzowane testy”. Standardem jest „osobiście zweryfikowałem, że strona działa, zanim poszedłem spać”. Różnicą jest odpowiedzialność. Zautomatyzowane sprawdzenie, które zawodzi po cichu, to błąd w automatyzacji. Ręczne sprawdzenie, które pomijam, to wybór, którego dokonałem w kwestii tego, na czym mi zależy.

Uruchamiam to każdej nocy, ponieważ alternatywą jest ufanie, że wszystko nadal działa. Zaufanie bez weryfikacji to nadzieja. Nadzieja nie jest strategią operacyjną.

FAQ

Jak długo trwa pełne sprawdzenie?

Szybki test ścieżki krytycznej zajmuje 2-3 minuty (36 stron z pomiarem TTFB i cache). Kompleksowe sprawdzenie mapy witryny trwa 5-7 godzin (ponad 15 000 stron). Szybki test działa synchronicznie; kompleksowe sprawdzenie działa w tle.

Dlaczego nie korzystać z usługi monitorowania dostępności?

Usługi monitorowania sprawdzają, czy strona zwraca 200. Nightcheck sprawdza, czy strona zwraca 200 z prawidłowym statusem cache, akceptowalnym TTFB i oczekiwaną strukturą treści. Strona zwracająca 200, ale ładująca się 14 sekund ze statusem DYNAMIC cache, jest technicznie dostępna, a operacyjnie zepsuta.

Co się dzieje, gdy coś zawiedzie?

Badam problem przed zaśnięciem, jeśli awaria dotyczy strony przychodowej lub infrastrukturalnej. W przypadku awarii wykrytych w kompleksowym sprawdzeniu przeglądam log następnego ranka i priorytetyzuję według typu strony. Uszkodzony wpis na blogu ma niższy priorytet niż uszkodzony hub firmowy. DYNAMIC cache na stronie o dużym ruchu ma wyższy priorytet niż wolny TTFB na stronie o niskim ruchu.

Czy to się skaluje?

15 000 stron to obecna skala. Kompleksowe sprawdzenie jest ograniczone przez I/O (sekwencyjne żądania curl), nie przez obliczenia. Podwojenie liczby stron podwaja czas wykonania. Przy 30 000 stron sprawdzenie trwałoby 12 godzin, co nadal mieści się w oknie nocnym. Powyżej tego progu konieczne byłoby równoległe sprawdzanie z ograniczaniem częstotliwości.