تحدد خطة الرجوع عن النشر آخر نسخة متوافقة من التطبيق، وشروط استخدامها، والمسؤول أو القاعدة التي تتخذ القرار، والفحوص التي تؤكد استعادة التشغيل. ويجب أن تراعي تغييرات البيانات والمهام المنتظرة والإجراءات الخارجية. الاحتفاظ ببناء الأمس مفيد، لكنه لا يثبت أن شفرة الأمس تستطيع العمل بأمان مع حالة النظام اليوم.
اكتب الخطة للإصدار الذي تراجعه. عبارة عامة مثل «ارجع إذا ظهرت مشكلة» تؤجل أصعب القرارات إلى وقت تقل فيه المعلومات المتاحة للفريق. ابدأ من سجل إصدار CI/CD، ثم أضف أدلة الاستعادة لهذا التغيير. يجب أن تبين الخطة ما تعرفه وما يحتاج اختباراً، لا أن تخفي الفجوات وراء اسم أداة.
يعيد الرجوع بالتطبيق الشفرة المشغلة أو الإعداد إلى حالة سابقة متوافقة. وقد يتجنب تعطيل ميزة المسار المعطوب مع إبقاء النسخة الجديدة. أما الإصلاح اللاحق فيضيف تغييراً آخر، وتعيد استعادة البيانات المعلومات إلى نقطة مدعومة وتفتح عملاً مستقلاً للمطابقة. لهذه الخيارات متطلبات وآثار مختلفة حتى لو استُخدمت لمعالجة الحادث نفسه.
اختر الإجراء بحسب الفشل والحالة الحالية. تغيير معطوب في عرض الشاشة وترحيل يحذف بيانات يحتاجان استجابتين مختلفتين. لا تجعل استعادة قاعدة البيانات كلها الاستجابة الافتراضية لكل شاشة فاشلة، لأنها قد تؤثر في نشاط صحيح نفذه المستخدمون بعد نقطة الاستعادة. وضح من يقرر هذا الأثر وكيف يتعامل معه الفريق.
يربط دليل Azure للنشر الآمن حالة الإطلاق بقرارات الاستعادة. طبق المبدأ على رحلة مستخدم وإشارة يمكن التصرف بناء عليها. حدد ما تثبته الإشارة، وكيف تعالج غياب الملاحظات، ومن يفحص النتائج الملتبسة قبل بدء إجراء قد يزيد الضرر. إنذار غامض لا يحدد وحده الإجراء الصحيح.
اجعل سجل القرار مختصراً بما يكفي لاستخدامه وقت الفشل، مع روابط للإجراءات التفصيلية. احفظه في مكان يستطيع الفريق المخوّل الوصول إليه إذا تعطلت منصة النشر. أشر إلى بيانات الاعتماد عبر مسار الوصول المعتمد بدلاً من كتابة الأسرار في المستند، وتحقق من صلاحية المسار قبل وقت الحاجة إليه.
يمكن لورقة العمل الأصلية التالية أن ترافق الإصدار. أكمل عمود الأدلة قبل اعتبار خيار الاستعادة جاهزاً. تسمية مسؤول لا يملك الوصول، أو الإشارة إلى نسخة احتياطية لم يستعدها أحد، تعني بقاء اعتمادية غير محسومة. اكتب هذه الفجوة بوضوح وحدد من يعالجها بدلاً من إخفائها داخل عبارة «الخطة جاهزة».
| البند | السؤال المطلوب حسمه | الدليل الذي تحتفظ به |
|---|---|---|
| هوية الإصدار | ما الشفرة والإعداد المشغلان؟ | المراجعات ومعرّفات الحزم والبيئة المستهدفة |
| محفز الاستعادة | أي فشل يبرر هذا الإجراء؟ | شرط رحلة المستخدم والإشارة وقاعدة الملاحظة والاستثناءات |
| سلطة القرار | من يبدأ الاستعادة أو يوقفها أو يصعّدها؟ | المسؤول وبديله ومسار الاتصال |
| النسخة المتوافقة | أي نسخة تستطيع استخدام الحالة الحالية؟ | نتائج توافق التطبيق والمخطط والرسائل |
| حدود البيانات | ما الذي تغير منذ نشر النسخة؟ | حالة الترحيل والكتابات الجديدة ونقاط الاستعادة المدعومة |
| الآثار الخارجية | ماذا حدث خارج التطبيق؟ | مراجع المعاملات والرسائل ومسؤول المطابقة |
| الإجراء والوصول | هل يستطيع المسؤول تنفيذ العملية؟ | دليل تشغيل بإصدار معلوم وصلاحيات وسجل تجربة |
| القبول | ما الذي يثبت عودة التشغيل المفيد؟ | رحلات المستخدم وفحوص السجلات والإشارات ذات الصلة |
| التواصل | من يحتاج تحديثاً ومتابعة؟ | المستلمون ومسؤول أثر المستخدم وسجل الحادث |
أضف تسلسل إيقاف التوسع في النشر والتحكم في العمل الذي قد يزيد المشكلة. يعتمد قرار إيقاف الكتابة أو العمال الخلفيين على التطبيق والحادث؛ اجعله صريحاً. لا ينبغي أن يكتشف المسؤول أثناء الاستعادة أن مساراً ثانياً ينشر نسخة أخرى بالتزامن، أو أن مهمة دورية تواصل تعديل السجلات محل التحقيق.
لنفترض تطبيقاً افتراضياً لتذاكر الدعم، تفهم نسخته الأولى A الحالتين open وclosed. تضيف ميزة مقترحة حالة awaiting_customer. إذا بدأت النسخة الجديدة بكتابتها قبل قدرة جميع الجهات المعنية بقراءة السجل على التعامل معها، فقد تفشل شاشة قديمة أو مهمة خلفية أو عملية تصدير عند مواجهتها، رغم نجاح تشغيل التطبيق نفسه.
يفصل المثال الأصلي التالي التهيئة عن التفعيل. نفترض أن B تتعامل مع الحالة الجديدة بصورة صحيحة في القراءة وإجراءات المستخدم، وتحافظ على القيم الموجودة، لكنها تستمر في إنشاء الحالات الأصلية فقط. هذا نموذج توافق ينبغي اختباره على التطبيق الفعلي، وليس وصفة ترحيل قابلة للتنفيذ دون معرفة بنية البيانات والسلوك.
| النسخة | القراءة والسلوك | القيم الجديدة التي تنشئها | حدود الرجوع |
|---|---|---|---|
| A: الأصلية | تفهم open وclosed فقط | الحالات الأصلية | لا تتعامل مع سجلات تستخدم awaiting_customer |
| B: المهيأة | تتعامل مع الحالات الأصلية والجديدة بصورة صحيحة | الحالات الأصلية مع الحفاظ على القيم الجديدة الموجودة | تتطلب العودة إلى A التأكد من غياب أي حالة غير متوافقة |
| C: المفعلة | تتعامل مع الحالات الأصلية والجديدة بصورة صحيحة | يمكنها أيضاً إنشاء awaiting_customer | B مسار عودة مرشح؛ A غير متوافقة بعد وجود القيم الجديدة |
قبل تفعيل C، تحقق من امتلاك كل جهة تقرأ البيانات السلوك المطلوب، بما فيها العمال الخلفيون والتصدير الدوري ومستهلكو الرسائل المحتفظ بها. اكتمال جزء من نشر التهيئة لا يكفي. يشرح مقال AWS عن سلامة الرجوع هذا الفصل بين التهيئة والتفعيل وخطر تغييرات البروتوكول غير المتوافقة بين النسخ.
بعد أن تكتب C القيمة الجديدة، قد تحافظ العودة إلى B على قدرة قراءة متوافقة. لا يجوز افتراض سلامة العودة مباشرة إلى A. إيقاف مفتاح الميزة لا يمحو قيماً خُزنت بالفعل أو رسائل دخلت الطابور. تحقق من الحالة الفعلية، واحتفظ بالنسخة المهيأة طوال مدة الاستعادة المتفق عليها.
تضيف تغييرات قواعد البيانات قيوداً أخرى مثل أقفال المخطط، وسلوك التطبيق، واكتمال الترحيل، وإمكان عكس تحويل البيانات. يوصي دليل AWS لتغييرات المخطط بمعالجة التوافق بين النسخ القديمة والجديدة. وجود أمر باسم «ترحيل عكسي» لا يثبت أنه يحافظ على كل سجل مهم أو يعيد معنى البيانات الذي تغير.
لا تسترجع إعادة نسخة التطبيق بريداً أُرسل، ولا تلغي شحنة مكتملة أو تعكس دفعة في نظام آخر. سجل هذه الآثار منفصلة وعيّن مسؤولاً عن مطابقتها. يحتاج أي إجراء تعويضي في العمل إلى التفويض المناسب والطريقة التي يدعمها المزود؛ فتصحيح حالة محلية لا يغير تلقائياً واقع المعاملة الخارجية.
تعامل مع إعادة المحاولة بحذر. قد ينتهي وقت انتظار الطلب دون معرفة إن كان الإجراء الخارجي قد اكتمل، وإعادته عشوائياً قد تكرر الأثر. يوضح دليل AWS لإعادة المحاولة وثبات أثر العملية أن الإعادة قد تنفذ العمل أكثر من مرة. أوضاع تنفيذ حزمة SDK المذكورة ليست ضماناً عاماً لمعالجة الأعمال مرة واحدة فقط.
ضمن التجربة، اختبر رسالة أنشأتها النسخة الجديدة ويستهلكها العامل بعد الرجوع. تحقق من توافق محتواها، ومعالجة التكرار، وما يحدث إذا لم يعد السجل يطابق افتراضات العامل. فحص صفحة الويب وحده لن يكشف كل فشل خلفي؛ اربط قبول الاستعادة بالمهام التي يعتمد عليها العمل فعلياً.
تحقق من سلوك الاستعادة وفترة الاحتفاظ والصلاحيات والاعتماديات في منتج قاعدة البيانات الفعلي. مثلاً، تنشئ الاستعادة إلى نقطة زمنية في Azure SQL قاعدة جديدة، ولا تستبدل القاعدة الحالية. لذلك تشمل العملية التحقق من الحالة المستعادة وإعادة ربط التطبيق بالطريقة المدعومة. قد تختلف المنتجات الأخرى، فلا تعمم خطوات هذا المثال عليها.
حدد النشاط الصحيح الذي حدث بعد نقطة الاستعادة المختارة وكيف ستتم مطابقته. افحص أيضاً الملفات وفهارس البحث والطوابير والأنظمة المتصلة التي قد تصف الآن حالة مختلفة. بدء قاعدة البيانات بنجاح لا يعني استعادة مسار العمل بصورة متسقة؛ فقد يعمل الاتصال بينما تبقى معاملات أو ملفات أو رسائل غير متوافقة.
اتفق مع أصحاب العمل على أهداف الاستعادة. يعرف دليل Azure للاستعادة RTO حول الوقت المقبول لإعادة التشغيل، وRPO حول فقدان البيانات المقبول مقاساً بالزمن. هذه أهداف تصمم وتختبر للوصول إليها. كتابتها في مستند لا تنشئ قدرة مقاسة أو ضماناً تعاقدياً، ويجب فصلها عن نتائج التجارب الفعلية.
استخدم بيئة اختبار مضبوطة بنسخ وإعدادات ممثلة وبيانات اختبار مناسبة. جرّب التغيير للأمام، وحالة اختلاط النسخ حيث تنطبق، والاستعادة المخططة بعد حدوث كتابات جديدة. سجل الخطوات الفعلية والمدة ومشكلات الوصول والإشارات المفقودة والاعتماديات غير المحسومة. لا تستبدل التحضير بتجارب مدمرة على الإنتاج، ولا تعتبر اختلاف البيئة تفصيلاً غير مؤثر.
اجعل المسؤول يتحقق من مهمة المستخدم والصلاحيات والمعالجة الخلفية والسجلات المتفق عليها. واصل الملاحظة للمدة المحددة، ثم أغلق الحادث عبر صاحبه المسمّى. حدّث الدليل إذا كشفت التجربة تسلسلاً مختلفاً أو قدرة ناقصة، واحتفظ بسبب التعديل حتى يعرف المسؤول التالي لماذا تغيرت الخطوات ومتى راجعت صلاحيتها.
أحضر الإصدار وتغيير البيانات وطريق العودة المقترح إلى مراجعة DevOps والاستعادة. قد تتضمن خطط الاستضافة والتشغيل أعمال نسخ احتياطي أو استعادة محددة؛ راجعها أولاً. وعندما يتطلب التوافق تغييراً في التطبيق، ضمّن هذا العمل صراحة بدلاً من الوعد بأن أداة النشر وحدها تستطيع معالجة المشكلة بكل اعتمادياتها.
