VPS dla botów tradingowych: co naprawdę ma znaczenie

Czego bot handlowy potrzebuje od VPS

VPS dla botów handlowych ocenia się według czterech kryteriów: czy proces uruchamia się ponownie po awarii, czy zegar systemowy wskazuje prawidłowy czas, czy klucze API (interfejsu programistycznego aplikacji) są odpowiednio chronione przed kradzieżą oraz czy można wykryć zatrzymanie procesu. Surowa wydajność znajduje się znacznie niżej na tej liście w przypadku bota detalicznego, ponieważ za opóźnienie na ścieżce realizacji zlecenia odpowiada przede wszystkim broker i odległość od niego, a nie host uruchamiający kod Python.

Jest to przewodnik dotyczący aspektów technicznych. Żadne zawarte tu informacje nie stanowią porady finansowej. Nie omówiono żadnej strategii.

Wysoka dostępność to dyscyplina restartów, a nie liczba na stronie sprzedażowej

Każdy host na świecie deklaruje dostępność na poziomie 99.9 procent. Ta wartość opisuje hypervisor, a nie bota. Bot kończy działanie z powodu nieobsłużonego wyjątku, połączenia websocket, które nigdy nie zostaje ponownie nawiązane, albo działania OOM (out of memory) killer. Serwer może przez cały czas działać prawidłowo. Dlatego istotne pytanie brzmi: co dzieje się w ciągu dziesięciu sekund po zakończeniu procesu.

Należy uruchomić bota jako usługę systemd i przekazać systemowi init obsługę restartów. Plik jednostki realizuje to w sześciu wierszach.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 to wiersz, który jest często pomijany. Domyślnie systemd rezygnuje po 5 restartach w ciągu 10 sekund i pozostawia jednostkę na stałe w stanie failed. Jest to dokładnie zachowanie, którego nie należy oczekiwać o 03:00. Ustawienie wartości 0 wyłącza ograniczenie częstotliwości, więc bot, który wpada w pętlę awarii i restartów, nadal podejmuje próby zamiast przejść w stan bezczynności. RestartSec=10 zapobiega przeciążaniu giełdy kolejnymi próbami ponownego nawiązania połączenia.

Przed uruchomieniem usługi należy sprawdzić plik:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable to część konfiguracji, która zapewnia działanie po ponownym uruchomieniu systemu. Aktualizacje jądra oznaczają konieczność ponownego uruchomienia systemu. Aby sprawdzić, czy bot po cichu kończył działanie, należy zażądać od systemd licznika restartów:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 po tygodniu oznacza prawidłowo działającego bota. NRestarts=812 oznacza, że transakcje były wykonywane przez proces, który przez całą noc ponownie nawiązywał połączenie. Pełną strukturę pliku jednostki, w tym timery dla zadań zaplanowanych, takich jak codzienny raport, opisano w sekcji uruchamianie programu jako usługi systemd.

Ustaw zegar na UTC i potwierdź synchronizację

Interfejsy API giełd podpisują żądania sygnaturą zawierającą znacznik czasu i odrzucają wszystko poza określonym oknem, często wynoszącym 5 sekund lub mniej. Zegar, który się rozregulowuje, powoduje błędy wyglądające jak problemy z uwierzytelnianiem. W rezultacie klucze są rotowane przez wiele godzin, zanim zostanie sprawdzony czas. W interfejsach API podobnych do Binance komunikat jest jednoznaczny: Timestamp for this request was 1000ms ahead of the server's time.

Ustaw serwer w strefie UTC. Lokalne strefy czasowe wprowadzają skok związany z czasem letnim, który może wystąpić w środku sesji handlowej.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu zawiera systemd-timesyncd, czyli klienta SNTP (simple network time protocol). Nadaje się on do dzienników, ale jest niewystarczający w przypadku zastosowań wymagających utrzymania dokładności rzędu kilku milisekund, ponieważ odpytuje jeden serwer i nie koryguje zegara w sposób ciągły. Zamiast niego użyj chrony:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Wartość odczytywana z chronyc tracking to System time, na przykład System time : 0.000031415 seconds fast of NTP time. Wartość poniżej kilku milisekund oznacza prawidłowy stan. Jeśli wyświetlana jest wartość Leap status : Not synchronised, chrony nie połączył się jeszcze z serwerem, zwykle dlatego, że wychodzący ruch UDP 123 jest blokowany. Odczekaj minutę, a następnie sprawdź ponownie przed modyfikacją reguł zapory sieciowej.

Klucze API należy przechowywać poza kopiowanymi lokalizacjami

Ujawniony klucz giełdy jest bardziej niebezpieczny niż ujawniony klucz SSH, ponieważ uprawnienie do wypłat pozwala natychmiast uzyskać dostęp do środków. Większość ryzyka ograniczają dwie zasady.

