تظهر عبارة «نقل مجاني» على صفحة كل مزوّد استضافة في الكويت تقريباً، ولا يصف أيٌّ منهم تقريباً ما يتضمّنه. وهذا مهمّ، لأن الفرق بين نقل لا يلاحظه أحد ونقل يُخرج الموقع من الخدمة نصف يوم ليس مهارة ولا أدوات. بل ترتيب أربع خطوات، على إحداها أن تحدث بأيام قبل أن يتحرّك أي شيء ظاهر. وهذا هو التسلسل، وسبب وقوع كل خطوة في موضعها.
لماذا يتوقّف الموقع أثناء النقل بين الاستضافات؟
لأن تغييرات DNS لا تصبح فعّالة في كل مكان في وقت واحد. فحين تُوجّهون نطاقاً إلى خادم جديد، تواصل المُحلِّلات حول العالم تقديم العنوان القديم حتى تنتهي صلاحية نسختها المخزّنة. ومدة تخزينها يحدّدها TTL الخاص بالسجل — مدة البقاء — والافتراض المعتاد 4 أو 12 أو 24 ساعة.
فأثناء الانتشار يصل بعض الزوار إلى الخادم الجديد وبعضهم إلى القديم، ولا سبيل للتحكّم بمن. وإن كان الموقع القديم قد أُوقف أو نُقلت قاعدة بياناته، فكل من لا يزال يُحلَّل إليه يحصل على خطأ. هذا هو التوقّف، وسببه ليس التحويل نفسه بل مدة التخزين المؤقت التي ضُبطت قبل ذلك بزمن طويل.
تخفيض TTL هو الخطوة الوحيدة التي يجب أن تحدث بأيام مسبقاً، وهي التي تحدّد هل يكون التحويل غير مرئي.
ما الترتيب الصحيح لنقل موقع؟
- 1
خفّضوا TTL في DNS، بأيام مسبقاً
أنزلوه إلى خمس دقائق. والتغيير نفسه يستغرق مدة TTL القديمة كاملةً ليبلغ كل مُحلِّل، وهذا بالضبط سبب تعذّر القيام به يوم التحويل. افعلوا ذلك قبل أي شيء آخر، وقبل بناء الخادم الجديد.
- 2
خذوا نسخة احتياطية كاملة، وتحقّقوا من أنها تُفتح
الملفات وقاعدة البيانات، قبل أن يتحرّك أي شيء. والنسخة التي لم يفتحها أحد افتراض؛ واسترجاعها في مكان ما هو ما يحوّلها إلى حقيقة.
- 3
ابنوا الخادم الجديد بالتوازي واختبروه على رابط مؤقت
الموقع القديم يستمر بخدمة الزوار طوال المدة. فلا شيء خارج الخدمة أثناء أكبر مرحلة من العمل، لأن البيئة الجديدة تُثبَت قبل أن تستقبل أي زيارات حقيقية.
- 4
حوّلوا DNS، بعد التحقّق من البيئة الجديدة
بـTTL خمس دقائق يكون الانتشار دقائق لا يوماً. والخادمان يجيبان بشكل صحيح للموقع نفسه، فالزائر الذي يُصادف منتصف الانتشار يُخدَم في الحالتين.
- 5
أبقوا الاستضافة القديمة عاملة من 48 إلى 72 ساعة
لا تُلغوا الخطة القديمة يوم التحويل. فهي خطة التراجع، وإبقاؤها يكلّف شهر استضافة واحداً.
وإعادة الترتيب المهمّة هي الخطوة الأولى. فأغلب أدلة النقل تذكر TTL في موضع ما من قسم التحويل، وهذا متأخّر جداً ليكون مفيداً — إذ تكون القيمة القديمة قد خُزّنت في كل مكان.
ماذا ينبغي أن تتحقّقوا منه قبل تحويل DNS؟
كل ما أدناه قابل للتحقّق على الرابط المؤقت، في حين يبقى الموقع الحيّ دون مساس. والعطل الذي يُكتشَف هنا لا يكلّف شيئاً.
- الموقع يُحمَّل، وكذلك الصفحات التي ليست الصفحة الرئيسية
- النماذج تُرسَل، والإرسالات تصل إلى مكان ترونه
- اتصال قاعدة البيانات يعمل تحت أكثر من طلب واحد
- رفع الملفات يكتب في مجلّد يستطيع الخادم الجديد الوصول إليه فعلاً
- المهام المجدولة وcron موجودة على الخادم الجديد — وهي البند الأكثر نسياناً
- إرسال البريد يعمل، وسجلات SPF تسمّي الخادم الجديد إن كان يُرسل مباشرةً
- شهادة SSL صادرة وصالحة للنطاق الحقيقي، لا للمؤقت فقط
- التحويلات وقواعد إعادة الكتابة انتقلت سليمة
واثنان من هذه يستحقان التأكيد. فمهام cron تعيش خارج الملفات وقاعدة البيانات، فنسخ الملفات وقاعدة البيانات يتركها كلها، ولا يبدو شيء خاطئاً حتى يتخلّف تقرير ليلي عن الوصول. وشهادة SSL الصادرة للرابط المؤقت ليست شهادة للنطاق، فيجب إعادة إصدارها بعد التحويل أو طلبها مسبقاً بوسيلة أخرى.
متى يكون نقل الاستضافة هو الإصلاح الخاطئ؟
كثيراً. فالموقع البطيء ليس خادماً بطيئاً عادةً، ونقله إلى خادم أسرع طريقة مكلفة لمعرفة ذلك. وقبل النقل يستحق الأمر تحديد ما هو البطيء فعلاً — فاستعلام قاعدة بيانات غير مُحسَّن، أو مجموعة صور مفرطة الحجم، أو إضافة تعمل في كل تحميل صفحة، كلها ستتبع الموقع إلى بيته الجديد.
والإشارات الحقيقية لتجاوز الاستضافة المشتركة أكثر تحديداً: أخطاء 503 متكرّرة، وأزمنة تحميل ترتفع مع ارتفاع الزيارات لا تبقى ثابتة، وزيارات تتجاوز نحو 25,000 زائر شهرياً. وهناك أيضاً أثر الجار المزدحم، حيث يرتفع نشاط موقع آخر على الخادم المشترك نفسه أو يسيء استعلاماً فيتباطأ موقعكم دون أن يتغيّر شيء من جانبكم — وهذا حقيقي، وهو أكثر سبب صادق شائع للنقل.
أغلب المواقع على الاستضافة المشتركة لا تحتاج خادماً افتراضياً بعد. فإن كانت أزمنة التحميل ثابتة لا ترتفع مع الزيارات، فالمشكلة في الموقع والنقل سينقلها كما هي.