استراتيجيات النشر

الموضوعات السابقة بنت البنية التحتية من الصفر. وهذا الموضوع يجيب عن سؤال أصعب: كيف تغيّر شيئاً يخدم مستخدمين الآن. النسخة الجديدة قد تكون معطوبة، وأنت لا تعرف ذلك قبل شحنها، فكل استراتيجية هنا مجرّد إجابة عن سؤالين: كم شخصاً يقابل الخلل قبل أن تنتبه، وكم يلزمك كي تتراجع.

ما الذي يغطّيه هذا الموضوع

• السؤالان اللذان يولّدان كل استراتيجية نشر: أتغيّر الخوادم التي لديك أم تبني جديدة، وكم من الحركة يصل النسخة الجديدة دفعة واحدة
• all at once وrolling وimmutable وblue/green وcanary وlinear، وما يكلّفه كل منها من سعة ووقت ومستخدمين متضرّرين
• حساب السعة الباقية أثناء نشر rolling، والنافذة التي تعمل فيها نسختان معاً وما تفسده
• الحدّ الفاصل بين blue/green وcanary: مفتاح يحوّل الحركة كلها مقابل مؤشّر يحوّل نسبة مقيسة
• قيود قاعدة البيانات والجلسات التي تجعل التراجع الفوري وعداً غير حقيقي، وكيف تُشحن تغييرات الـ schema بأمان
• instance refresh في Auto Scaling: MinHealthyPercentage وMaxHealthyPercentage وcheckpoints وskip matching وشروط إلغاء التراجع
• سياسات تحديث CloudFormation الثلاث لمجموعة Auto Scaling، وقيمها الافتراضية الحادّة
• نشر ECS: حساب minimumHealthyPercent وmaximumPercent، وقاطع دائرة النشر وعتباته، وblue/green وcanary مع bake time وlifecycle hooks
• aliases Lambda الموزونة، ونشر blue/green المُدار في RDS وما يحدث للبيئة القديمة

لماذا هذا مهم

المهارة 3.1.5 في دليل اختبار SOA-C03 تسمّي استراتيجيات النشر مباشرةً، والأسئلة عنها نادراً ما تطلب تعريفاً. هي تعطيك قيوداً (لا انقطاع، ولا ميزانية إضافية، وتراجع يُقاس بالثواني) وتطلب الاستراتيجية التي تصمد تحتها، أو تصف نشراً عالقاً وتطلب السبب. والإجابة تأتي من الأرقام: نسبة تُقرَّب صعوداً، أو حدّ أدنى تحت 100، أو عتبة فشل لم تُبلَغ بعد.

وضغط العمل اليومي هو نفسه. لا تفشل معظم عمليات النشر لأن الفريق اختار الاستراتيجية الخاطئة، بل لأن الإعدادات سمحت بشيء لم يقصده أحد: مجموعة أُفرغت بقيمة افتراضية صفر، أو نشر ECS جلس ساعة لأن الأرضية والسقف تساويا، أو تحويل blue/green لم يعد ممكناً عكسه بعد migration واحد.