مشاركة عبر

توصيات لتصميم استراتيجية التخفيف من فشل التوزيع

  • مقالة

ينطبق على توصية قائمة التحقق من التميز التشغيلي في Azure Well-Architected Framework:

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

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

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

استراتيجيات التصميم الرئيسية

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

عند استخدام نموذج توزيع التعرض التدريجي كممارسة قياسية:

  • لديك الأساس الصحيح لتقليل التأثيرات على عملائك أو المستخدمين الداخليين عند فشل عمليات النشر.
  • يمكنك التخفيف من المشكلات بكفاءة.

تتكون استراتيجية التخفيف من فشل التوزيع من خمس مراحل واسعة:

  1. الكشف: للاستجابة إلى عملية توزيع فاشلة، يجب أولا اكتشاف الفشل. يمكن أن يتخذ الكشف عدة أشكال، مثل اختبارات الدخان الفاشلة أو المشكلات التي أبلغ عنها المستخدم أو التنبيهات التي ينشئها النظام الأساسي للمراقبة.

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

  3. التخفيف من المخاطر: يمكنك تنفيذ إجراء التخفيف المحدد. يمكن أن يتخذ التخفيف شكل التراجع أو التراجع أو العودة إلى الأمام أو استخدام تكوين وقت التشغيل لتجاوز الدالة المخالفة.

  4. الاتصال: يجب إعلام المساهمين والمستخدمين النهائيين المتأثرين بالحالة أثناء اكتشاف المشكلة والعمل من خلالها كما هو مطلوب في خطة الاستجابة للطوارئ.

  5. ما بعد الوفاة: توفر أنظمة ما بعد الوفاة بلا لوم فرصا لفريق حمل العمل لتحديد مجالات التحسين وإنشاء خطط لتطبيق التعلم.

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

الكشف عن المشكلات

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

  • استخدم أداة إدارة أداء التطبيق.
  • تمكين التسجيل من خلال الأجهزة.

يجب أن يحدث اختبار الدخان واختبار الجودة الأخرى في كل مرحلة من مراحل الإطلاق. يجب ألا تؤثر الاختبارات الناجحة في مجموعة توزيع واحدة على قرارات الاختبار في المجموعات اللاحقة.

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

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

القرار

يتضمن اتخاذ قرار بشأن استراتيجية التخفيف المناسبة لمسألة توزيع معينة النظر في العديد من العوامل، بما في ذلك:

  • نوع نموذج التعرض التدريجي الذي تستخدمه. على سبيل المثال، قد تستخدم نموذجا أزرق أخضر أو نموذجا كناريا.

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

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

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

    • تابع عملية الإطلاق.
    • تجنب التراجع.
    • العودة إلى الوراء أثناء إصلاح التعليمات البرمجية المخالفة.

  • مستوى الجهد المطلوب لتنفيذ إصلاح في التعليمات البرمجية.

    إذا كان مستوى الجهد لإصلاح التعليمات البرمجية منخفضا، فإن المضي قدما من خلال تنفيذ إصلاح عاجل هو الخيار الصحيح لسيناريوهات معينة.

  • مستوى الأهمية الحرجة لحمل العمل المتأثر.

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

  • نوع البنية الأساسية التي يستخدمها حمل العمل - قابل للتغيير أو غير قابل للتغيير.

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

بغض النظر عن الخيارات التي تتخذها، يجب عليك تضمين الموافقات المناسبة في عملية صنع القرار الخاصة بك وتقنينها في شجرة القرار الخاصة بك.

التخفيف من المخاطر

  • العودة إلى الحالة السابقة: في سيناريو التراجع، يمكنك إعادة الأنظمة المحدثة إلى حالة التكوين الجيدة المعروفة الأخيرة.

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

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

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

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

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

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

  • توزيع الطوارئ (الإصلاح العاجل): إذا كان بإمكانك معالجة المشكلة في منتصف الإطلاق، فقد يكون الإصلاح العاجل هو استراتيجية التخفيف الأكثر عملية.

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

المقايضات:

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

الاتصالات

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

توحيد إيقاع فريق حمل العمل الذي يتبعه لتوفير تحديثات الحالة. تأكد من أن أصحاب المصلحة على دراية بهذا المعيار حتى يعرفوا متى يتوقعون التحديثات.

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

تقرير الموقف

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

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

الاعتبارات والتوصيات العامة

تأكد من أن البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع الخاصة بك يمكن أن تقبل الإصدارات المميزة كمعلمات بحيث يمكنك بسهولة نشر آخر تكوينات جيدة معروفة.

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

تفضل التغييرات الصغيرة والمتكررة على التغييرات الكبيرة غير المتكررة بحيث تكون دلتا بين عمليات النشر الجديدة وآخر عمليات النشر الجيدة المعروفة صغيرة.

قم بإجراء تحليل وضع الفشل (FMA) على البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر والتسليم المستمر (CI/CD) للمساعدة في تحديد المشكلات التي يمكن أن تعقد عوامل التخفيف. مثل حمل العمل الخاص بك ككل، يمكن تحليل المسارات الخاصة بك لتحديد المناطق التي قد تكون مشكلة عند محاولة نوع تخفيف معين.

استخدم وظيفة التراجع التلقائي بحكمة:

  • تحتوي بعض أدوات CI/CD مثل Azure DevOps على وظيفة التراجع التلقائي المضمنة. ضع في اعتبارك استخدام هذه الوظيفة إذا كانت توفر لك قيمة ملموسة.
  • يجب عليك اعتماد وظيفة التراجع التلقائي فقط بعد اختبار البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك بشكل شامل ومنتظم. تأكد من أن البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك ناضجة بما يكفي لإدخال مشكلات إضافية إذا تم تشغيل التراجع التلقائي.
  • تحتاج إلى الثقة في أن الأتمتة تنشر التغييرات الضرورية فقط وأنه يتم تشغيلها فقط عند الضرورة. صمم المشغلات بعناية لتلبية هذه المتطلبات.

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

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

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

تسهيل Azure

  • توفر Azure Pipelines خدمات الإنشاء والإصدار لدعم CI/CD لتطبيقاتك.

  • خطط اختبار Azure هي حل إدارة اختبار يستند إلى المستعرض يسهل استخدامه. يوفر هذا الحل القدرات المطلوبة للاختبار اليدوي المخطط له واختبار قبول المستخدم والاختبار الاستكشافي. توفر خطط اختبار Azure أيضا طريقة لجمع الملاحظات من أصحاب المصلحة.

  • Azure Monitor هو حل مراقبة شامل لجمع وتحليل والاستجابة لبيانات المراقبة من البيئات السحابية والمحلية. تتضمن المراقبة نظاما أساسيا قويا للتنبيه. يمكنك تكوين هذا النظام للإعلامات التلقائية والإجراءات الأخرى، مثل التحجيم التلقائي وآليات الشفاء الذاتي الأخرى.

  • Application Insights هو امتداد لمراقبة يوفر ميزات مراقبة أداء التطبيق (APM).

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

  • توفر العديد من خدمات قاعدة بيانات Azure وظيفة استعادة في نقطة زمنية يمكن أن تساعدك عندما تحتاج إلى التراجع:

  • Azure Chaos Studio Preview هي خدمة مدارة تستخدم هندسة الفوضى لمساعدتك في قياس تطبيق السحابة ومرونة الخدمة وفهمها وتحسينها.

قائمة التحقق من التميز التشغيلي

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من التميز التشغيلي