التوزيع والاختبار لأحمال العمل الحرجة للمهام على Azure

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

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

يجب أن تنفذ الاستراتيجية:

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

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

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

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

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

هام

تعد هذه المقالة جزءا من سلسلة حمل العمل الحرجة لمهمة Azure Well-Architected Framework . إذا لم تكن على دراية بهذه السلسلة، نوصي بالبدء بما هو حمل العمل الحرج للمهمة؟.

توزيع وقت التعطل الصفري

اعرض الفيديو التالي للحصول على نظرة عامة حول توزيع وقت التعطل الصفري.

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

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

توضح عمليات التنفيذ المرجعية للمهام الحرجة عبر الإنترنتوAzure Mission-Critical Connected نهج النشر هذا، كما هو موضح في هذا الرسم التخطيطي:

بيئات التطبيق

اعرض الفيديو التالي للحصول على نظرة عامة على التوصيات لبيئات التطبيق.

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

هناك بعض الاعتبارات الشائعة:

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

• يجب أن تستخدم جميع البيئات البنية الأساسية كقطع أثرية للتعليمات البرمجية (IaC) مثل قوالب Terraform أو Azure Resource Manager (ARM).

بيئات التطوير

اعرض الفيديو التالي للحصول على معلومات حول بيئات التطوير سريعة الزوال والتحقق من صحة الميزات التلقائية.

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

• القدرات. المتطلبات الأقل للموثوقية والسعة والأمان مقبولة لبيئات التطوير.

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

• الكثافة. تحتاج الفرق إلى بيئات متعددة لدعم تطوير الميزات المتوازية. يمكنهم التعايش ضمن اشتراك واحد.

توصيات التصميم

• احتفظ بالبيئة في اشتراك مخصص مع تعيين السياق لأغراض التطوير.

• استخدم عملية تلقائية لنشر التعليمات البرمجية من فرع ميزة إلى بيئة تطوير.

بيئات الاختبار أو التقسيم المرحلي

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

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

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

• Lifecycle. هذه البيئات قصيرة الأجل. يجب إتلافها بعد اكتمال عمليات التحقق من صحة الاختبار.

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

ملاحظة

يجب أن تخضع التطبيقات الحرجة للمهام لاختبارات صارمة.

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

توصيات التصميم

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

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

  ملاحظة

  يوفر التنفيذ المرجعي Mission Critical Online مثالا على منشئ تحميل المستخدم.

• حدد عدد بيئات التقسيم المرحلي وأغراضها ضمن دورة التطوير والإصدار.

بيئات إنتاجية

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

• القدرات. مطلوب أعلى مستويات الموثوقية والسعة ووظائف الأمان للتطبيق.

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

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

توصيات التصميم

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

عمليات التوزيع سريعة الزوال باللون الأزرق/الأخضر

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

توصي Azure Mission-Critical بنهج توزيع أزرق/أخضر حيث يتم نشر البنية الأساسية والتطبيقات معا كجزء من طابع التوزيع. لذلك يؤدي طرح تغيير في البنية الأساسية أو التطبيق دائما إلى توزيع أخضر يحتوي على كلتا الطبقتين. يمكنك هذا الأسلوب من اختبار تأثير التغيير والتحقق من صحته بالكامل مقابل البنية الأساسية والتطبيق من طرف إلى طرف قبل إعادة توجيه حركة مرور المستخدم إليها. يزيد النهج من الثقة في إصدار التغييرات ويتيح ترقيات دون توقف لأنه يمكن التحقق من صحة التوافق مع تبعيات انتقال البيانات من الخادم مثل النظام الأساسي Azure وموفري الموارد ووحدات IaC النمطية.

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

• قدرات التكنولوجيا. استفد من ميزات التوزيع المضمنة في خدمات Azure. على سبيل المثال، توفر Azure App Service فتحات توزيع ثانوية يمكن تبديلها بعد التوزيع. باستخدام خدمة Azure Kubernetes (AKS)، يمكنك استخدام توزيع جراب منفصل على كل عقدة وتحديث تعريف الخدمة.

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

