خطة التراجع: ايش تسوي لو النقل فشل

لماذا تحتاج خطة تراجع؟

كل ترحيل يحمل احتمال فشل. مهما خططت واختبرت، قد تظهر مشكلة لم تتوقعها. خطة التراجع (Rollback Plan) هي شبكة الأمان التي تضمن إنك تقدر ترجع لوضعك السابق خلال دقائق بدلاً من ساعات من التخبط والمحاولة.

الفرق بين مهندس محترف ومبتدئ: المحترف يخطط للفشل قبل ما يبدأ. هذا الدليل يشرح كيف تبني خطة تراجع محكمة لكل سيناريو.

مبادئ خطة التراجع

1. حدد معايير التراجع مسبقاً

لا تنتظر حتى تكون في وسط الأزمة لتقرر. قبل الترحيل، حدد بالضبط متى ترجع:

المعيار	الحد	القرار
التطبيق لا يستجيب	أكثر من 5 دقائق	تراجع فوري
أخطاء 500 متكررة	أكثر من 10 في الدقيقة	تراجع فوري
بيانات مفقودة أو تالفة	أي كمية	تراجع فوري
بطء ملحوظ	أبطأ 3 مرات من السابق	تحقيق ثم قرار
بوابة الدفع لا تعمل	أي فشل	تراجع فوري
البريد لا يُرسل	أكثر من 30 دقيقة	تحقيق ثم قرار

2. حدد نافذة التراجع

نافذة التراجع هي المدة التي يمكنك فيها الرجوع بسهولة. بعد هذه المدة، الرجوع يصبح أصعب أو مستحيلاً:

• أول ساعة: تراجع سهل — DNS ما انتشر كاملاً، البيانات متطابقة تقريباً
• 1-24 ساعة: تراجع ممكن — لكن قد تفقد بيانات جديدة أُدخلت على السيرفر الجديد
• بعد 24 ساعة: تراجع صعب — البيانات تباعدت بين السيرفرين
• بعد 72 ساعة: تراجع شبه مستحيل بدون فقدان بيانات

3. وثّق كل خطوة

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

بناء خطة التراجع: خطوة بخطوة

الخطوة 1: النسخ الاحتياطي الكامل قبل الترحيل

1. نسخة كاملة من قاعدة البيانات مع التاريخ والوقت
2. نسخة كاملة من ملفات التطبيق وملفات المستخدمين
3. نسخة من إعدادات السيرفر (Nginx, PHP, MySQL configs)
4. نسخة من سجلات DNS الحالية
5. نسخة من Cron Jobs والمهام المجدولة
6. تخزين كل هذا في مكان ثالث (ليس السيرفر القديم أو الجديد)

الخطوة 2: إبقاء السيرفر القديم جاهزاً

لا تلمس السيرفر القديم بعد الترحيل. لا تحذف شيء، لا توقف شيء. أبقِه يعمل كما هو لمدة 72 ساعة على الأقل. هذا هو خط الرجعة الأول والأسرع.

• التطبيق يعمل ويستقبل الطلبات
• قاعدة البيانات تعمل ومحدّثة حتى لحظة التحويل
• شهادة SSL ما زالت صالحة
• الـ IP القديم ما زال محجوزاً لك

الخطوة 3: التراجع السريع عبر DNS

أبسط طريقة للتراجع: أرجع سجل DNS للـ IP القديم. لو خفّضت TTL مسبقاً إلى 300 ثانية، المستخدمون يرجعون للسيرفر القديم خلال 5 دقائق.

الخطوة 4: التعامل مع البيانات الجديدة

المشكلة الأكبر: بعد التحويل، المستخدمون أدخلوا بيانات جديدة على السيرفر الجديد. لو رجعت للقديم، هذه البيانات تُفقد. الحلول:

• النسخ المتماثل العكسي: فعّل Replication من الجديد إلى القديم أيضاً (Dual-Write)
• تصدير البيانات الجديدة: صدّر فقط السجلات التي أُنشئت بعد التحويل وأدخلها يدوياً
• قبول الفقدان: في بعض الحالات، فقدان بيانات ساعة واحدة أقل ضرراً من استمرار الخلل

سيناريوهات التراجع

سيناريو 1: التطبيق لا يعمل

1. أرجع DNS للـ IP القديم فوراً
2. تحقق من إن السيرفر القديم يستجيب
3. حلل سبب الفشل في السيرفر الجديد
4. أصلح المشكلة وحاول مرة أخرى لاحقاً

سيناريو 2: أداء سيء

1. راقب لمدة 30 دقيقة — قد يكون تأثير الـ cache البارد
2. لو استمر البطء: تحقق من إعدادات قاعدة البيانات ومحرك الويب
3. لو لم يتحسن: أرجع DNS وحلل المشكلة

سيناريو 3: بيانات تالفة

1. أوقف التطبيق على السيرفر الجديد فوراً (امنع مزيد من الكتابة)
2. أرجع DNS للسيرفر القديم
3. حلل مصدر التلف
4. استعد من النسخة الاحتياطية المؤكدة

اختبار خطة التراجع

خطة تراجع لم تُختبر هي مجرد أمنيات. قبل الترحيل الفعلي:

• نفّذ تمرين تراجع وهمي: حوّل DNS وأرجعه وقِس الوقت
• تأكد إن النسخ الاحتياطية قابلة للاستعادة فعلاً
• تأكد إن كل فرد في الفريق يعرف دوره
• حدد قناة تواصل للطوارئ

قالب خطة التراجع

هذا قالب جاهز تقدر تنسخه وتعدّله حسب نظامك:

البند	التفاصيل
تاريخ الترحيل المخطط	[التاريخ والوقت]
نافذة التراجع	[مثلاً: أول 24 ساعة]
IP السيرفر القديم	[عنوان IP]
IP السيرفر الجديد	[عنوان IP]
مكان النسخ الاحتياطية	[مسار/سيرفر ثالث]
مسؤول التنفيذ	[اسم المطور]
مسؤول القرار	[اسم المدير]
قناة الطوارئ	[WhatsApp/Slack/هاتف]

خطوات التراجع (نفّذها بالترتيب)

1. أوقف التطبيق على السيرفر الجديد: sudo systemctl stop nginx
2. صدّر البيانات الجديدة إن أمكن: mysqldump --where="created_at > 'YYYY-MM-DD HH:MM:SS'" db > new_data.sql
3. أرجع سجل DNS A إلى عنوان IP القديم
4. تأكد من إن السيرفر القديم يستقبل حركة المرور: راقب access.log
5. أرسل إشعار للفريق إن التراجع تم بنجاح
6. حلل سبب الفشل وخطط لمحاولة ثانية

خطة التراجع على كلاود

كلاود (cloud.net.sa) يوفر جلسات توجيه تقني مجانية لمطوّري العملاء تشمل مراجعة خطة التراجع قبل أي ترحيل. نساعدك في تحديد معايير التراجع المناسبة لنظامك ونتأكد إن لديك شبكة أمان محكمة قبل البدء.

لا تبدأ أي ترحيل بدون خطة تراجع مكتوبة ومختبرة. الدقائق التي تقضيها في التخطيط توفر عليك ساعات من الضغط والفوضى.

--- ### ابدأ الآن تبي تجرب بنفسك؟ اختر باقة الاستضافة المناسبة أو صمم سيرفرك الخاص بالمواصفات اللي تبيها.