التحدي: منصات عاملة فوق بنية يصعب الوصول إليها

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

لم يكن لدى أي من المشاريع فريق DevOps مخصص. لم تكن الخدمات تعمل داخل حاويات، وكانت Production البيئة الوحيدة، وكانت عمليات النشر يدوية، فيما حُفظت الملفات على الأقراص المحلية للخوادم. كما احتاجت المراقبة والتكرار والنسخ الاحتياطي والتعافي من الكوارث والضوابط الأمنية إلى تطوير جوهري.

لم يكن المطلوب مجرد نقل خوادم؛ بل إنشاء نموذج تشغيلي يبقى فيه فريق محدد مسؤولاً عن صحة المنصة وأمنها وعمليات النشر والاستجابة للحوادث بعد اكتمال الترحيل.

Audit أولاً: خطة ترحيل قبل تنفيذ أي تغيير

قبل التنفيذ، أجرت Dropp Tempo تدقيقاً للبنية الخارجية لكل مشروع. شمل ذلك معمارية الخدمات وقواعد البيانات ومسارات النشر والاعتماديات الخارجية والمراقبة والنسخ الاحتياطية وضوابط الوصول وHardening وسيناريوهات الأعطال.

حددت عمليات التدقيق مجموعة واضحة من الأولويات: نقل الاستضافة إلى إيران، وتحويل الخدمات إلى حاويات، وإنشاء بيئات Staging، وإضافة التكرار إلى الطبقات الحيوية، وتوحيد عمليات النشر، ونقل الملفات إلى Object Storage، وبناء مسارات موثوقة للنسخ الاحتياطي والاستعادة.

أُعدت Runbook مستقلة للترحيل والانتقال النهائي وRollback لكل منصة. وهكذا بدأت مرحلة Build بخطة تشغيلية واضحة، لا بمجرد اختيار سريع للأدوات.

ثلاث عمليات ترحيل في نحو ٢٠ يوماً لكل مشروع، بلا فقدان للبيانات

اكتمل ترحيل كل مشروع في نحو ٢٠ يوماً. بدأ العمل بتحويل الخدمات إلى حاويات وإنشاء بيئة Staging، ثم نُفذت عملية ترحيل تجريبية للتحقق من النشر واتصال الخدمات واستعادة البيانات وسلوك التطبيق في البيئة الجديدة قبل الانتقال إلى Production.

خلال نافذة الانتقال النهائية، وُضعت الخدمات في وضع القراءة فقط، ونُقلت قواعد MongoDB وSQL Server من خلال عملية Dump وRestore محكومة. تحققت Dropp Tempo من سلامة البيانات بعد الاستعادة، ثم أجرى فريق التطوير اختباراته الوظيفية.

اكتملت عمليات الانتقال الثلاث خلال ساعتين أو أقل ومن دون فقدان أي بيانات. كما بقيت البنية السابقة قيد التشغيل لمدة شهر، لتظل إمكانية Rollback متاحة طوال مرحلة الاستقرار.

معمارية للتوافر والأداء والاستعادة

تستخدم البيئات الجديدة عبر المشاريع الثلاثة مزيجاً من Kubernetes وDocker Swarm. تعمل الخدمات على عناقيد متعددة العقد، فيما تتولى NGINX أو خدمات CDN توزيع الحركة. وقد وحّد ذلك عمليات النشر وإدارة السعة، وجعل أعطال العقد المنفردة قابلة للاحتواء.

على مستوى البيانات، تعمل MongoDB بصيغة Replica Set، ويعتمد SQL Server على Standby Node. كما نُقلت ملفات المنتجات من أقراص خوادم التطبيقات إلى Object Storage. وتُدار عمليات Failover بصورة محكومة بعد تقييم قائد الحادث للوضع واتخاذ قرار التحويل.

تتولى Dropp Tempo نشر وتشغيل البنية التي تدعم واجهات API للتداول وWebSocket والتسعير والإيداع والسحب وKYC والإشعارات. أما المنطق المالي وأصول المستخدمين والمحافظ والمفاتيح الخاصة، فهي خارج نطاق مسؤوليتنا.

