Jest 3:17 w nocy. Twój telefon wibruje. Alert z monitoringu: Response time exceeded 30s. Wstajesz, otwierasz laptopa i zaczynasz debug sesję, która zmieni Twoje podejście do programowania na zawsze. Brzmi znajomo? Jeśli jesteś developerem z choćby kilkuletnim stażem, prawdopodobnie przeżyłeś coś podobnego.

Tajemnicze życie cron jobów

Większość nocnych koszmarów programistycznych ma wspólnego winowajcę: zadania zaplanowane na godziny, kiedy nikt nie patrzy. Raporty generowane o północy. Synchronizacje baz danych o 2 w nocy. Backup o 4 rano. Każde z tych zadań wydaje się niewinne, dopóki nie zaczną się nawzajem blokować.

Klasyczny scenariusz: job A startuje o 2:00 i powinien skończyć się o 2:15. Job B startuje o 2:30 i potrzebuje danych z joba A. Wszystko działa, dopóki pewnego dnia job A nie napotka większego zestawu danych i kończy się o 2:45. Job B już dawno wystartował z niekompletnymi danymi. Chaos gotowy.

Strefy czasowe: cichy zabójca

U mnie działa - to zdanie, które nabiera nowego znaczenia, gdy Twój serwer stoi w Irlandii, baza danych zapisuje timestampy w UTC, a użytkownicy są w Polsce. Dodaj do tego zmianę czasu letniego i masz przepis na błędy, które pojawiają się dosłownie dwa razy w roku.

Prawdziwa historia: system rezerwacji, który przez lata działał bez zarzutu, nagle zaczął podwójnie księgować rezerwacje. Tylko w październiku. Tylko w niedzielę. Okazało się, że logika sprawdzała czy minęła godzina od ostatniej rezerwacji bez uwzględnienia faktu, że godzina 2:30 wystąpiła tej nocy dwukrotnie.

Gdy pamięć ma swoje zdanie

W ciągu dnia Twoja aplikacja obsługuje setki requestów na minutę. Garbage collector regularnie sprząta, pamięć jest w ryzach. Ale w nocy ruch spada do zera, GC idzie spać, a Twój nocny job próbuje załadować do pamięci raport z milionem wierszy. Efekt? OutOfMemoryError o 3:47, gdy jedyną osobą, która mogłaby zareagować, jesteś Ty - śpiący.

Rozwiązanie jest prozaiczne: przetwarzanie strumieniowe, batch processing, limity pamięci. Ale żeby do niego dojść, trzeba najpierw przeżyć tę jedną noc, która wszystko zmienia.

Lekcje o 3 w nocy

Po kilku takich nocach uczysz się rzeczy, których nie ma w żadnym tutorialu. Że monitoring to nie koszt, tylko inwestycja. Że każdy cron job powinien mieć timeout i alerting. Że działa na produkcji to stan tymczasowy. Że najlepszy kod to ten, który nie budzi Cię w nocy.

I uczysz się jeszcze jednej rzeczy: że te nocne sesje debugowania, choć męczące, budują intuicję, której nie da się zdobyć inaczej. Bo prawdziwe programowanie zaczyna się tam, gdzie kończą się tutoriale - o 3 w nocy, z kawą w jednej ręce i stacktrace'em w drugiej.