Po pierwsze, nie należy nadawać kluczowi bota uprawnień do wypłat. Jeśli giełda to obsługuje, należy powiązać klucz z adresem IP serwera. Jest to pojedynczy mechanizm kontrolny, który sprawia, że skradziony klucz staje się prawie bezużyteczny.

Po drugie, sekretu nie należy przechowywać w katalogu z kodem. Wszystko, co znajduje się w /opt/tradingbot, wcześniej czy później trafi do repozytorium git albo archiwum kopii zapasowej. Należy umieścić sekret w pliku należącym do root, odczytywanym wyłącznie przez systemd:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

Plik zawiera zwykłe wiersze KEY=value bez cudzysłowów i bez export. Tryb 640 oraz grupa bot oznaczają, że użytkownik usługi może odczytać plik, a nikt inny nie ma do niego dostępu. Należy sprawdzić to za pomocą sudo -u bot cat /etc/tradingbot/api.env, a następnie przy użyciu dowolnego innego użytkownika, dla którego operacja musi zakończyć się niepowodzeniem z użyciem Permission denied.

Bot nie powinien działać jako root ani jako użytkownik, za pomocą którego wykonywane jest logowanie. Należy utworzyć konto systemowe bez powłoki i bez katalogu domowego, do którego można się zalogować:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

Wyjaśnienie każdego z tych przełączników oraz zakres działania ProtectSystem=strict opisano w artykule uruchamianie usług jako użytkownik nieuprzywilejowany. Pozostałe elementy konfiguracji bazowej serwera, czyli klucze SSH i zapora sieciowa, opisano w artykule pierwsze dziesięć minut na nowym VPS.

Dowiedz się o awarii, zanim zrobi to broker

systemctl status informuje, że proces działa. Nie oznacza to, że bot wykonuje jakiekolwiek operacje. Proces zablokowany w pętli ponawiania połączenia z niedziałającym websocketem przechodzi wszystkie kontrole, które może wykonać systemd.

Należy użyć sygnału heartbeat. Uptime Kuma obsługuje monitory push: oczekuje, że bot będzie wywoływać adres URL zgodnie z harmonogramem, i wysyła alert, gdy wywołania przestaną docierać. Wywołanie należy umieścić na końcu głównej pętli, za częścią potwierdzającą działanie bota, na przykład za pomyślnym odczytem danych rynkowych.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Interwał monitora należy ustawić na około dwukrotność czasu wykonania pętli, aby typowe wahania czasu wykonania nie powodowały alertów. Monitor należy uruchomić na innym serwerze niż bot, ponieważ monitor, który zakończy działanie razem z monitorowanym procesem, niczego nie zgłosi. Konfigurację opisano w samodzielnie hostowane monitorowanie stanu za pomocą Uptime Kuma.

Należy również dodać alert dotyczący dysku. Bot zapisujący szczegółowe logi zapełni główny system plików w ciągu kilku tygodni, a pełny dysk uniemożliwi zapis do bazy danych, ale nie wywołanie sieciowe, dlatego objawy będą nietypowe. journalctl --vacuum-time=14d i wiersz SystemMaxUse= w /etc/systemd/journald.conf ograniczają rozmiar dziennika systemowego.

Uczciwie: opóźnienie w większości nie zależy od serwera

W tym miejscu rynek produktów trading VPS przestaje być techniczny. Strony marketingowe podają wartości poniżej milisekundy i sugerują, że serwer jest tym, co dzieli użytkownika od realizacji zlecenia. W przypadku niemal każdego bota detalicznego tak nie jest.

Zlecenie jest przesyłane z bota do punktu końcowego giełdy lub brokera przez publiczny Internet. Na tę trasę wpływają przede wszystkim odległość fizyczna oraz peering między dostawcą użytkownika a dostawcą giełdy lub brokera. Serwer we Frankfurcie komunikujący się z punktem końcowym w Tokio uzyskuje czas obiegu wynoszący około 250 milisekund, niezależnie od szybkości procesora. Następnie własne systemy brokera dodają czas oczekiwania w kolejce, kontrole ryzyka i limity szybkości. W przypadku rachunku detalicznego wartości te zwykle wynoszą dziesiątki lub setki milisekund.

Należy wykonać pomiar zamiast zgadywać. curl raportuje czas nawiązania połączenia i otrzymania pierwszego bajtu dla rzeczywistego punktu końcowego:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Należy uruchomić to polecenie na serwerze kandydującym przed podjęciem decyzji. Jeśli connect wynosi 0.180 sekundy, serwer znajduje się na niewłaściwym kontynencie i warto to poprawić. Jeśli connect wynosi 0.004 sekundy, a ttfb wynosi 0.140 sekundy, pozostałe opóźnienie wynika z przetwarzania po stronie brokera i zmiana serwera go nie zmniejszy.