من النشر اليدوي إلى Deployment خلال عشر دقائق

أنشأت Dropp Tempo للمشاريع الثلاثة Pipelines تعتمد على GitLab CI وGitLab Container Registry. ويشمل مسار الإصدار القياسي تثبيت الاعتماديات وLint وBuild وRelease وDeploy، وتستغرق الدورة الكاملة نحو ١٠ دقائق.

في بيئات Kubernetes، يطبق Argo CD الحالة المطلوبة المحفوظة في Git. أما في Docker Swarm، فتُنفذ عمليات النشر عبر Webhooks في Portainer. ويمكن تنفيذ Rollback من خلال Argo CD أو Portainer خلال نحو ١٠ دقائق أيضاً.

يبدأ فريق التطوير عملية الإصدار، بينما تظل Dropp Tempo مسؤولة عن صيانة الـPipelines والـRegistry والبنية الخاصة بالنشر، ومعالجة مشكلاتها وتطويرها باستمرار.

وصول مستقر داخل إيران واتصال دولي محكوم

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

باستخدام pfSense أو MikroTik مع أنفاق تعتمد على OpenVPN وWireGuard، صممت Dropp Tempo مسارات الخروج المطلوبة وأدخلتها ضمن منظومة المراقبة. وفي أحد المشاريع أُضيف نفق احتياطي، حتى لا يؤدي تعطل المسار الرئيسي إلى توقف الاتصال الخارجي بالكامل.

تمثل هذه الطبقة أحد المتطلبات المميزة للبنية التحتية لمنصات التداول في هذا السوق. فسلامة الخوادم وحدها لا تكفي؛ إذ يجب تصميم الاتصال بالخدمات الخارجية ومراقبته وإدراجه ضمن إجراءات الاستجابة للحوادث.

pfSense

أمن متعدد الطبقات وقابل للتدقيق

تمر جميع عمليات الوصول الإداري في المشاريع الثلاثة عبر VPN، بينما يتم الوصول إلى الخوادم من خلال Teleport مع MFA. وتُحفظ سجلات الوصول عبر VPN وTeleport لأغراض التدقيق، فيما تُدار الأسرار بحسب طبيعة كل بيئة باستخدام GitLab Environment Variables أو Portainer أو HashiCorp Vault.

تُطبّق إجراءات Hardening على جميع الخوادم من خلال Ansible Playbook مخصصة طورتها Dropp Tempo. وتُفحص Container Images باستخدام Trivy، بينما تعمل WAF وRate Limiting وDDoS Protection عند طبقة CDN. كما تُشفّر النسخ الاحتياطية قبل نقلها إلى Object Storage.

في أحد المشاريع الثلاثة، اجتازت البنية التحتية تقييماً أمنياً أجرته الجهة المختصة وحصلت على درجة مرتفعة؛ وهو تحقق مستقل من جودة الضوابط المطبقة ومستوى النضج التشغيلي.

TrivyTeleport

Observability لأكثر من خمسة ملايين طلب يومياً

تراقب Prometheus وGrafana وAlertmanager الخوادم والعناقيد وقواعد البيانات والـEndpoints ومؤشرات الأعمال التي تتيحها الخدمات. ويوفر ELK تجميعاً مركزياً للسجلات وAPM، بينما يسجل Sentry أخطاء التطبيقات، ويقيس Uptime Kuma توافر الـEndpoints الحيوية من خارج البنية.

تصل التنبيهات التشغيلية إلى قناة دعم العميل في Mattermost وإلى Rocket.Chat الداخلي لدى Dropp Tempo. ويتفعّل فريق On-call عند ورود تنبيه حرج أو اتصال من العميل، فيما ينسق قائد الحادث التشخيص وFailover وRollback واستعادة الخدمة.

