ما الذي يحتاجه روبوت التداول فعلًا من 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 وأثبت أنها متزامنة

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

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

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

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

اكتشف توقفه قبل الوسيط

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

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

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

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

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

متى يكون الخادم مهمًا إذن؟ عندما يكون خادمك مستضافًا في نفس موقع منصة التداول أو متصلًا بها اتصالًا مباشرًا، وتتنافس على ترتيبك في قائمة الأوامر. هذا نشاط مختلف بميزانية مختلفة. ويكون مهمًا أيضًا عندما يكون كودك نفسه عنق الزجاجة. فقد يستهلك روبوت يعيد حساب المؤشرات على كامل السجل عند كل تحديث 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. يرسل لك نظام مراقبة نبض الخدمة تنبيهًا خلال فترة واحدة عند إيقافك للروبوت عمدًا.
6. تكون السجلات محدودة الحجم، وتتوفر مساحة كافية في نظام الملفات الجذري ضمن df -h.

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

FAQ

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

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

ما مقدار RAM وCPU الذي يحتاج إليه روبوت التداول؟

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

لماذا ترفض exchange طلبات API بسبب خطأ في timestamp؟

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

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

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

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

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