نقل Odoo من استضافة إلى أخرى يبدو مهمة واحدة، ثم يتبيّن أنه ست مهام. نسخ قاعدة البيانات هو غالباً أبسط ما في الأمر، والوقت يذهب إلى كل ما هو معلّق بها: الملفات المرفقة، والكود المخصص، ومسار البريد الصادر، والمهام المجدولة، والتكاملات التي ضُبطت مرة واحدة قبل سنوات ولم يوثقها أحد.
ما يلي خريطة عملية لما ينتقل بسلاسة، وما لا ينتقل، وكيف تخطط لعملية تحويل لا تلتهم أسبوع عمل كامل.
مما يتكوّن الترحيل فعلياً
نظام Odoo أربعة أشياء منفصلة، وكل منها ينتقل بطريقة مختلفة:
- قاعدة بيانات PostgreSQL. البيانات المهيكلة والإعدادات وسجل كل حركة. تنتقل عبر تصدير واستعادة، وهي الجزء الأكثر قابلية للتنبؤ.
- مخزن الملفات (filestore). المرفقات وصور المنتجات والمستندات المرفوعة وملفات PDF المولّدة. يقع على القرص لا داخل قاعدة البيانات، وهو أكثر عنصر يُنسى في عمليات الترحيل.
- الوحدات المخصصة ووحدات الطرف الثالث. الوحدات المثبتة على الخادم المصدر. إذا لم تتوفر على الخادم الهدف بإصدارات متوافقة، فلن تعمل قاعدة البيانات المستعادة أصلاً.
- البيئة المحيطة. إعدادات DNS وشهادات SSL وإعدادات البريد وسلوك المهام المجدولة، وكل نظام خارجي ما زال يشير إلى الرابط القديم.
الخطة التي تحسب البند الأول فقط هي الخطة التي تفشل.
المفاجآت تسكن في مخزن الملفات
استعادة قاعدة البيانات تنجح تماماً حتى بدون مخزن الملفات، وهنا تحديداً تكمن المشكلة. سجلات المرفقات تنجو من الاستعادة وتظل تشير إلى ملفات لم تعد موجودة على القرص، فلا يظهر أي خطأ لحظة التحويل. يظهر العطل بعد أسابيع، حين يفتح أحدهم عقداً موقعاً من مارس فيجد صفحة فارغة، أو حين تتحول صورة منتج إلى أيقونة مكسورة في بوابة العملاء.
انسخ مخزن الملفات مع نسخة قاعدة البيانات، ثم تحقق منه بالحجم وعدد الملفات لا بالنظرة السريعة. وعند الفحص العشوائي، افتح مرفقات قديمة لا مرفقات الأمس، لأن الملفات الحديثة هي الأرجح وجوداً في أي نسخة ناقصة.
تطابق الوحدات، لا مجرد وجودها
يبني Odoo سجل النماذج انطلاقاً من الوحدات المسجلة كمثبتة داخل قاعدة البيانات. فإذا كانت وحدة مسجلة هناك وكودها غائب على الخادم الهدف، أو موجوداً بإصدار لم تعد حقوله متطابقة، فلن يقلع النظام. هذا ليس تدهوراً تدريجياً في الأداء، بل قاعدة بيانات لا تعمل.
قبل أن تبدأ، جهّز جرداً بالوحدات المثبتة على النظام المصدر، وثبّت الوحدات المخصصة على commit محدد بدل فرع متحرك. عبارة «سنسحب آخر إصدار» هي الطريق المعتاد لتحويل الترحيل إلى مشروع ترقية غير مخطط له.
ما الذي يتعطل بعد استعادة سليمة
- البريد الصادر. الخادم الجديد يرسل من عنوان IP جديد. إذا لم يشمله سجل SPF، فإما أن تذهب الرسائل إلى البريد المزعج أو تُرفض تماماً، بينما يبدو طابور الإرسال سليماً طوال الوقت.
- البريد الوارد. بيانات اعتماد خوادم البريد ونطاق الـ catchall تحتاج إعادة ضبط، وإلا توقفت الردود الواردة عن الارتباط بسجلاتها.
- المهام المجدولة. قاعدة البيانات المستعادة تحمل جدولها الزمني كاملاً. وإذا بقي النظام القديم يعمل، شغّل النظامان المهام نفسها: فواتير مكررة ومزامنة مزدوجة ورسائل تذكير مرتين. أوقف المهام المجدولة على المصدر قبل أن تفتح الهدف للمستخدمين.
- تكاملات الطرف الثالث. بوابات الدفع وشركات الشحن وتطبيقات المراسلة ونقاط الفوترة الإلكترونية تحتفظ جميعها بروابط استدعاء وبيانات اعتماد مرتبطة بالبيئة. وحين يتعلق الأمر بالامتثال، فإن دعم ZATCA وETA وFTA وWPS يأتي من وحدات التوطين الرسمية في Odoo، ولهذه الوحدات إعداداتها الخاصة بالبيئة التي يجب إدخالها من جديد لا افتراض انتقالها.
- الرابط الأساسي للنظام. روابط البوابة ورسائل إعادة تعيين كلمة المرور وروابط الفواتير المشتركة تُبنى كلها من معامل الرابط الأساسي. إغفاله يعني أن عملاءك سيستلمون رسائل سليمة مليئة بروابط ميتة.
خطط للتحويل لا للنسخ فقط
أعلى خطوة قيمة هي التجربة المسبقة. نفّذ استعادة كاملة على الخادم الهدف قبل الموعد الحقيقي بأيام، واحتفظ بقائمة مكتوبة بكل إصلاح اضطررت إليه. هذه القائمة هي دليل التنفيذ يوم التحويل، وهي التقدير الوحيد الموثوق لطول النافذة الزمنية التي تحتاجها فعلاً.
في اليوم نفسه يهم الترتيب: أغلق وصول المستخدمين إلى المصدر، خذ النسخة النهائية لقاعدة البيانات ومخزن الملفات، استعِد، طبّق قائمة الإصلاحات، حوّل الـ DNS، ثم افتح النظام للناس. وخفّض قيمة TTL في سجلات DNS قبل يوم كامل حتى ينتشر التحويل خلال دقائق بدل ساعات.
بعدها اختبر النظام بحساب مستخدم عادي لا بحساب مدير: سجّل الدخول، افتح ملف PDF لفاتورة قديمة، سجّل قيداً محاسبياً، أرسل رسالة صادرة واحدة، شغّل تكاملاً واحداً من البداية إلى النهاية، وتأكد أن مهمة مجدولة قد نُفذت بعد التحويل. واحتفظ بالنظام القديم قائماً لكن مجمداً لأسبوع أو أسبوعين. حذفه في المساء نفسه يلغي خيار التراجع الوحيد لديك.
ما الذي تغيّره الاستضافة المُدارة
المنصة المُدارة تختصر بعض هذه الخطوات ولا تلغي أياً من القرارات. Plemo، منصة الاستضافة المُدارة لدينا، تتكفل بجدول النسخ الاحتياطي والاستعادة إلى نقطة زمنية محددة وببيئة الاختبار، وهو ما يجعل الاستعادة التجريبية عملية روتينية بدل أن تكون مشروعاً قائماً بذاته. أما إعادة توجيه التكاملات وتحديث سجل SPF وتجميد المهام المجدولة على المصدر، فتبقى قرارات يتخذها شخص عن قصد ويتحقق منها.
وإذا كان النظام الذي تنقله حساساً لعملك ولا ترغب في تحمّل دليل التنفيذ بنفسك، فهذا بالضبط دور اتفاقية الدعم المستمر: راجع صفحة الدعم المُدار واتفاقيات مستوى الخدمة لمعرفة كيف تُبنى هذه العلاقة.