النشر الأزرق/الأخضر: عندما تحتاج إلى تحويل فوري وتراجع فوري

تخيل هذا المشهد: فريقك أنهى للتو إعادة تصميم كبيرة لصفحة الهبوط الرئيسية. أو ربما استبدلت مكتبة أساسية تمس كل جزء من التطبيق. التغييرات مثل هذه يصعب اختبارها بشكل مثالي في بيئة الاختبار لأن بيانات الاختبار وسلوك المستخدم لا تتطابق أبداً مع بيئة الإنتاج. يمكنك تجربة التحديث التدريجي (rolling update)، ولكن إذا حدث خطأ ما، سيرى نصف المستخدمين النسخة المعطلة بينما لا يزال النصف الآخر يرى النسخة القديمة. وماذا عن التراجع؟ هذا يعني الانتظار حتى تعود كل نسخة فردية إلى حالتها السابقة واحدة تلو الأخرى. ليس فورياً بالتأكيد.

هنا يأتي دور النشر الأزرق/الأخضر (blue/green deployment). إنه يحل مشكلة محددة: كيف تحول جميع المستخدمين إلى إصدار جديد دفعة واحدة، وكيف تعيدهم بنفس السرعة إذا حدث خطأ ما؟

بيئتان متطابقتان، واحدة نشطة في كل مرة

الفكرة واضحة ومباشرة. تحتفظ ببيئتين متطابقتين. سم إحداهما زرقاء (blue) والأخرى خضراء (green). كلاهما يعمل بنفس البنية التحتية، نفس التكوين، ونفس السعة. الاختلاف الوحيد هو أي منهما يخدم المستخدمين حالياً.

دعنا نستعرض كيفية عمل هذا عملياً.

الرسم البياني أدناه يوضح الحالتين والانتقالات بينهما.

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

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

بمجرد أن تصبح واثقاً، تقوم بعملية التحويل (cutover). التحويل يعني تحويل حركة مرور المستخدمين من البيئة الزرقاء إلى الخضراء. قد تقوم بتحديث تكوين موازن التحميل، أو تغيير سجلات DNS، أو تعديل التوجيه في شبكة الخدمات (service mesh). في ثوانٍ، يبدأ جميع المستخدمين في الوصول إلى الإصدار 2. لا يوجد توقف عن العمل لأن البيئة الخضراء كانت تعمل بالفعل مع خوادم دافئة، واتصالات قاعدة بيانات مفتوحة، والتطبيق مهيأ بالكامل.

الميزة القاتلة: التراجع الفوري

أكبر ميزة للنشر الأزرق/الأخضر هي السرعة التي يمكنك بها التراجع. إذا تبين أن الإصدار 2 به مشكلة بعد أن بدأ المستخدمون في استخدامه، فقط قم بتحويل حركة المرور مرة أخرى إلى البيئة الزرقاء. يعود المستخدمون إلى الإصدار 1 فوراً. لا انتظار لإعادة النشر. لا حاجة لتشغيل pipeline مرة أخرى. التراجع هو مجرد تغيير في التوجيه.

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

مقايضة التكلفة

النشر الأزرق/الأخضر له جانب سلبي واضح: التكلفة. تحتاج إلى تشغيل بيئتين كاملتين في نفس الوقت. إذا كان عبء عمل الإنتاج يتطلب 10 خوادم، فإن النشر الأزرق/الأخضر يعني أنك تدير 20 خادماً خلال فترة الانتقال. أنت تدفع مقابل ضعف السعة.

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

متى تستخدم النشر الأزرق/الأخضر

هذه الاستراتيجية تناسب التغييرات حيث تكون المخاطر عالية ويجب أن يكون التراجع فورياً. فكر في:

• إعادة تصميم واجهة المستخدم الرئيسية التي تؤثر على كيفية تفاعل المستخدمين مع منتجك
• استبدال التبعيات أو المكتبات الأساسية
• تغييرات مخطط قاعدة البيانات التي يصعب عكسها
• تحديثات الامتثال أو التنظيم حيث تحتاج إلى تحويل نظيف

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

قائمة تحقق عملية

قبل تنفيذ النشر الأزرق/الأخضر، تأكد من توفر هذه العناصر:

• بيئات متطابقة. يجب أن تعمل كلتا البيئتين بنفس البنية التحتية والتكوين والسعة. الاختلافات بينهما تنفي الغرض.
• تطبيقات عديمة الحالة أو واعية بالجلسة. إذا كان تطبيقك يخزن بيانات الجلسة محلياً، سيفقد المستخدمون جلساتهم أثناء التحويل. استخدم مخازن جلسات خارجية مثل Redis أو صمم لتكون عديمة الحالة.
• تحويل آلي. التحويل اليدوي عرضة للأخطاء. قم بأتمتة تبديل حركة المرور بحيث يستغرق ثوانٍ، وليس دقائق من النقر.
• فحوصات صحة على البيئة الجديدة. لا تقم فقط بالنشر والتحويل. تحقق من أن الإصدار الجديد يجتاز فحوصات الصحة قبل توجيه حركة المرور إليه.
• مراقبة أثناء وبعد التحويل. راقب معدلات الأخطاء، وزمن الاستجابة، والمقاييس التجارية فوراً بعد التبديل. إذا بدا شيء خاطئاً، تراجع بسرعة.

الخلاصة الملموسة

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