Zły czas serwera: awaria MetaQuotes-Demo 27 października

W skrócie: 27 października 2026 serwer MetaQuotes-Demo przez około pół godziny nie działał, a po powrocie nadawał śmieciowe tiki: czasy z 1970 roku, ceny typu 17931 dla pary AUDNZD, a w terminalach zegar serwera przeskoczył w przyszłość (rok 2573 albo 2803). Bot, który ufa temu zegarowi, nie zamyka pozycji o czasie i nie wchodzi w sesji. U mnie skutki ujawniły się dopiero po tygodniu.

Co się stało tego wieczoru

Serwer był niedostępny od około 18:10 do 18:37 czasu mojego komputera, a wrócił jako nowszy build. Na trzech terminalach z kontami demo zegar zwracany przez TimeCurrent() skoczył w przyszłość. Objawy były trzy:

boty nie handlowały, bo ich okna sesji zostały wyliczone dla roku 2803, więc “teraz” nigdy nie wpadało w godziny wejść,
moduł podtrzymujący konto otworzył osiem fałszywych pozycji,
panel monitorujący przestał działać, bo dostał datę spoza zakresu.

Restart terminali około 22:12 przywrócił poprawny czas. W logach terminali pojawiły się za to ogromne pliki (od 64 do 583 MB), więc je przeniosłem do osobnego katalogu zamiast kasować, żeby mieć co analizować. Tego samego wieczoru aktualizowałem flotę do nowszego buildu, więc awarię serwera trzeba było odróżnić od skutków aktualizacji.

Drugie dno: skutek, który został po naprawie

To jest ta część, którą cenię najbardziej, bo jest nieoczywista. Tydzień później, przy porównaniu wyniku z konta z wynikiem z testu, zauważyłem, że jeden z botów od 27 października nie zamyka pozycji o ustalonej godzinie. W Testerze zamykał, na koncie nie.

Przyczyna siedziała w kodzie, który pilnuje godziny zamknięcia. Zapisywał on “termin zamknięcia” w zmiennej globalnej terminala. Podczas awarii pętla przesuwająca termin o dzień doszła do fałszywej daty (rok 2573 lub 2803) i ją zapisała. Po restarcie zegar wrócił do normy, ale zapisany termin został. Warunek “czy już czas zamknąć” porównywał bieżący czas z rokiem 2803, więc nigdy nie był spełniony. Zmienna globalna przeżywa restart terminala, a razem z nią przeżył błąd.

Odczytałem te zmienne ze specjalnego pliku terminala skryptem i znalazłem fałszywe terminy na dwóch terminalach demo: 2573-08-30 dla czterech botów i 2803-08-15 dla czterech botów (jedna data na terminal oznacza jedno zdarzenie). Terminale innych brokerów miały terminy poprawne. Na koncie prop nie wydarzyło się nic, bo tam serwer działał normalnie.

Co zmieniłem

Test sensowności zegara. Gdy czas serwera różni się od czasu GMT o więcej niż 26 godzin, uznaję go za zły. Wtedy kod niczego nie przesuwa ani nie zapisuje, a odczytany termin ignoruje.
Ten sam test w narzędziu podtrzymującym i w monitorze. Przy zepsutym zegarze moduł nie otwiera pozycji.
Skaner zmiennych globalnych. Po takiej awarii przeglądam zapisane terminy pod kątem dat w przyszłości.
Kontrola po restarcie. Zdrowy zegar po restarcie nie dowodzi, że stan zapisany w trakcie awarii jest zdrowy.

Czego się z tego nauczyłem

Każdą wartość zapisywaną na dłużej niż jeden dzień należy zapisywać dopiero po sprawdzeniu, że czas, od którego ją liczę, jest wiarygodny. Zegar serwera brokera nie jest świętością. Inne serwery w tym samym czasie działały normalnie, więc awaria dotyczyła tylko konta demo MetaQuotes.

Checklista

Bot porównuje czas serwera z czasem GMT i odrzuca przeskok większy niż doba.
Nic, co przeżywa restart (zmienne globalne, pliki), nie jest zapisywane przy podejrzanym zegarze.
Po awarii serwera sprawdzam zapisane terminy i liczniki, nie tylko to, czy bot wystartował.
Logi z awarii przenoszę do osobnego miejsca, nie kasuję.
Wpisuję zdarzenie do rejestru błędnych danych: serwer, data, godzina, skutek.

Powiązane

Ostrzeżenie: handel CFD i forex wiąże się z wysokim ryzykiem utraty kapitału. Awarie serwerów brokerów zdarzają się także na kontach prawdziwych. Artykuł ma charakter edukacyjny i nie jest rekomendacją inwestycyjną.