Trafna Pogoda
PolskaBlog
Kronika serwisu
Kronika serwisu

Kronika rozwoju Trafnej Pogody: droga do autonomii

W tydzień serwis Trafna Pogoda przeszedł drogę do pełnej autonomii. Zobacz, jak rozdzielenie ról serwerów dało odporność i świeżość danych.

Nowoczesna serwerownia z rzędami szaf rackowych w turkusowo-bursztynowym oświetleniu
Serwery pracujące bez udziału człowieka — ilustracja wygenerowana (Imagen)

Jak wygląda dobowy cykl pracy serwisu?

Każdego dnia system prognostyczny serwisu Trafna Pogoda wykonuje siedem biegów obliczeniowych. Bieg to proces, w którym na podstawie najnowszych danych z modeli numerycznych generowane są prognozy dla wszystkich 396 miast w Polsce. Kluczowy jest pierwszy bieg, który startuje o godzinie 4:30 czasu uniwersalnego (UTC). To właśnie jego wyniki są archiwizowane i służą do codziennej weryfikacji trafności, stanowiącej fundament naszej marki.

Kolejne biegi, uruchamiane w przybliżeniu co trzy godziny aż do późnego wieczora, pełnią rolę korygującą. Pozwalają na bieżąco uwzględniać najświeższe dane wejściowe i uaktualniać prognozę w ciągu dnia. Niezależnie od tego cyklu, system ostrzeżeń meteorologicznych IMGW jest odświeżany znacznie częściej, bo co 15 minut, aby zapewnić użytkownikom dostęp do najnowszych informacji o potencjalnych zagrożeniach.

Jakie zmiany poprzedziły kluczową transformację?

Droga do pełnej autonomii była procesem ewolucyjnym, a kluczowe zmiany zaszły w ciągu jednego tygodnia. 5 lipca 2026 roku skupiliśmy się na optymalizacji wydajności. Wprowadzenie równoległego przetwarzania pozwoliło skrócić czas generowania nagłówków opisowych dla wszystkich miast z około pięciu minut do zaledwie 32 sekund. Równie istotne było zredukowanie czasu blokowania głównego wątku przeglądarki z 1,5 sekundy do 0,4 sekundy, co bezpośrednio przełożyło się na płynność i responsywność interfejsu użytkownika.

Dzień później, 6 lipca, podjęliśmy dwie strategiczne decyzje. Po pierwsze, przeszliśmy na płatny klucz dostępowy do zewnętrznych danych pogodowych, eliminując ryzyko przerw w działaniu serwisu spowodowanych wyczerpaniem limitów darmowego planu. Po drugie, wprowadziliśmy żelazną zasadę: całość produkcji serwisu odbywa się na dedykowanym serwerze. Uniezależniło to działanie Trafnej Pogody od stabilności domowych komputerów i łączy internetowych.

7 lipca kontynuowaliśmy prace nad poprawą jakości serwisu. Skróciliśmy interwał automatycznego odświeżania treści na stronie z 30 do 15 minut, dzięki czemu prezentowane dane są jeszcze świeższe. Tego samego dnia wdrożyliśmy nową mapę ostrzeżeń IMGW, która zaczęła prezentować dane w układzie powiatowym, czyli dokładnie tak, jak są one wydawane przez państwową służbę meteorologiczną. To znacząco podniosło precyzję i użyteczność tej funkcji.

Na czym polegała największa zmiana w architekturze serwisu?

Kulminacja tygodniowej pracy nastąpiła 8 lipca 2026 roku. Tego dnia wdrożyliśmy fundamentalną zmianę w architekturze systemu, rozdzielając jego role na dwa niezależne komponenty: serwer generujący oraz serwer frontowy. Taka architektura jest standardem w dojrzałych systemach informatycznych, ponieważ zapewnia większą stabilność, bezpieczeństwo i skalowalność.

Serwer generujący od tej pory odpowiada wyłącznie za ciężkie obliczenia: pobieranie danych z modeli, ich przetwarzanie, tworzenie prognozy zespołowej i generowanie finalnych plików z danymi. Serwer frontowy, czyli ten, z którym łączą się przeglądarki naszych czytelników, zajmuje się jedynie serwowaniem strony. Co 20 minut samodzielnie pobiera on po protokole HTTP świeżo przygotowane dane z serwera generującego. Dzięki temu ewentualne problemy z jednym komponentem nie wpływają na drugi – duży ruch na stronie nie spowalnia obliczeń, a intensywne obliczenia nie spowalniają strony.

Architektura serwisu po zmianach z 8 lipca 2026Serwer generujący7 biegów dzienniepełny bieg: 4:30 UTCSerwer frontowypobiera dane co 20 minserwuje stronę WWWCzytelnikświeża prognozabez czekania na rebuildpublikacja danychstrona WWW
Uproszczony schemat architektury serwisu Trafna Pogoda po zmianach z 8 lipca 2026 r.

Efektem tej zmiany jest pełna autonomia. Jak zapisano w naszym dzienniku technicznym: „komputery domowe mogą być wyłączone tygodniami, a serwis aktualizuje się sam”. Aby móc nadzorować tak działający system, tego samego dnia uruchomiliśmy wewnętrzny panel operacyjny, zwany kokpitem, który pozwala na bieżąco monitorować stan wszystkich komponentów usługi.

Co było ostatnim krokiem w tym etapie rozwoju?

Prace nad nową architekturą zakończyliśmy 9 lipca, wdrażając standardowe logowanie aplikacyjne do wspomnianego kokpitu. Był to niezbędny krok w celu zabezpieczenia dostępu do narzędzi monitorujących i operacyjnych serwisu. W ten sposób cały system stał się nie tylko autonomiczny, ale również odpowiednio zabezpieczony.

Tydzień od 5 do 9 lipca był okresem intensywnych, ale przemyślanych zmian, które przeniosły serwis w nowy etap dojrzałości technologicznej. Każda decyzja była podyktowana dążeniem do zwiększenia niezawodności, wydajności i odporności na awarie. Zachęcamy do zapoznania się z metodologią naszych prognoz oraz do śledzenia kolejnych wpisów na naszym blogu.