• تأثير التكلفة. هناك تكلفة إضافية بسبب عمليات التوزيع جنبا إلى جنب، والتي يجب أن تتعايش حتى يكتمل النشر.

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

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

توصيات التصميم

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

• استخدم موازن تحميل عمومي، مثل Azure Front Door، لتنسيق الانتقال التلقائي لنسبة استخدام الشبكة للمستخدم بين البيئات الزرقاء والأخضر.

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

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

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

التوزيع على نطاق الاشتراك

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

اعرض الفيديو التالي للحصول على نظرة عامة على توصيات تحديد نطاق الاشتراكات لتطبيق مهم للمهمة.

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

• ⁧⁩قابلية التوسع⁧⁩. بالنسبة لسيناريوهات التطبيق عالية النطاق مع كميات كبيرة من نسبة استخدام الشبكة، قم بتصميم الحل لتوسيع نطاقه عبر اشتراكات Azure متعددة بحيث لا تقيد حدود مقياس اشتراك واحد قابلية التوسع.

  هام

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

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

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

توصيات التصميم

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

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

التحقق المستمر من الصحة والاختبار

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

اعرض الفيديو التالي للحصول على نظرة عامة على التحقق المستمر والاختبار.

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

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

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

• التشغيل التلقائي. الاختبار التلقائي ضروري للتحقق من صحة تغييرات التطبيق أو البنية الأساسية في الوقت المناسب وبطريقة قابلة للتكرار.

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

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

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

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

• ⁧⁩المراقبة⁧⁩. يجب عليك التقاط نتائج الاختبار وتحليلها بشكل فردي وأيضا تجميعها لتقييم الاتجاهات بمرور الوقت. يجب تقييم نتائج الاختبار باستمرار للتأكد من الدقة والتغطية.

توصيات التصميم

اعرض الفيديو التالي لمعرفة كيف يمكن دمج اختبار المرونة مع مسارات Azure DevOps CI/CD.

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

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

• محاذاة اتفاقية مستوى الخدمة للبنية الأساسية للاختبار مع اتفاقية مستوى الخدمة لدورات التوزيع والاختبار.

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

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

  تلميح

  Azure Chaos Studio هو مجموعة أصلية من أدوات تجربة الفوضى. تسهل الأدوات إجراء تجارب الفوضى وإدخال الأخطاء داخل خدمات Azure ومكونات التطبيق.

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

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

• فحص ومراقبة سلسلة توريد البرامج الشاملة وتبعيات الحزمة ل CVEs المعروفة.

  • استخدم Dependabot لمستودعات GitHub لضمان تحديث المستودع تلقائيا بأحدث إصدارات الحزم والتطبيقات التي يعتمد عليها.

البنية الأساسية كنشر للتعليمات البرمجية

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

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

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

• البنية الأساسية القابلة للتكرار. توزيع أحمال العمل الحرجة للمهام بطريقة تولد نفس البيئة في كل مرة. يجب أن يكون IaC هو النموذج الأساسي.

• التشغيل التلقائي. يجب أن تكون جميع عمليات التوزيع تلقائية بالكامل. العمليات البشرية عرضة للخطأ.

توصيات التصميم

• قم بتطبيق IaC، مع التأكد من تعريف جميع موارد Azure في القوالب التعريفية والحفاظ عليها في مستودع التحكم بالمصادر. يتم نشر القوالب ويتم توفير الموارد تلقائيا من التحكم بالمصادر عبر مسارات CI/CD. لا نوصي باستخدام البرامج النصية الإلزامية.

• حظر العمليات اليدوية ضد جميع البيئات. الاستثناء الوحيد هو بيئات المطور المستقلة بالكامل.

أدوات DevOps

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

توفر Microsoft مجموعتي أدوات أصليتين من Azure، GitHub Actions وAzure Pipelines، التي يمكنها توزيع تطبيق مهم وإدارته بفعالية.

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