Kiedy serwer ma więc znaczenie? Gdy użytkownik korzysta z kolokacji lub bezpośredniego połączenia z platformą i konkuruje o pozycję w kolejce. Jest to inny rodzaj działalności, wymagający innego budżetu. Serwer ma znaczenie również wtedy, gdy wąskim gardłem jest własny kod. Bot, który przy każdym ticku ponownie oblicza wskaźniki na podstawie pełnej historii, może zużywać 200 milisekund czasu CPU na jedną iterację. Jest to rzeczywiste opóźnienie, nad którym można bezpłatnie przejąć kontrolę. Przed wyborem szybszego serwera należy profilować pętlę.

Wybierając serwer, należy zwrócić uwagę na lokalizację geograficzną, stabilną sieć oraz ilość pamięci wystarczającą do tego, aby zabójca OOM nigdy nie musiał przerywać procesu. Według stanu na lipiec 2026 pojedynczy bot Python obsługujący jedną strategię i kilkaset symboli przechowywanych w pamięci działa bez problemu przy 2 GB RAM i 2 vCPU. Pamięć należy zwiększyć, jeśli historia ticków jest przechowywana w lokalnej bazie danych.

Krótka lista kontrolna przed uruchomieniem produkcyjnym

1. systemctl is-enabled tradingbot wyświetla enabled, a usługa działa nadal po sudo reboot.
2. chronyc tracking zgłasza przesunięcie czasu systemowego mniejsze niż kilka milisekund.
3. Klucz API ma uprawnienie do handlu, nie ma uprawnienia do wypłat, a także ma listę dozwolonych adresów IP, jeśli giełda ją udostępnia.
4. Zakończenie procesu za pomocą sudo systemctl kill -s SIGKILL tradingbot powoduje jego ponowne uruchomienie w ciągu RestartSec.
5. Monitor sygnału heartbeat wysyła powiadomienie w ciągu jednego interwału po celowym zatrzymaniu bota.
6. Rozmiar logów jest ograniczony, a główny system plików ma wolne miejsce w df -h.

Przez tydzień należy uruchamiać całość w środowisku sandbox giełdy lub w trybie paper trading, zanim zostaną użyte rzeczywiste środki. W tym tygodniu każdy z powyższych punktów zawiedzie co najmniej raz. Na tym polega cel tego tygodnia.

FAQ

Czy bot handlowy wymaga serwera o niskich opóźnieniach lub serwera bare metal?

Tylko wtedy, gdy szybkość realizacji zleceń jest przedmiotem rywalizacji z innymi automatycznymi uczestnikami na tej samej platformie. Zwykle oznacza to kolokację, a nie ogólny VPS. W przypadku bota detalicznego czas pełnego cyklu zależy głównie od odległości geograficznej i przetwarzania po stronie brokera. Należy więc wybrać serwer znajdujący się blisko punktu końcowego API i wykonać pomiary za pomocą curl oraz mtr przed opłaceniem szybszej infrastruktury.

Ile pamięci RAM i mocy CPU wymaga bot handlowy?

Większość botów obsługujących pojedynczą strategię jest ograniczona przepustowością sieci i pozostaje bezczynna między zdarzeniami. W lipcu 2026 2 vCPU i 2 GB pamięci RAM wystarczają do obsługi bota w Pythonie monitorującego kilkaset instrumentów. Pamięć staje się ograniczeniem, gdy historia kwotowań jest przechowywana w procesie lub działa lokalna baza danych. Należy więc monitorować free -h i dziennik systemowy pod kątem komunikatów OOM kill, zamiast zgadywać.

Dlaczego API giełdy odrzuca żądania z powodu błędu znacznika czasu?

Zegar serwera rozregulował się poza oknem podpisywania używanym przez giełdę, zwykle o kilka sekund. Należy zainstalować chrony, sprawdzić, czy chronyc tracking pokazuje niewielkie przesunięcie System time oraz zsynchronizowany status przestępny, a także ustawić UTC jako strefę czasową maszyny, aby zmiana czasu letniego nigdy nie przesunęła zegara. Rotacja klucza API nie rozwiązuje problemu z zegarem.

Jak zatrzymać bota przed nieoczekiwanym zakończeniem pracy w nocy?

Należy uruchomić go za pomocą systemd z użyciem Restart=always i StartLimitIntervalSec=0, aby po awarii był ponownie uruchamiany zamiast trwale się zatrzymać. Następnie należy dodać mechanizm heartbeat wysyłany przez bota po zakończeniu każdej pomyślnie wykonanej pętli. Restart obsługuje przypadek zakończenia procesu. Heartbeat wykrywa przypadek, w którym proces działa, ale został zablokowany.

Czy można uruchomić bota i monitoring na tym samym VPS?

Jest to możliwe, ale w dniu awarii monitoring przekaże nieprawdziwy obraz sytuacji, ponieważ awaria, która wyłączy bota, wyłączy również monitoring. Mechanizm alertów należy utrzymywać na oddzielnej maszynie, najlepiej u innego dostawcy lub w innym regionie. Serwer bota powinien służyć wyłącznie do uruchamiania bota i przechowywania jego dzienników.