الارتهان لمزود السحابة: كيف تبني خطة خروج قبل أن تحتاجها

الارتهان لمزود السحابة يعني أن كلفة خروجك من عنده صارت أعلى من كلفة بقائك، حتى لو كانت خدمته لم تعد تناسبك. ما يحدث عادة ليس قراراً واحداً خاطئاً، بل عشرات القرارات الصغيرة: قاعدة بيانات مُدارة بصيغة خاصة بالمزود، ودوال serverless مكتوبة على واجهته وحده، وطوابير رسائل لا يوجد لها مكافئ خارج منصته، ثم فاتورة إخراج بيانات تصل إلى نحو 0.09 دولار لكل GB عند بعض المزودين العالميين الكبار. الحل ليس تجنب السحابة، بل بناء خطة خروج من اليوم الأول تقوم على أربعة أعمدة: تقنيات قياسية قابلة للنقل مثل Docker وPostgreSQL وواجهة S3، ونسخ احتياطية بصيغ مفتوحة تملكها أنت خارج حساب المزود، واختبار نقل سنوي فعلي لا على الورق، وبنود عقد تضمن حقك في بياناتك ومدة كافية لاستلامها. الشركة التي تطبق هذه الأعمدة تستطيع نقل نظام ERP متوسط الحجم خلال من يومين إلى خمسة أيام، بينما الشركة المرتهنة قد تحتاج من ثلاثة إلى ستة أشهر من إعادة الكتابة. هذا المقال يشرح أين يختبئ الارتهان، وكيف تكتب خطة خروج قابلة للتنفيذ بالأوامر، وكيف تقارن كلفة الخروج من مزود عالمي ومن مزود محلي بالريال.

أين يحدث الارتهان فعلياً

الارتهان يتسلل من ثلاث بوابات رئيسية، وأخطرها التي لا تظهر في الفاتورة الأولى.

الخدمات المُدارة الخاصة بالمزود

كل خدمة لها اسم تجاري خاص بمزود واحد هي نقطة ارتهان محتملة. قاعدة بيانات NoSQL مملوكة للمزود، أو محرك بحث بواجهة خاصة، أو نظام مصادقة مدمج في منصته. الكود الذي يستدعي هذه الخدمات يُكتب بمكتبات المزود نفسه، فإذا أردت الخروج لا تنقل بيانات فقط، بل تعيد كتابة طبقة كاملة من التطبيق. في نظام ERP نموذجي، قد يصل الكود المرتبط بواجهات مزود واحد إلى 20% أو 30% من قاعدة الكود حين لا ينتبه الفريق لذلك مبكراً.

رسوم إخراج البيانات

إدخال البيانات إلى السحابة مجاني غالباً، أما إخراجها فمدفوع. شركة لديها 10TB من الملفات والنسخ الاحتياطية ستدفع نحو 900 دولار، أي قرابة 3,375 ريالاً، لمجرد سحب بياناتها مرة واحدة من مزود يحاسب 0.09 دولار لكل GB، وهذا قبل حساب ساعات الفريق وتوقف الخدمة. الرقم ليس ضخماً بذاته، لكنه يتكرر مع كل اختبار نقل، فيصير حاجزاً نفسياً يمنع الفريق من التجربة أصلاً.

صيغ التصدير المغلقة

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

اختر تقنيات قياسية قابلة للنقل

القاعدة العملية بسيطة: استخدم الخدمة المُدارة إذا كان لها مكافئ مفتوح بنفس البروتوكول، وتجنبها إذا كانت واجهتها حصرية. هذا الجدول يلخص البدائل الآمنة.

الطبقة	خيار يرتهنك	خيار قابل للنقل
التطبيق	دوال serverless بواجهة خاصة	حاويات Docker مع docker compose
قاعدة البيانات	محرك NoSQL مملوك للمزود	PostgreSQL أو MySQL بإصدار قياسي
تخزين الملفات	واجهة تخزين خاصة	أي تخزين يدعم S3 API مثل MinIO
الطوابير	خدمة رسائل حصرية	Redis أو RabbitMQ
البنية	قوالب بنية خاصة بمزود واحد	Terraform أو Ansible مع سكربتات موثقة

الحاويات هي أهم خطوة منفردة، لأن ملف docker-compose.yml واحد يصف التطبيق كاملاً، وتشغيله على سيرفر جديد يحتاج أمرين فقط:

git clone git@your-git:company/erp.git && cd erp
docker compose pull && docker compose up -d

أما التخزين، فواجهة S3 صارت معياراً فعلياً تدعمه عشرات الأنظمة، ونقل bucket كامل بين مزودين يتم بأداة rclone بأمر واحد:

rclone sync oldcloud:erp-files newcloud:erp-files --transfers 16 --checksum

الخيار --checksum يتحقق من سلامة كل ملف، وهذا يعطيك دليلاً على اكتمال النقل لا مجرد انطباع.

النسخ الاحتياطية: صيغة مفتوحة ومكان مستقل

خطة الخروج الحقيقية تبدأ من النسخة الاحتياطية. لقطة القرص (snapshot) داخل حساب المزود مفيدة للاستعادة السريعة، لكنها لا تفيدك في الخروج لأنها لا تعمل إلا عنده. أضف دائماً نسخة منطقية بصيغة مفتوحة تُحفظ خارج المزود:

