توصيات لممارسات النشر الآمنة
ينطبق على توصية قائمة التحقق من التميز التشغيلي في Azure Well-Architected Framework:
OE:11 | حدد بوضوح ممارسات النشر الآمنة لحمل العمل الخاص بك. التأكيد على المثل العليا لأساليب الإصدار الصغيرة والتزايدية وذات البوابات عالية الجودة. استخدم أنماط النشر الحديثة وتقنيات التعرض التدريجي للتحكم في المخاطر. حساب عمليات التوزيع الروتينية وعمليات التوزيع في حالات الطوارئ أو الإصلاح العاجل. |
---|
يصف هذا الدليل توصيات استخدام ممارسات النشر الآمنة (SDP). تحدد عمليات وإجراءات التوزيع الآمنة كيفية إجراء التغييرات ونشرها بأمان على حمل العمل الخاص بك. يتطلب منك تنفيذ SDP التفكير في عمليات التوزيع من خلال عدسة إدارة المخاطر. يمكنك تقليل مخاطر الخطأ البشري في عمليات التوزيع الخاصة بك والحد من تأثيرات عمليات التوزيع الإشكالية على المستخدمين عن طريق تنفيذ SDP.
استراتيجيات التصميم الرئيسية
هناك أربعة إرشادات مهمة يجب وضعها في الاعتبار عند تنفيذ ممارسات التوزيع الآمنة:
السلامة والاتساق: جميع التغييرات التي تطرأ على حمل عمل الإنتاج محفوفة بالمخاطر بطبيعتها ويجب إجراؤها مع التركيز على السلامة والاتساق.
التعرض التدريجي: يمكنك تقليل نصف قطر الانفجار المحتمل للمشكلات الناجمة عن التوزيع عن طريق اعتماد نموذج توزيع التعرض التدريجي.
النماذج الصحية: يجب أن تمر عمليات التوزيع بالفحوصات الصحية قبل أن تبدأ كل مرحلة من مراحل التعرض التدريجي.
الكشف عن المشكلات: عند الكشف عن المشكلات، يجب إيقاف النشر على الفور وبدء الاسترداد.
وتقدم الأقسام التالية توصيات مفصلة بشأن كل نقطة من هذه النقاط.
السلامة والاتساق
سواء كنت تقوم بنشر تحديث إلى التعليمات البرمجية للتطبيق الخاص بك أو البنية الأساسية كتعليق برمجي (IaC) أو علامة ميزة أو تحديث تكوين، فأنت تعرض حمل العمل للخطر. لا توجد عمليات توزيع منخفضة المخاطر للإنتاج. يجب أن يتبع كل توزيع نمطا قياسيا ويجب أن يكون تلقائيا لفرض التناسق وتقليل مخاطر الخطأ البشري. من المهم أن تكون سلسلة توريد حمل العمل وتدفقات التوزيع موثوقة وآمنة، وأن يكون لها معايير توزيع محددة بوضوح. تعامل مع كل عملية نشر على أنها مخاطرة محتملة وخضع كل عملية توزيع لنفس مستوى إدارة المخاطر. على الرغم من المخاطر، يجب الاستمرار في نشر التغييرات المنتظمة على حمل العمل الخاص بك. يؤدي الفشل في نشر التحديثات العادية إلى مخاطر أخرى، مثل الثغرات الأمنية التي يجب معالجتها من خلال عمليات النشر. لمزيد من المعلومات، راجع توصيات لتصميم سلسلة توريد تطوير حمل العمل.
يفضل عمليات النشر الصغيرة المتكررة عمليات التوزيع الكبيرة غير المتكررة. من الأسهل حل التغييرات الصغيرة عند ظهور مشكلات وتساعد عمليات التوزيع المتكررة فريقك على بناء الثقة في عملية التوزيع. من المهم أيضا أن تتعلم من الإنتاج من خلال مراجعة عمليات حمل العمل عند مواجهة حالة شاذة أثناء التوزيع. قد تجد نقاط ضعف في تصميم البنية الأساسية أو الإطلاق. عند حدوث مشكلات أثناء عمليات النشر، تأكد من أن الوفاة غير الملومة هي جزء من عملية SDP لالتقاط الدروس حول الحادث.
نشر التعرض التدريجي
عند حدوث مشكلات في التوزيع، يكون الهدف هو التقاطها في أقرب وقت ممكن لتقليل التأثير على المستخدمين النهائيين. تنفيذ نموذج نشر الإطلاق التدريجي، المعروف أيضا باسم نموذج التعرض التدريجي، لتحقيق هذا الهدف. تعد عمليات توزيع الكناري مثالا شائعا على التعرض التدريجي. في نموذج التوزيع هذا، تتلقى مجموعة صغيرة من المستخدمين الداخليين أو الخارجيين الميزة الجديدة أولا. بعد أن تقوم المجموعة الأولى بتشغيل الإصدار الجديد دون مشكلة، يتم نشر الميزة إلى مجموعات أكبر بشكل متتالي حتى يقوم محتوى المستخدم بأكمله بتشغيل الإصدار الجديد. تستخدم علامات الميزات عادة لتمكين الإصدار الجديد للمستخدمين المستهدفين في عمليات توزيع الكناري.
نموذج توزيع شائع آخر هو نهج أزرق أخضر. في هذا النموذج، يتم نشر مجموعتين متطابقتين، أو تجمعات، من البنية الأساسية لحمل العمل. كلا التجمعين قادران على التعامل مع حمل إنتاج كامل. يقوم التجمع الأول (الأزرق) بتشغيل الإصدار الحالي من النشر حيث يهبط جميع المستخدمين. يتم تحديث التجمع الثاني (الأخضر) مع الميزة الجديدة واختباره داخليا. بعد الاختبار الداخلي، يتم توجيه مجموعة فرعية من حركة مرور الإنتاج من التجمع الأزرق إلى التجمع الأخضر. مثل عمليات توزيع الكناري، يكون الإطلاق التدريجي أثناء تحويل المزيد من نسبة استخدام الشبكة إلى التجمع الأخضر في موجات الإطلاق الأكبر على التوالي. بعد الانتهاء من الإطلاق، يصبح تجمع التحديث هو التجمع الأزرق والتجمع الأخضر جاهز للتوزيع التالي. يتم فصل التجمعين منطقيا عن بعضهما البعض للحماية من الأعطال. يمكنك نشر تباين من النموذج الأزرق والأخضر في حمل العمل الذي يستخدم نمط تصميم طوابع النشر عن طريق النشر على طابع واحد في كل مرة.
في كلا النموذجين، يجب أن يكون الوقت بين كل مرحلة من مراحل الإطلاق طويلا بما يكفي لتمكينك من مراقبة المقاييس الصحية لحمل العمل. يجب توفير وقت خبز وافر، ووقت بين مجموعات الإطلاق، للمساعدة في ضمان أن المستخدمين من مناطق مختلفة أو المستخدمين الذين يؤدون مهاما مختلفة لديهم الوقت لاستخدام حمل العمل بسعة عادية. يجب قياس أوقات الخبز بالساعات والأيام بدلا من الدقائق. يجب أيضا زيادة أوقات الخبز لكل مجموعة إطلاق بحيث يمكنك حساب مناطق زمنية مختلفة وأنماط الاستخدام على مدار اليوم.
نماذج السلامة
تطوير نموذج صحي قوي كجزء من النظام الأساسي للمراقبة واستراتيجيات الموثوقية. يجب أن يوفر نموذج الصحة رؤية متعمقة لمكونات حمل العمل وصحته العامة. أثناء الإطلاق، إذا تلقيت تنبيها حول تغيير صحي يتعلق بالمستخدم النهائي، يجب أن يتوقف الإطلاق على الفور ويجب إجراء تحقيق في سبب التنبيه للمساعدة في تحديد مسار العمل التالي. إذا لم تكن هناك مشكلات أبلغ عنها المستخدمون النهائيون وبقيت جميع مؤشرات الصحة خضراء طوال وقت الخبز، يجب أن يستمر الإطلاق. تأكد من تضمين مقاييس الاستخدام في النموذج الصحي للمساعدة في ضمان عدم وجود مشكلات أبلغ عنها المستخدم والإشارات الصحية السلبية لا يخفي مشكلة. لمزيد من المعلومات، راجع إنشاء نموذج صحي.
الكشف عن المشكلات
عندما يتسبب التوزيع في حدوث مشكلة في إحدى مجموعات الإطلاق، يجب أن يتوقف الإطلاق على الفور. يجب إجراء تحقيق في سبب المشكلة وخطورة التأثيرات بمجرد تلقي التنبيه. يمكن أن يتضمن الاسترداد من المشكلة ما يلي:
التراجع عن التوزيع عن طريق التراجع عن التغييرات التي تم إجراؤها في التوزيع والعودة إلى آخر تكوين عمل معروف.
المضي قدما في النشر عن طريق معالجة المشكلة في خضم الإطلاق. يمكنك معالجة المشكلات في منتصف الإطلاق عن طريق تطبيق إصلاح عاجل أو تقليل المشكلة بطريقة أخرى.
نشر بنية أساسية جديدة باستخدام آخر تكوين عمل معروف.
يمكن أن يكون التراجع عن التغييرات، خاصة قاعدة البيانات أو المخطط أو تغييرات المكونات الأخرى ذات الحالة، أمرا معقدا. يجب أن توفر إرشادات SDP الخاصة بك إرشادات واضحة حول كيفية التعامل مع تغييرات البيانات وفقا لتصميم ملكية البيانات لحمل العمل الخاص بك. وبالمثل، يجب التعامل مع المضي قدما بعناية لضمان عدم إهمال SDP وتنفيذ الإصلاح العاجل أو جهود تقليل أخرى بأمان.
توصيات SDP العامة
تنفيذ تعيين الإصدار عبر البيانات الاصطناعية للبناء للمساعدة في التأكد من أنه يمكنك العودة إلى الوراء والتراجع عند الضرورة.
استخدم تدفق الإصدار أو بنية التفريع المستندة إلى الجذع، والتي تفرض التعاون المتزامن بإحكام عبر فريق التطوير، بدلا من Gitflow أو بنية التفريع المستندة إلى البيئة.
أتمتة أكبر قدر ممكن من SDP الخاص بك. للحصول على إرشادات مفصلة حول أتمتة IaC وعمليات التكامل المستمر للتطبيق والتسليم المستمر (CI/CD)، راجع توصيات لتنفيذ الأتمتة.
استخدم ممارسات CI لدمج تغييرات التعليمات البرمجية بانتظام في المستودعات. يمكن أن تساعدك ممارسات التكامل المستمر في تحديد تعارضات التكامل وتقليل احتمالية عمليات الدمج الكبيرة والمحفيفة بالمخاطر. لمزيد من المعلومات، راجع دليل التكامل المستمر.
استخدم علامات الميزات لتمكين الميزات أو التغييرات الجديدة في الإنتاج أو تعطيلها بشكل انتقائي. يمكن أن تساعدك علامات الميزات على التحكم في تعرض التعليمات البرمجية الجديدة والتراجع عن التوزيع بسرعة إذا ظهرت مشكلات.
انشر التغييرات في بيئات التقسيم المرحلي التي تعكس بيئة الإنتاج الخاصة بك. تسمح لك بيئات التدريب باختبار التغييرات في إعداد خاضع للرقابة قبل التوزيع إلى البيئة المباشرة.
قم بإنشاء فحوصات ما قبل النشر، بما في ذلك مراجعة التعليمات البرمجية وفحص الأمان وفحوصات التوافق، للمساعدة في ضمان أمان نشر التغييرات.
تنفيذ قاطعات الدوائر لإيقاف نسبة استخدام الشبكة تلقائيا إلى خدمة تواجه مشكلات. ويمكن أن يساعد القيام بذلك على منع المزيد من تدهور النظام.
بروتوكولات SDP في حالات الطوارئ
قم بإنشاء بروتوكولات توجيهية تحدد كيفية تعديل SDP الخاص بك للحصول على إصلاح عاجل أو لمشكلات الطوارئ مثل خرق الأمان أو التعرض للثغرات الأمنية. على سبيل المثال، قد تتضمن بروتوكولات SDP في حالات الطوارئ ما يلي:
تسريع مرحلة الترقية والموافقة.
اختبار الدخان وتسريع اختبار التكامل.
خبز تقليل الوقت.
في بعض الحالات، قد تحد الطوارئ من بوابات الجودة والاختبار، ولكن يجب تشغيل البوابات في أسرع وقت ممكن كتمرين خارج النطاق. تأكد من تحديد من يمكنه الموافقة على تسريع SDP في حالة الطوارئ والمعايير التي يجب استيفاءها للموافقة على التسارع. قم بمواءمة بروتوكولات SDP للطوارئ مع خطة الاستجابة للطوارئ للمساعدة في ضمان التعامل مع جميع حالات الطوارئ وفقا لنفس البروتوكولات.
الاعتبارات
يعد بناء ممارسات النشر الآمنة وصيانتها أمرا معقدا. يعتمد نجاحك في التنفيذ الكامل لمعايير قوية على نضج ممارساتك عبر العديد من مجالات تطوير البرامج. يمكن أن يساعد استخدام الأتمتة وIaC-only لتغييرات البنية الأساسية والاتساق في استراتيجيات التفريع واستخدام علامات الميزات والعديد من الممارسات الأخرى في ضمان التوزيع الآمن. استخدم هذا الدليل لتحسين حمل العمل الخاص بك وإعلام خططك للتحسين مع تطور ممارساتك.
تسهيل Azure
تدعم Azure PipelinesوGitHub Actions عمليات النشر متعددة المراحل باستخدام بوابات الموافقة، والتي يمكن أن تساعدك في تصميم إطلاق التعرض التدريجي لعمليات التوزيع.
استخدم فتحات التقسيم المرحلي لخدمة تطبيقات Azure للتبديل بسهولة بين إصدارات التعليمات البرمجية. تعد فتحات التقسيم المرحلي مفيدة للاختبار في بيئات التقسيم المرحلي ويمكن استخدامها لعمليات النشر باللونين الأزرق والأخضر.
تخزين علامات ميزات تطبيق الويب وإدارتها في Azure App Configuration. باستخدام هذه الخدمة، يمكنك إنشاء الميزات وتغييرها وتوزيعها في مستوى إدارة موحد.
توزيع تطبيقات حمل العمل في جهازك الظاهري باستخدام تطبيقات الجهاز الظاهري.
استخدم موازنات تحميل Azure لتنفيذ استراتيجيات التوزيع وكشف صحة تطبيقات حمل العمل باستخدام الموارد الأصلية.
استخدم ملحق سلامة التطبيق للإبلاغ عن صحة التطبيق من داخل مثيل مجموعة مقياس الجهاز الظاهري. يفحص الملحق نقطة نهاية تطبيق محلي ويحدث الحالة الصحية استنادا إلى استجابات TCP/HTTP(S) المستلمة من التطبيق.
استخدم Azure Logic Apps لإنشاء إصدار جديد من التطبيق كلما تم إجراء تحديث له. يحتفظ Azure بمحفوظات إصدارات التطبيق ويمكنه العودة أو الترقية إلى أي إصدار سابق.
توفر العديد من خدمات قاعدة بيانات Azure وظيفة استعادة في نقطة زمنية يمكن أن تساعدك على العودة إلى الحالة السابقة. تتضمن الخدمات التي تدعم الاستعادة في نقطة زمنية ما يلي:
مثال
راجع دليل بنية بنية أنظمة مجموعات Azure Kubernetes Service (AKS) للتوزيع الأزرق والأخضر للحصول على مثال حول كيفية استخدام نموذج التوزيع هذا.
الروابط ذات الصلة
- ملحق سلامة التطبيق
- تكوين Azure App
- فتحات التقسيم المرحلي لخدمة تطبيقات Azure
- Azure Cosmos DB
- قاعدة بيانات Azure لـ MySQL
- قاعدة بيانات Azure لـ PostgreSQL
- موازنات تحميل Azure
- Azure Logic Apps
- تدفقات Azure
- قاعدة بيانات Azure SQL
- مثيل Azure SQL المُدار
- بناء نموذج صحي
- دليل التكامل المستمر
- طوابع النشر
- اعتبارات الأداء للبنية الأساسية للتوزيع
- هندسة الإصدار: تطوير التطبيقات
- هندسة الإصدار: التكامل المستمر
- هندسة الإصدار: العودة إلى الحالة السابقة
- اختبار التطبيق الخاص بك وبيئة Azure
- تطبيقات VM
روابط المجتمع
قائمة التحقق من التميز التشغيلي
راجع المجموعة الكاملة من التوصيات.