VPS لروبوتات التداول: ما الذي يهم فعلاً؟

ما الذي يحتاجه روبوت التداول من VPS

يُقيَّم VPS المخصّص لروبوتات التداول وفق أربعة أمور: هل تعود العملية إلى العمل بعد توقفها، وهل الساعة مضبوطة، وهل يصعب سرقة مفاتيح API (واجهة برمجة التطبيقات)، وهل تعرف عند توقفها. تأتي السرعة الخام في مرتبة متأخرة بالنسبة إلى روبوت للاستخدام الفردي، لأن الجزء الأبطأ في مسار طلبك هو الوسيط والمسافة إليه، وليس المضيف الذي يشغّل Python.

هذا دليل هندسي. لا يتضمن أي جزء منه نصيحة مالية، ولا يناقش أي استراتيجية.

الجاهزية المستمرة هي انضباط إعادة التشغيل، وليست رقماً في صفحة مبيعات

يعلن كل خادم في العالم عن جاهزية بنسبة 99.9 بالمئة. يصف هذا الرقم برنامج الـhypervisor، وليس روبوتك. قد يتوقف الروبوت بسبب استثناء غير معالج، أو websocket لا يعيد الاتصال أبداً، أو بسبب أداة OOM (نفاد الذاكرة)، بينما يبقى الخادم قيد التشغيل طوال الوقت. لذلك، السؤال المفيد هو: ماذا يحدث خلال الثواني العشر التالية لخروج عمليتك؟

شغّل الروبوت كخدمة systemd ودَع نظام init يتولى إعادة التشغيل. ينفذ ملف الوحدة ذلك في ستة أسطر.