# نسخة PostgreSQL بصيغة قابلة للاستعادة في أي مكان
pg_dump -Fc -d erp_prod -f /backup/erp_$(date +%F).dump

# نسخة MySQL مع الإجراءات المخزنة
mysqldump --single-transaction --routines --triggers erp_prod | gzip > /backup/erp_$(date +%F).sql.gz

احتفظ بنسختين على الأقل في مكانين مختلفين، واحدة منهما عند جهة غير المزود الأساسي. على الخادم السحابي من كلاود مثلاً تقدر تضيف نسخاً احتياطياً يومياً بمدة احتفاظ 7 أيام بـ800 ريال سنوياً أو 30 يوماً بـ2,000 ريال، وتبقى النسخة المنطقية التي تصدّرها أنت ملكك الكامل بصيغة تُستعاد على أي سيرفر لينكس.

اختبر النقل سنوياً، لا على الورق

خطة الخروج التي لم تُجرَّب لا قيمة لها. مرة في السنة، خذ يوماً واحداً وانقل نسخة كاملة من النظام إلى سيرفر مستقل لدى مزود آخر، ثم قِس ثلاثة أرقام: كم ساعة استغرق النقل، وكم خطوة يدوية احتجت لم تكن موثقة، وهل اشتغل التطبيق دون تعديل في الكود. سيرفر اختبار بحجم باقة نمو (2 vCPU و4GB RAM) يكفي غالباً لتشغيل نسخة تجريبية من تطبيق متوسط، وكلفته جزء صغير من كلفة توقف واحد غير مخطط.

اكتب قائمة الاختبار في ملف واحد داخل مستودع الكود، وحدّثها بعد كل تجربة:

1. تصدير قاعدة البيانات واستعادتها والتحقق من عدد السجلات في أهم 10 جداول.
2. مزامنة الملفات بـrclone مع التحقق بالـchecksum.
3. تشغيل الحاويات بأمر docker compose واحد.
4. تحويل DNS بقيمة TTL منخفضة (300 ثانية) قبل النقل بـ48 ساعة.
5. تشغيل اختبارات القبول وتسجيل الزمن الكلي.

إذا تجاوز الزمن الكلي 8 ساعات، فهذا مؤشر على ارتهان يحتاج معالجة قبل أن تضطر للخروج تحت ضغط.

بنود العقد التي تحمي حقك في بياناتك

التقنية وحدها لا تكفي إذا كان العقد يسمح للمزود بحذف بياناتك فور انتهاء الاشتراك. قبل التوقيع، تأكد من هذه البنود:

• ملكية البيانات: نص صريح أن البيانات ملك العميل وحده، وأن المزود لا يحتفظ بأي حق استخدام لها.
• فترة الاستلام بعد الانتهاء: مدة لا تقل عن 30 يوماً يبقى فيها الوصول للبيانات متاحاً بعد انتهاء العقد أو إنهائه.
• صيغة التسليم: التزام بتسليم البيانات بصيغ قياسية مفتوحة، لا بصيغة داخلية.
• موقع البيانات: تحديد أن البيانات تبقى داخل المملكة طوال العقد وأثناء التسليم، وهذا مهم لمتطلبات الهيئة الوطنية للأمن السيبراني.
• الحذف الموثق: شهادة حذف مكتوبة بعد استلامك للبيانات وتأكيدك.

كلفة الخروج: مزود عالمي مقابل مزود محلي

لنأخذ سيناريو شركة لديها نظام مخصص بـ500GB قاعدة بيانات و5TB ملفات، وتريد النقل إلى مزود آخر.

البند	مزود عالمي بخدمات خاصة	مزود محلي بتقنيات قياسية
رسوم إخراج 5.5TB	نحو 1,850 ريالاً	ضمن نقل البيانات المشمول في الباقة غالباً
إعادة كتابة الكود	من 4 إلى 12 أسبوع عمل	لا يوجد، الحاويات نفسها تعمل
زمن النقل الفعلي	أسابيع	من يومين إلى خمسة أيام
موقع البيانات أثناء النقل	قد يمر خارج المملكة	داخل المملكة

المزود المحلي لا يحميك تلقائياً من الارتهان، لكنه حين يقدم سيرفرات لينكس قياسية بصلاحيات root كاملة يجعل الخروج قراراً تجارياً لا مشروعاً هندسياً. في كلاود تأتي باقة أعمال (4 vCPU و8GB RAM) مع 1TB نقل بيانات ضمن 11,500 ريال سنوياً، وكل تيرابايت إضافي بـ1,150 ريالاً، فتعرف كلفة نقل بياناتك مسبقاً بالريال. تقدر تراجع التفاصيل في صفحة الأسعار.

خطة الخروج في صفحة واحدة

لا تحتاج وثيقة من 50 صفحة. اكتب صفحة واحدة تجيب عن هذه الأسئلة، واحفظها مع الكود:

1. ما الخدمات الخاصة بالمزود التي نستخدمها، وما البديل المفتوح لكل واحدة؟
2. أين تُحفظ النسخة المنطقية الأحدث، وبأي صيغة، ومن يملك الوصول إليها؟
3. كم تيرابايت سننقل، وكم ستكلف رسوم الإخراج بالريال؟
4. متى كان آخر اختبار نقل، وكم ساعة استغرق؟
5. ما بنود العقد التي تضمن فترة الاستلام وصيغة التسليم؟

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