قائمة التحقق للانتقال إلى السحابة
- الرئيسية
- قوائم التحقق
- الانتقال إلى السحابة
هذه القائمة موجّهة للشركات التي تنقل مواقعها وأنظمتها من استضافة مشتركة، أو سيرفرات محلية داخل الشركة، أو VPS قديم، إلى بنية سحابية حديثة. «الانتقال إلى السحابة» لا يعني نسخ الملفات ثم تغيير DNS؛ بل يشمل قواعد البيانات، والبريد الإلكتروني، ومهام Cron، والتكاملات مع الأنظمة الخارجية، والمراقبة، وخطة تراجع مكتوبة إن ساءت الأمور ليلة التحويل. جمعنا هنا 72 بندًا عمليًا من واقع انتقالات نفّذناها فعلًا خلال أكثر من 12 سنة — بلغة مهندسي أنظمة، لا لغة تسويق.
ضع علامة على كل بند تُنجزه — تقدّمك يُحفظ تلقائيًا في متصفحك، ويمكنك طباعة القائمة أو تنزيلها كملف DOCX لمشاركتها مع فريقك.
1 التقييم والجرد 0/8
2 التخطيط والهندسة 0/9
3 الأمان والامتثال 0/8
4 تنفيذ الانتقال 0/8
5 الاختبار والتحويل النهائي 0/8
6 التحسين بعد الانتقال 0/7
7 قائمة نقل قواعد البيانات (تعمّق) 0/8
8 قائمة اختبارات ما قبل التحويل 0/8
9 قائمة التطبيق والـ CDN ليلة التحويل 0/8
أشهر 5 أسباب لفشل الانتقال — نُستدعى لإصلاحها باستمرار
- مفاجآت TTL في سجلات DNS. يتم التحويل بينما قيمة TTL ما زالت 86400 ثانية، فيظل جزء من الزوار على السيرفر القديم يومًا كاملًا — وفي المتاجر يعني ذلك طلبات مقسومة على قاعدتي بيانات لا يمكن دمجهما بسهولة. الحل بسيط ومجاني: خفض TTL قبل التحويل بيوم أو يومين، لكنه يُنسى في أغلب الانتقالات الذاتية التي نراها.
- مهام Cron المنسية. الموقع يعمل بعد النقل بشكل ممتاز، والجميع يحتفل — ثم بعد أسبوع يتضح أن الفواتير لم تُرسل، والنسخ الاحتياطية لم تعمل، والتقارير المجدولة توقفت بصمت. المهام المجدولة لا تظهر في أي «اختبار تصفح» للموقع؛ لا بد من جردها ونقلها بندًا بندًا.
- انكسار البريد الإلكتروني. تُنقل سجلات A ويُنسى بقية الملف: MX أو SPF أو DKIM، فيتحول بريد الشركة إلى Spam أو يتوقف تمامًا — وأحيانًا لا يُكتشف ذلك إلا حين يسأل عميل: «لماذا لا تردّون على رسائلنا؟».
- نسخ احتياطية لم تُختبر. الجميع «لديه نسخ احتياطية» حتى لحظة الاستعادة الأولى: أرشيف تالف، أو قاعدة بيانات ناقصة جداول، أو نسخة تحفظ فوق نفسها منذ شهور. النسخة التي لم تُستعد فعلًا في تجربة حقيقية لا قيمة لها.
- لا أحد يملك قرار التراجع. تظهر مشكلة جدّية في الثانية صباحًا، ولا أحد يعرف من يقرر العودة للبيئة القديمة ولا ما خطواتها، فيستمر العطل ساعات بينما الفريق «يحاول الإصلاح للأمام». خطة التراجع المكتوبة — بنقطة قرار ومسؤول واحد باسمه — هي الفرق بين حادثة دقائق وليلة كاملة.
الانتقال الذاتي أم الانتقال المُدار؟ مقارنة صريحة
متى يكون الانتقال الذاتي منطقيًا؟
- موقع صغير أو شبه ثابت بلا عمليات شراء أو تكاملات.
- ووردبريس قياسي بإضافات شائعة فقط.
- لديك مهندس أنظمة داخلي يملك وقتًا فعليًا للمهمة.
- تتحمل نافذة توقف مجدولة دون خسارة تُذكر.
متى تحتاج انتقالًا مُدارًا؟
- الموقع مصدر دخل مباشر ولا يحتمل التوقف.
- قواعد بيانات كبيرة وطوابير وworkers ومهام مجدولة.
- البريد الإلكتروني على السيرفر نفسه.
- متطلبات امتثال أو إقامة بيانات.
- لا يوجد فريق تشغيل داخلي يتفرغ للمتابعة بعد التحويل.
الانتقال الذاتي يوفّر تكلفة الخدمة لكنه ينقل كل المخاطرة إليك — والبنود الأربعون في هذه القائمة موجودة لأن كل واحد منها أفشل انتقالًا حقيقيًا عند من تجاهله. نحن ننفّذ انتقالات مُدارة بنهج يقارب صفر توقف (مزامنة أولية ثم مزامنة فرق، مع خفض TTL مسبقًا) وبـخطة تراجع مكتوبة يوقّع عليها الطرفان قبل ليلة التحويل — ثم نتولى إدارة السيرفرات والمراقبة بعد الانتقال إن رغبت.
أسئلة شائعة عن الانتقال إلى السحابة
كم يستغرق الانتقال إلى السحابة؟
يعتمد على الحجم والتعقيد: موقع صغير يُنقل خلال ساعات إلى يوم، وموقع أعمال نموذجي خلال 3–7 أيام شاملة الاختبار، أما المنصات المعقدة (قواعد بيانات كبيرة، طوابير، تكاملات) فتحتاج عادة من أسبوع إلى ثلاثة أسابيع عمل.
هل التوقف حتمي أثناء الانتقال؟
لا. بخفض TTL مسبقًا، ومزامنة أولية للبيانات ثم مزامنة فرق صغيرة ليلة التحويل، يقترب التوقف من الصفر. قد نحتاج أحيانًا نافذة قصيرة تكون فيها قاعدة البيانات للقراءة فقط لدقائق — تُجدول في أقل أوقات الزيارات.
كم تكلفة الانتقال المُدار؟
استرشاديًا: الموقع الصغير يحتاج ساعات عمل محدودة، بينما المنصات المعقدة تحتاج من أسبوع إلى ثلاثة أسابيع عمل. أرسل تفاصيلك عبر صفحة التواصل أو اطّلع على خدمة إدارة السيرفرات — والعرض المكتوب الدقيق مجاني خلال 24 ساعة.
أي مزوّد سحابة هو الأفضل؟
بصراحة: لا توجد إجابة واحدة. يعتمد الاختيار على طبيعة الحمل والميزانية ومكان مستخدميك ومتطلبات إقامة البيانات. نعمل ضمن بيئات AWS وGoogle Cloud وHetzner وOVH، ونرشّح الأنسب لحالتك لا الأغلى.
هل سيتعطل بريدي الإلكتروني بعد النقل؟
لن يتعطل إذا جُردت سجلات MX وSPF وDKIM وDMARC ونُقلت بدقة قبل تحويل DNS — ولهذا خصصنا لها بندًا كاملًا في القائمة. انكسار البريد يحدث فقط حين تُنسى هذه السجلات.
هل تقدمون دعمًا بعد الانتقال؟
نعم. نوفّر مراقبة وإدارة مستمرة للسيرفرات بعد الانتقال — تحديثات، نسخ احتياطي مُختبر، تأمين، ومتابعة أداء — ضمن خدمة إدارة السيرفرات.
هل يمكن نقل قاعدة البيانات إلى السحابة بدون توقف؟
قريب جدًا من الصفر، نعم. النمط المعتاد: انسخ القاعدة نسخًا كاملًا أولًا، ثم أبقها متزامنة عبر النسخ المتزامن أو مزامنة الفروقات، ثم خذ نافذة قراءة-فقط لدقائق معدودة في أهدأ ساعاتك للمزامنة الأخيرة قبل تحويل التطبيق. قسم «نقل قواعد البيانات» أعلاه يغطي كل خطوة.
كيف أختبر الانتقال إلى السحابة قبل الإطلاق الفعلي؟
أربع طبقات: قائمة مكتوبة لاختبارات المسارات الحرجة، ومقارنة زحف لأهم الصفحات بين البيئتين، واختبار تحميل حتى ذروة زياراتك الحقيقية، وبروفة تراجع واحدة مُوقّتة. إن نجحت الأربعة، تمر ليلة التحويل بهدوء ممل — وهذا هو الهدف.
جاهز للانتقال إلى السحابة دون مفاجآت؟
ننفّذ انتقالات مُدارة بنهج يقارب صفر توقف وخطة تراجع مكتوبة — والعرض المكتوب الدقيق مجاني خلال 24 ساعة.
احصل على نسخة DOCX + عرض انتقال مُدار
أرسل بياناتك وسيبدأ تنزيل القائمة فورًا — ويصلك عرض مكتوب دقيق مجانًا خلال 24 ساعة.
أو حمّل نسخة DOCX مباشرة من هنا دون تسجيل.
