Mój system stanął o 1 w nocy. Dowiedziałem się rano, z opóźnienia w raporcie

1 lipca 2026 mój system przestał pracować w nocy i nie powiedział o tym ani słowa. Rano zorientowałem się nie po alercie, tylko po tym, że dzienny raport przyszedł spóźniony i był krótszy, niż powinien.

Piszę o tym, bo to jest najbardziej pouczająca rzecz, jaka mi się w tym projekcie przydarzyła — i dlatego, że mechanizm, który za tym stał, powtarza się wszędzie tam, gdzie coś stoi w kolejce.

Co się właściwie stało

Mam u siebie zestaw nocnych procesów, które przechodzą przez jedną kolejkę do lokalnego modelu językowego: analiza rynków, kontrola zgodności, monitoring bezpieczeństwa. Wszystkie wchodzą tą samą bramką, jeden po drugim.

Po serii nietypowo długich zapytań proces pośredniczący zawiesił się wewnętrznie. Kluczowe jest słowo „wewnętrznie”: on dalej działał. Nasłuchiwał na porcie, odpowiadał, że żyje, nie zostawił po sobie żadnego wpisu o błędzie. Po prostu przestał przetwarzać nowe żądania.

To jest najgorszy rodzaj awarii, jaki znam. Proces, który się wywala, zostawia ślad: log, restart, alert. Proces, który stoi i odpowiada „wszystko w porządku”, nie zostawia nic — i jedynym objawem jest to, że coś dalej w łańcuchu nie przyszło na czas.

Przyczyna

Dwie rzeczy naraz, i dopiero razem robią awarię:

Martwe, osierocone połączenie sieciowe. Druga strona zniknęła, ale gniazdo zostało otwarte. Z punktu widzenia procesu połączenie wciąż „trwa”, więc czeka na odpowiedź, która nigdy nie przyjdzie.
Brak jakiegokolwiek timeoutu na krytycznej ścieżce. To jest właściwa przyczyna. Punkt pierwszy jest zwykłą rzeczą, która w sieci zdarza się codziennie — dopiero brak limitu czasu zamienia ją w zatrzymanie całego systemu.

Kolejka przepuszczała jedno zadanie naraz. Wystarczyło, że pierwsze utknęło, i wszystko za nim stanęło.

Czego nie zrobiłem

Nie zrestartowałem procesu i nie dopisałem crona, który restartuje go co godzinę. To była pierwsza myśl i jest zła: restart usuwa objaw i sprawia, że przyczyna zostaje w kodzie na zawsze, tylko już nikt jej nie szuka, bo „przecież działa”.

Naprawa

Trzy zmiany, wszystkie w kodzie:

Zwolnienie kolejki na KAŻDEJ ścieżce. Wcześniej kolejka zwalniała się po udanym przetworzeniu. Teraz zwalnia się zawsze: przy sukcesie, przy błędzie i przy przekroczeniu czasu. To jest ta jedna zmiana, która likwiduje całą klasę problemu, a nie ten konkretny przypadek. Jeśli miałbym z tego wpisu zapamiętać jedno zdanie, byłoby to: sprzątanie musi wisieć na wyjściu z funkcji, nie na jej szczęśliwym zakończeniu.

Twarde limity czasu na każdym kroku. Każde wywołanie ma teraz górny czas. Zadanie, które go przekroczy, jest przerywane i odnotowane — zamiast czekać w nieskończoność.

Alert mailowy przy każdej samo-naprawie. Nie przy błędzie — przy naprawie. To jest ważne rozróżnienie: system, który po cichu leczy się sam, jest systemem, który po cichu ukrywa przed tobą, że coś jest nie tak. Chcę wiedzieć, ile razy się podniósł, bo rosnąca liczba to sygnał, że przyczyna wróciła w innym miejscu.

Co się stało w nocy z 2 na 3 lipca

Naprawa wypadła próbę praktyczną dzień później. Kolejka spiętrzyła się pod nietypowo dużym obciążeniem — trzy kolejne zadania czekały coraz dłużej (godziny w UTC):

2026-07-02 23:28 → czekało 51 min → kolejka zwolniona automatycznie
2026-07-02 23:48 → czekało 65 min → kolejka zwolniona automatycznie
2026-07-03 00:08 → czekało 78 min → kolejka zwolniona automatycznie

Nikt nie wstał. To są procesy nocne, więc godzina opóźnienia nie ma tu żadnego znaczenia — znaczenie ma to, że rano wszystko było zrobione, a w skrzynce leżały trzy wiadomości mówiące dokładnie, co się działo.

W ciągu siedemnastu dni obserwacji naliczyłem 33 takie zdarzenia. Gdyby nie ta zmiana, każde z nich byłoby cichym zatrzymaniem całego łańcucha aż do momentu, w którym ktoś zauważyłby brak raportu.

Co z tego wynika poza moim serwerem

Trzy rzeczy, które biorę ze sobą do każdego kolejnego systemu:

„Żyje” i „pracuje” to dwa różne pytania. Sprawdzanie, czy proces odpowiada, nie mówi nic o tym, czy cokolwiek robi. Odkąd to wiem, moje kontrole mierzą postęp, a nie obecność.

Cisza nie jest dobrą wiadomością. Jeżeli jedynym sygnałem, że system działa, jest brak alarmu, to nie masz monitoringu — masz nadzieję. Ten sam mechanizm złapał mi później kopię zapasową, która nie zmieniała się od 169 dni: nie dlatego, że coś krzyknęło, tylko dlatego, że codzienny raport podaje wiek kopii jako liczbę.

Naprawiaj klasę, nie przypadek. Można było dodać timeout w tym jednym miejscu, w którym się zacięło. Zamiast tego przeszedłem wszystkie ścieżki wyjścia z tej funkcji. To zajęło pół dnia więcej i od tamtej pory nie wróciło.

Liczby w tym wpisie pochodzą z danych monitoringu z okresu 1–17 lipca 2026 i są tymi samymi, które pokazuję na stronie głównej.