[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 هو الجزء الذي يستمر بعد إعادة التشغيل، وتؤدي تحديثات kernel إلى إعادة التشغيل. لمعرفة ما إذا كان الروبوت يتوقف بصمت، اطلب من systemd عرض عداد إعادة التشغيل:

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

يمثل NRestarts=0 بعد أسبوع روبوتاً سليماً. أما NRestarts=812 فيعني أنك كنت تتداول باستخدام عملية تعيد الاتصال طوال الليل. يشرح تشغيل برنامج كخدمة systemd البنية الكاملة لملف الوحدة، بما في ذلك المؤقتات للمهام المجدولة مثل التقرير اليومي.

اضبط الساعة على UTC وتحقق من مزامنتها

توقّع Exchange APIs الطلبات باستخدام طابع زمني، وترفض أي طلب يقع خارج نافذة زمنية محددة، غالباً 5 ثوانٍ أو أقل. تؤدي الساعة غير المتزامنة إلى أخطاء تبدو كأنها حالات فشل في المصادقة، لذلك قد يبدّل المستخدمون المفاتيح لساعات قبل فحص الوقت. في واجهات Binance-style APIs، تكون الرسالة حرفية: 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 خارج الأماكن التي تنسخها

مفتاح Exchange مُسرَّب أخطر من مفتاح SSH مُسرَّب، لأن صلاحية السحب تحوّله فوراً إلى أموال. تغطي عادتان معظم المخاطر.

أولاً، لا تمنح مفتاح bot صلاحية السحب مطلقاً. وعندما يدعم Exchange ذلك، قيّد المفتاح بعنوان 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.

يجب ألا يعمل bot بصلاحيات root أو باستخدام مستخدم تسجيل دخولك. أنشئ حساب نظام بلا shell وبلا home directory يمكن تسجيل الدخول إليه:

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

يوضح تشغيل الخدمات كمستخدم غير مميّز سبب كل خيار من تلك الخيارات، ومدى ما يفعله ProtectSystem=strict فعلياً. يجب وضع بقية إعدادات الخادم الأساسية، مثل مفاتيح SSH وجدار الحماية، ضمن الدقائق العشر الأولى على VPS جديد.

اكتشف توقّف الخدمة قبل أن يكتشفه الوسيط

systemctl status يوضح أن العملية قيد التشغيل. لكنه لا يوضح أن الروبوت ينفّذ أي شيء. فالعملية العالقة في حلقة إعادة محاولة للاتصال بـwebsocket متوقف تتجاوز كل الفحوص التي يستطيع systemd تنفيذها.

استخدم heartbeat بدلاً من ذلك. يوفّر Uptime Kuma شاشات مراقبة push؛ إذ يتوقع أن يستدعي الروبوت عنوان URL وفق جدول زمني، ويرسل تنبيهاً عندما يتوقف وصول الاستدعاءات. ضع الاستدعاء في نهاية الحلقة الرئيسية، بعد الجزء الذي يثبت أن الروبوت يعمل، مثل القراءة الناجحة لبيانات السوق.

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

اضبط الفاصل الزمني للمراقبة على نحو يساوي ضعف زمن الحلقة تقريباً، حتى لا تؤدي التقلبات الطبيعية إلى إرسال تنبيه إليك. شغّل شاشة المراقبة على خادم مختلف عن خادم الروبوت، لأن شاشة المراقبة التي تتوقف مع الشيء الذي تراقبه لن تبلغ عن أي شيء. يوضّح إعداد مراقبة الحالة ذاتية الاستضافة باستخدام Uptime Kuma خطوات الإعداد.

أضف تنبيهاً للمساحة القرصية أيضاً. سيملأ الروبوت الذي يكتب سجلات تفصيلية نظام الملفات الجذر خلال أسابيع، وامتلاء القرص يوقف الكتابة إلى قاعدة البيانات، لا استدعاء الشبكة، لذلك تكون الأعراض غريبة. يحافظ journalctl --vacuum-time=14d وسطر SystemMaxUse= في /etc/systemd/journald.conf على حجم journal ضمن حدود معقولة.

الجزء الصريح: زمن الانتقال يعتمد في الغالب على عوامل خارج خادمك

هنا يتوقف سوق منتجات VPS المخصصة للتداول عن كونه تقنياً. تعرض صفحات التسويق أرقاماً تقل عن ميلي ثانية، وتوحي بأن الخادم هو العامل الفاصل بينك وبين تنفيذ الأمر. لكن هذا لا ينطبق على معظم روبوتات التداول بالتجزئة.

ينتقل أمرك من الروبوت إلى نقطة نهاية المنصة أو الوسيط عبر الإنترنت العام. ويتحدد هذا المسار أساساً بالمسافة الجغرافية وبالربط بين مزود الخدمة لديك ومزود الخدمة لديهم. إذا اتصل خادم في Frankfurt بنقطة نهاية في Tokyo، فسيستغرق ذهاباً وإياباً نحو 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 ميلي ثانية من وقت وحدة المعالجة المركزية في كل دورة. هذا زمن انتقال فعلي يمكنك التحكم فيه مجاناً. حلّل أداء الدورة قبل أن تبحث عن خادم أسرع.

العوامل المهمة في الخادم الذي تختاره هي الموقع الجغرافي، واستقرار الشبكة، وذاكرة كافية بحيث لا يضطر OOM killer إلى إنهاء العمليات. حتى July 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 تنبيهاً خلال فترة واحدة عند إيقاف bot عمداً.
6. تكون السجلات محدودة الحجم، وتتوفر مساحة كافية في نظام الملفات الجذري ضمن df -h.

شغّل النظام بالكامل في بيئة sandbox الخاصة بالمنصة أو في paper mode لمدة أسبوع قبل استخدام أموال حقيقية. سيفشل كل بند أعلاه مرة واحدة على الأقل خلال ذلك الأسبوع، وهذا هو الهدف من الأسبوع.

FAQ

هل يحتاج روبوت التداول إلى خادم منخفض زمن الاستجابة أو خادم bare metal؟

فقط إذا كنت تنافس مشاركين آليين آخرين في سرعة التنفيذ ضمن المكان نفسه، وهذا يعني عادةً الاستضافة المشتركة في مركز البيانات بدلاً من VPS عام. بالنسبة إلى روبوت يستخدمه متداول عادي، يهيمن الموقع الجغرافي ومعالجة الوسيط على زمن الرحلة ذهاباً وإياباً، لذلك اختر خادماً قريباً من نقطة نهاية API، وقِس باستخدام curl وmtr قبل أن تدفع مقابل أي أداء أعلى.

ما مقدار RAM ووحدة المعالجة المركزية الذي يحتاج إليه روبوت التداول؟

تعتمد معظم الروبوتات ذات الاستراتيجية الواحدة على الشبكة، وتبقى في وضع الخمول بين الأحداث. اعتباراً من July 2026، يستطيع 2 vCPU و2 GB من RAM تشغيل روبوت Python يتتبع بضع مئات من الأدوات. تصبح الذاكرة قيداً عندما تحتفظ بسجل tick داخل العملية أو تشغّل قاعدة بيانات محلية، لذلك راقب free -h وjournal بحثاً عن رسائل OOM kill بدلاً من التخمين.

لماذا ترفض واجهة API الخاصة بالمنصة طلباتي بسبب خطأ في الطابع الزمني؟

انحرفت ساعة الخادم خارج نافذة التوقيع التي تسمح بها المنصة، وعادةً يكون الانحراف بضع ثوانٍ. ثبّت chrony، وتأكد من أن chronyc tracking يعرض إزاحة صغيرة System time وحالة leap متزامنة، واضبط الجهاز على UTC حتى لا يؤدي تغيير التوقيت الصيفي إلى تغيير الساعة. لا يؤدي تدوير API key إلى إصلاح مشكلة الساعة.

كيف أمنع روبوتي من التوقف طوال الليل دون أن أعرف؟

شغّله ضمن systemd باستخدام Restart=always وStartLimitIntervalSec=0 حتى تستمر محاولة التشغيل بعد حلقة انهيار بدلاً من توقفه نهائياً، ثم أضف heartbeat يرسله الروبوت في نهاية كل حلقة ناجحة. يتولى restart معالجة العملية. ويكشف heartbeat حالة بقاء العملية قيد التشغيل مع توقفها عن الاستجابة.

هل يمكنني تشغيل الروبوت ونظام المراقبة على VPS نفسه؟

يمكنك ذلك، لكن نظام المراقبة سيعطيك معلومات مضللة في اليوم الذي تحتاج إليه فيه، لأن العطل الذي يوقف الروبوت سيوقف نظام المراقبة معه. أبقِ نظام التنبيه على جهاز منفصل، ويفضل أن يكون لدى مزود أو في منطقة مختلفة، واستخدم خادم الروبوت للروبوت وسجلاته فقط.