• القدرات التكنولوجية. تتداخل قدرات GitHub وAzure DevOps. يمكنك استخدامها معا للحصول على أفضل من كليهما. يتمثل النهج الشائع في تخزين مستودعات التعليمات البرمجية في GitHub.com أو GitHub AE أثناء استخدام Azure Pipelines للتوزيع.

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

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

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

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

توصيات التصميم

• تتم استضافة كلتا التقنيتين في منطقة Azure واحدة، مما قد يجعل استراتيجية التعافي من الكوارث مقيدة.

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

• حدد اتفاقية مستوى الخدمة (SLA) للتوفر لأوادر النشر وتأكد من التوافق مع متطلبات موثوقية التطبيق الأوسع.

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

استراتيجية التفريع

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

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

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

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

توصيات التصميم

• تحديد أولويات استخدام GitHub للتحكم بالمصادر.

  هام

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

• قم بتشغيل عملية اختبار تلقائية للتحقق من صحة مساهمات تغيير التعليمات البرمجية قبل قبولها. يجب على أعضاء الفريق أيضا مراجعة التغييرات.

• تعامل مع الفرع الرئيسي على أنه فرع ثابت ومتقدم باستمرار يستخدم في المقام الأول لاختبار التكامل.

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

• استخدم فروع الإصدار/* المخصصة التي تم إنشاؤها من الفرع الرئيسي وتستخدم للنشر في بيئات الإنتاج. يجب أن تظل فروع الإصدار/* في المستودع ويمكن استخدامها لتصحيح الإصدار.

• توثيق عملية إصلاح عاجل واستخدامها فقط عند الحاجة. إنشاء الإصلاحات العاجلة في فرع الإصلاح/* للدمج اللاحق في فرع الإصدار والتوزيع إلى الإنتاج.

الذكاء الاصطناعي ل DevOps

يمكنك تطبيق منهجيات AIOps في مسارات CI/CD لتكملة نهج الاختبار التقليدية. يتيح القيام بذلك الكشف عن الانحدارات أو التدهور المحتمل ويسمح بالتوقف عن عمليات النشر بشكل استباقي لمنع التأثيرات السلبية المحتملة.

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

• حجم بيانات تتبع الاستخدام. تنبعث من مسارات CI/CD وعمليات DevOps مجموعة واسعة من بيانات تتبع الاستخدام لنماذج التعلم الآلي. تتراوح بيانات تتبع الاستخدام من نتائج الاختبار ونتائج التوزيع إلى البيانات التشغيلية حول مكونات الاختبار من مراحل النشر المركب.

• ⁧⁩قابلية التوسع⁧⁩. قد لا تتمكن نهج معالجة البيانات التقليدية مثل استخراج وتحويل وتحميل (ETL) من توسيع نطاق معدل النقل لمواكبة نمو بيانات تتبع الاستخدام للتوزيع وبيانات مراقبة التطبيق. يمكنك استخدام نهج التحليلات الحديثة التي لا تتطلب ETL وحركة البيانات، مثل ظاهرية البيانات، لتمكين التحليل المستمر بواسطة نماذج AIOps.

• تغييرات التوزيع. يجب تخزين التغييرات في التوزيع للتحليل التلقائي والارتباط بنتائج التوزيع.

توصيات التصميم

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

  • كشف بيانات إمكانية مراقبة التطبيق من بيئات التقسيم المرحلي والاختبار والإنتاج للتحليل والارتباط داخل نماذج AIOps.

• اعتماد سير عمل MLOps.

• تطوير نماذج تحليلية مدركة للسياق وواعية بالتبعية لتوفير تنبؤات بهندسة ميزات تلقائية لمعالجة تغييرات المخطط والسلوك.

• تشغيل النماذج عن طريق تسجيل وتوزيع أفضل النماذج المدربة داخل مسارات التوزيع.

الخطوة التالية

راجع اعتبارات الأمان.

الأمان