מה באמת חשוב בבחירת VPS לבוט מסחר

מה בוט מסחר צריך מ־VPS

VPS עבור בוטים למסחר נבחן לפי ארבעה מדדים: האם התהליך חוזר לפעול לאחר שהוא מפסיק, האם השעון מכוון כראוי, האם קשה לגנוב את מפתחות ה־API (ממשק תכנות היישומים), והאם מתקבלת התראה כאשר הוא מפסיק לפעול. מהירות גולמית נמצאת בעדיפות נמוכה בהרבה עבור בוט קמעונאי, משום שהחלק האיטי בנתיב הפקודה שלך הוא הברוקר והמרחק אליו, ולא המארח שמריץ את Python.

זהו מדריך הנדסי. אין באמור כאן ייעוץ פיננסי, ולא נידונה כאן שום אסטרטגיה.

זמן פעילות הוא משמעת אתחול, לא מספר בדף מכירות

כל שרת בעולם מציג זמן פעילות של 99.9 אחוזים. נתון זה מתאר את ה-hypervisor, ולא את הבוט שלכם. בוט מפסיק לפעול בגלל חריגה שאינה מטופלת, websocket שאינו מתחבר מחדש, או ה-OOM (out of memory) killer, בעוד שהשרת ממשיך לפעול כל הזמן. לכן השאלה החשובה היא מה קורה בעשר השניות שלאחר יציאת התהליך.

הריצו את הבוט כשירות systemd, ואפשרו למערכת האתחול לנהל את האתחול מחדש. קובץ יחידה עושה זאת בשש שורות.