تسجل البيئات الثلاث مجتمعة أكثر من خمسة ملايين طلب يومياً عند طبقة NGINX، وحققت كل منها توافراً يتجاوز ٩٩٫٩٥٪ خلال فترة الثلاثين يوماً السابقة للنشر. وفي أحد المشاريع، واصلت المنصة الخدمة خلال حملة مرتفعة الحركة مرتبطة بكأس العالم من دون اضطراب تشغيلي ملحوظ.

Uptime KumaRocket.ChatMattermost

نسخ احتياطي وتعافٍ من الكوارث مصممان للتشغيل الفعلي

تحصل جميع قواعد البيانات على Full Backup كل ٢٤ ساعة وIncremental Backup كل ٣٠ دقيقة. وتُحفظ النسخ المشفرة في Object Storage خارج البنية الرئيسية لمدة ٣٠ يوماً، بينما يوفر Database Replication طبقة إضافية لحماية الخدمات الحيوية.

أُجريت اختبارات Restore بعد التنفيذ، وحُدد RPO قدره ١٥ دقيقة وRTO قدره ساعة واحدة للبيانات والخدمات الحيوية. كما توجد بيئة Passive جاهزة في مركز بيانات ثانٍ لدى Cloud Provider نفسه، وتظل البيانات الحيوية متزامنة معها والخدمات منشورة مسبقاً عليها.

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

النتائج التقنية والتجارية

  • تنفيذ ثلاثة مشاريع للترحيل وإعادة الهندسة، في نحو ٢٠ يوماً لكل مشروع
  • إتمام الانتقال النهائي خلال ساعتين أو أقل، بلا فقدان للبيانات
  • تحسين سرعة الوصول واستقراره للمستخدمين داخل إيران
  • معالجة أكثر من خمسة ملايين طلب يومياً عند طبقة دخول البنية
  • تسجيل توافر يتجاوز ٩٩٫٩٥٪ عبر المنصات الثلاث
  • استبدال الإصدارات اليدوية بـPipelines قياسية تستغرق نحو ١٠ دقائق
  • إتاحة Rollback عبر Argo CD أو Portainer خلال نحو ١٠ دقائق
  • إنشاء بيئات Staging وDatabase Replication وObject Storage
  • تطبيق Monitoring وتجميع السجلات وAPM والتنبيهات ومراقبة التوافر الخارجية
  • تطبيق ضوابط أمنية تشمل VPN وMFA وHardening وفحص الصور وWAF وDDoS Protection
  • إنشاء نسخ احتياطية مشفرة واختبارات Restore وبيئة Passive للاستعادة
  • دعم على مدار الساعة مع استجابة أولية خلال أقل من ٣٠ دقيقة

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

Retain: مسؤولية البنية لا تنتهي عند Go-live

انتقلت المشاريع الثلاثة إلى مرحلة Retain بعد الترحيل. ويواصل فريق Dropp Tempo المكوّن من ستة أشخاص—CTO وDevOps Team Lead واثنين من Senior DevOps Engineers واثنين من Junior DevOps Engineers—تغطية المراقبة والاستجابة للحوادث وصيانة الـPipelines وإدارة التحديثات والسعة والنسخ الاحتياطي واختبارات الاستعادة والأداء وبنية الخدمات الجديدة.

يعني الدعم على مدار الساعة والاستجابة الأولية خلال أقل من ٣٠ دقيقة أن العميل لا يُترك وحده بعد التسليم. فالفريق الذي يعرف المعمارية ومسار الترحيل يبقى مسؤولاً عن صحة المنصة اليومية وتطورها المستمر.

إذا كنت تعمل على ترحيل أو إعادة تصميم أو تثبيت البنية التحتية لمنصة تداول عملات رقمية أو منصة مالية، تستطيع Dropp Tempo البدء بمراجعة Architecture & Reliability ومواصلة المسؤولية معك عبر مراحل Audit وBuild وRetain.

احجز جلسة لمراجعة معمارية البنية التحتية لمنصتك وموثوقيتها.