[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 היא השורה שאנשים נוטים לפספס. כברירת מחדל, systemd מפסיקה לנסות לאחר 5 אתחולים מחדש בתוך 10 שניות ומשאירה את היחידה במצב failed לצמיתות. זה בדיוק המצב שאינכם רוצים בשעה 03:00. הגדרת הערך ל-0 משביתה את הגבלת הקצב, ולכן בוט שנכנס ללולאת קריסות ממשיך לנסות במקום להשתתק. RestartSec=10 מונעת מהלולאה להציף את הבורסה בניסיונות התחברות מחדש.

בדקו את הקובץ לפני שאתם מסתמכים עליו, ולאחר מכן הפעילו את השירות:

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

enable הוא החלק ששורד אתחול מחדש, ועדכוני ליבה מחייבים אתחול מחדש. כדי לבדוק אם הבוט מפסיק לפעול בשקט, בקשו מ-systemd את מונה האתחולים מחדש:

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

NRestarts=0 לאחר שבוע מצביע על בוט תקין. NRestarts=812 פירושו שסחרתם באמצעות תהליך שמתחבר מחדש במשך כל הלילה. המבנה המלא של קובץ היחידה, כולל timers עבור משימות מתוזמנות כמו דוח יומי, מוסבר בהפעלת תוכנית כשירות systemd.

הגדרת השעון ל-UTC והוכחה שהוא מסונכרן

ממשקי API של בורסות חותמים על בקשות באמצעות חותמת זמן ודוחים כל בקשה שחורגת מחלון זמן, שלעתים קרובות הוא 5 שניות או פחות. שעון שסוטה גורם לשגיאות שנראות כמו כשלי אימות, ולכן משתמשים מחליפים מפתחות במשך שעות לפני שהם בודקים את השעה. בממשקי API בסגנון Binance, ההודעה מפורשת: Timestamp for this request was 1000ms ahead of the server's time.

הגדירו את השרת ל-UTC. אזורי זמן מקומיים יוצרים קפיצה עקב שעון קיץ, שתתרחש באמצע סשן מסחר.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu מגיעה עם systemd-timesyncd, שהוא לקוח SNTP (פרוטוקול זמן רשת פשוט). הוא מתאים ליומנים ואינו מתאים למשימות שצריכות להישאר בטווח של מילישניות ספורות, משום שהוא מבצע שאילתות מול שרת אחד ואינו מווסת את השעון באופן רציף. השתמשו במקום זאת ב-chrony:

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

השורה שיש לקרוא מ-chronyc tracking היא System time, לדוגמה System time : 0.000031415 seconds fast of NTP time. ערך הנמוך ממילישניות ספורות נחשב תקין. אם מתקבל Leap status : Not synchronised, ‏chrony עדיין לא התחבר לשרת, בדרך כלל משום ש-UDP 123 יוצא נחסם. המתינו דקה ובדקו שוב לפני שתשנו את כללי חומת האש.

שמרו מפתחות API מחוץ למקומות שאתם מעתיקים

מפתח של בורסת מטבעות קריפטוגרפיים שדלף מסוכן יותר ממפתח SSH שדלף, משום שהרשאת משיכה הופכת אותו מיד לכסף. שני הרגלים מכסים את רוב הסיכון.

ראשית, לעולם אל תעניקו הרשאת משיכה למפתח של בוט. כאשר הבורסה תומכת בכך, הגבילו את המפתח לכתובת ה-IP של השרת שלכם. זהו אמצעי הבקרה היחיד שהופך מפתח שנגנב לכמעט חסר תועלת.

שנית, שמרו את הסוד מחוץ לספריית הקוד. כל דבר שנמצא בתוך /opt/tradingbot מגיע במוקדם או במאוחר למאגר git או לארכיון גיבוי. שמרו אותו בקובץ בבעלות root, שרק 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

הקובץ מכיל שורות KEY=value פשוטות, ללא מרכאות וללא export. הרשאות 640 עם הקבוצה bot מאפשרות למשתמש השירות לקרוא את הקובץ, ואינן מאפשרות לאף משתמש אחר לעשות זאת. אמתו זאת באמצעות sudo -u bot cat /etc/tradingbot/api.env ולאחר מכן באמצעות משתמש אחר כלשהו; הפעולה חייבת להיכשל עם Permission denied.

הבוט עצמו לא צריך לפעול כ-root או כמשתמש ההתחברות שלכם. צרו חשבון מערכת ללא מעטפת וללא ספריית בית שאליה ניתן להתחבר:

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

ההסבר לכל אחד מהדגלים האלה, וכן למידה שבה ProtectSystem=strict אכן מספק הגנה, נמצא במאמר הפעלת שירותים כמשתמש ללא הרשאות. יתרת תצורת הבסיס של השרת, מפתחות SSH וחומת אש, צריכה להיכלל במדריך עשר הדקות הראשונות ב-VPS חדש.

גלה שהשירות מושבת לפני שהברוקר שלך מגלה זאת

systemctl status מציין שהתהליך פועל. הוא אינו מציין שהבוט מבצע פעולה כלשהי. תהליך שנתקע בלולאת ניסיונות חוזרים מול websocket שאינו פעיל יעבור כל בדיקה ש-systemctl status יכול לבצע.

השתמש ב-heartbeat במקום זאת. ל-Uptime Kuma יש צגי push: הוא מצפה שהבוט שלך יקרא לכתובת URL לפי לוח זמנים, ושולח התראה כאשר הקריאות מפסיקות להגיע. הוסף את הקריאה בסוף הלולאה הראשית, אחרי החלק שמוכיח שהבוט פעיל, כגון קריאה מוצלחת של נתוני שוק.

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

הגדר את מרווח הצג לערך השווה בקירוב לפי 2 מזמן הלולאה, כדי שתנודות רגילות לא יפעילו התראה. הפעל את הצג בשרת שונה מזה שבו פועל הבוט, משום שצג שנעצר יחד עם הרכיב שעליו הוא מפקח לא ידווח על דבר. ההגדרה מתוארת בניטור סטטוס עצמאי באמצעות Uptime Kuma.

הוסף גם התראה על שטח הדיסק. בוט שכותב יומנים מפורטים ימלא את מערכת הקבצים של root בתוך שבועות, ודיסק מלא מונע כתיבה למסד הנתונים, אך לא את הקריאה לרשת, ולכן התסמינים אינם צפויים. journalctl --vacuum-time=14d ושורת SystemMaxUse= בתוך /etc/systemd/journald.conf שומרים על גודל היומן בגבולות מוגדרים.

החלק הכנה: זמן האחזור תלוי בעיקר בגורמים שאינם השרת שלך

כאן השוק של מוצרי VPS למסחר מפסיק להיות טכני. בדפי שיווק מציינים ערכים של פחות מאלפית שנייה, ומשתמע מהם שהשרת הוא הגורם המפריד בינך לבין ביצוע העסקה. עבור כמעט כל בוט קמעונאי, זה אינו המצב.

הפקודה שלך עוברת מהבוט אל נקודת הקצה של הבורסה או של הברוקר דרך האינטרנט הציבורי. המרחק הפיזי והקישוריות בין ספק האינטרנט שלך לספק שלהם הם הגורמים העיקריים במסלול הזה. שרת בפרנקפורט שמתקשר עם נקודת קצה בטוקיו ישלם בערך 250 אלפיות השנייה הלוך ושוב, בלי קשר למהירות המעבד. לאחר מכן המערכות של הברוקר מוסיפות את זמן ההמתנה בתור, את בדיקות הסיכון ואת מגבלות הקצב שלהן. בחשבון קמעונאי, זמנים אלה נמדדים בדרך כלל בעשרות או במאות אלפיות השנייה.

מדדו במקום לנחש. curl מדווחת על זמני יצירת החיבור וקבלת הבייט הראשון מנקודת קצה אמיתית:

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

הריצו אותה משרת מועמד לפני שאתם מתחייבים אליו. אם connect הוא 0.180 שניות, אתם נמצאים ביבשת הלא נכונה, וכדאי לתקן זאת. אם connect הוא 0.004 שניות ו-ttfb הוא 0.140 שניות, העיכוב הנותר נגרם מעיבוד אצל הברוקר, ושינוי השרת לא ישפיע עליו.

אז מתי השרת חשוב? כאשר אתם נמצאים באותו אתר אירוח משותף עם זירת המסחר, או מחוברים אליה בחיבור ישיר, ומתחרים על המיקום בתור. זהו עסק אחר, עם תקציב אחר. השרת חשוב גם כאשר הקוד שלכם הוא צוואר הבקבוק: בוט שמחשב מחדש אינדיקטורים על פני היסטוריה מלאה בכל tick עלול לצרוך 200 אלפיות השנייה של זמן CPU בכל לולאה. זהו זמן אחזור ממשי שנמצא בשליטתכם ואפשר לצמצם אותו ללא עלות. בצעו פרופיילינג ללולאה לפני שאתם מחפשים שרת מהיר יותר.

הגורמים החשובים בבחירת השרת הם המיקום הגאוגרפי, יציבות הרשת וכמות זיכרון מספקת, כך של- OOM killer לא תהיה הזדמנות להשפיע. נכון ליולי 2026, בוט Python יחיד לאסטרטגיה אחת, עם כמה מאות סמלים בזיכרון, פועל בנוחות עם 2 GB של RAM ו-2 vCPU. הוסיפו זיכרון אם אתם שומרים היסטוריית tick במסד נתונים מקומי.

רשימת בדיקה קצרה לפני הפעלה בסביבת ייצור

1. systemctl is-enabled tradingbot מדפיס enabled, והשירות שורד את sudo reboot.
2. chronyc tracking מדווח על סטייה של פחות מכמה מילישניות בשעון המערכת.
3. למפתח ה-API יש הרשאת מסחר, ללא הרשאת משיכה, וכן רשימת IP מורשים אם הבורסה מציעה אפשרות זו.
4. סיום התהליך באמצעות sudo systemctl kill -s SIGKILL tradingbot גורם לו לחזור לפעולה בתוך RestartSec.
5. צג ה-heartbeat שולח אליך התראה בתוך מרווח בדיקה אחד כאשר אתה עוצר את הבוט בכוונה.
6. גודל קובצי היומן מוגבל, ובמערכת הקבצים של החשבון root יש שטח פנוי ב-df -h.

הפעל את המערכת כולה ב-sandbox של הבורסה או במצב paper במשך שבוע לפני שימוש בכספים אמיתיים. כל אחד מהפריטים לעיל נכשל לפחות פעם אחת במהלך אותו שבוע, וזו מטרת השבוע.

FAQ

האם בוט מסחר זקוק לשרת בעל שיהוי נמוך או לשרת bare metal?

רק אם אתם מתחרים על מהירות הביצוע מול משתתפים אוטומטיים אחרים באותה זירת מסחר. במקרה כזה נדרש בדרך כלל אירוח משותף (colocation), ולא VPS למטרות כלליות. עבור בוט קמעונאי, זמן הלוך-חזור מושפע בעיקר מהמיקום הגאוגרפי ומהעיבוד של הברוקר עצמו. לכן בחרו שרת הקרוב לנקודת הקצה של ה-API, ומדדו באמצעות curl ו-mtr לפני שתשלמו על פתרון מהיר יותר.

כמה RAM ו-CPU דרושים לבוט מסחר?

רוב הבוטים בעלי אסטרטגיה יחידה מוגבלים על ידי הרשת ונמצאים במצב סרק בין אירועים. נכון ליולי 2026, 2 vCPU ו-2 GB של RAM מספיקים לבוט Python שעוקב אחר כמה מאות מכשירים. הזיכרון הופך למגבלה כאשר שומרים היסטוריית tick בזיכרון התהליך או מפעילים מסד נתונים מקומי. לכן עקבו אחר free -h ואחר היומן כדי לזהות הודעות OOM kill, במקום להסתמך על ניחושים.

מדוע ה-API של הבורסה דוחה בקשות עם שגיאת חותמת זמן?

שעון השרת נסחף מעבר לחלון החתימה של הבורסה, בדרך כלל בכמה שניות. התקינו chrony, ודאו ש-chronyc tracking מציג היסט קטן של System time וסטטוס leap מסונכרן, והגדירו את המכונה לשימוש ב-UTC כדי ששינוי לשעון קיץ לא יזיז את השעה. החלפת מפתח ה-API אינה פותרת בעיית שעון.

כיצד אפשר למנוע מהבוט להפסיק לפעול במהלך הלילה בלי שאדע?

הפעילו אותו תחת systemd באמצעות Restart=always ו-StartLimitIntervalSec=0, כדי שלולאת קריסה תמשיך לנסות מחדש במקום להיפסק לצמיתות. לאחר מכן הוסיפו heartbeat שהבוט שולח בסוף כל לולאה שהסתיימה בהצלחה. מנגנון האתחול מחדש מטפל בתהליך. ה-heartbeat מזהה מצב שבו התהליך עדיין פעיל אך תקוע.

האם אפשר להפעיל את הבוט ואת מערכת הניטור שלי באותו VPS?

אפשר, אך ביום שבו הדבר יהיה חשוב מערכת הניטור תציג תמונה שגויה. הסיבה היא שתקלה שמפילה את הבוט תפיל גם את מערכת הניטור. השאירו את מערכת ההתראות במכונה נפרדת, ורצוי אצל ספק או באזור שונים, והשתמשו בשרת של הבוט רק עבור הבוט והיומנים שלו.