توصيات لإجراء تحليل وضع الفشل

ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:

RE:03	استخدم تحليل وضع الفشل (FMA) لتحديد وتحديد أولويات حالات الفشل المحتملة في مكونات الحل. قم بإجراء FMA لمساعدتك في تقييم مخاطر وتأثير كل وضع فشل. تحديد كيفية استجابة حمل العمل واسترداده.

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

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

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

التعريفات

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

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

المتطلبات الأساسية

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

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

نهج FMA

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

تحليل حمل العمل

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

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

تحديد التبعيات

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

التبعيات الداخلية هي مكونات في نطاق حمل العمل المطلوبة لتشغيل حمل العمل. تتضمن التبعيات الداخلية النموذجية واجهات برمجة التطبيقات أو حلول إدارة البيانات السرية/المفاتيح مثل Azure Key Vault. بالنسبة لهذه التبعيات، التقط بيانات الموثوقية، مثل اتفاقيات مستوى الخدمة للتوفر وحدود التحجيم. التبعيات الخارجية هي مكونات مطلوبة خارج نطاق حمل العمل، مثل تطبيق آخر أو خدمة تابعة لجهة خارجية. تتضمن التبعيات الخارجية النموذجية حلول المصادقة، مثل Microsoft Entra ID وحلول الاتصال السحابي، مثل Azure ExpressRoute.

تحديد وتوثيق التبعيات في حمل العمل الخاص بك، وتضمينها في البيانات الاصطناعية لوثائق التدفق.

نقاط الفشل

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

• الانقطاع الإقليمي. منطقة Azure بأكملها غير متوفرة.

• انقطاع منطقة التوفر. منطقة توفر Azure غير متوفرة.

• انقطاع الخدمة. خدمة Azure واحدة أو أكثر غير متوفرة.

• رفض الخدمة الموزع (DDoS) أو هجوم ضار آخر.

• التكوين الخاطئ للتطبيق أو المكون.

• خطأ عامل التشغيل.

• انقطاع الصيانة المخطط له.

• التحميل الزائد للمكون.

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

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

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

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

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

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

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

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

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

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

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

⁧⁩النتيجة⁧⁩

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

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

راجع جدول المثال التالي للحصول على نقطة بداية للوثائق.

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

تسهيل Azure

استخدم Azure MonitorوLog Analytics للكشف عن المشكلات في حمل العمل الخاص بك. لمزيد من التفاصيل حول المشكلات المتعلقة بالبنية الأساسية والتطبيقات وقواعد البيانات، استخدم أدوات مثل Application Insights و Container InsightsوNetwork InsightsوVM InsightsوSQL Insights.

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

للحصول على معلومات حول تطبيق مبادئ FMA على خدمات Azure الشائعة، راجع تحليل وضع الفشل لتطبيقات Azure.

مثال

يعرض الجدول التالي مثال FMA لموقع ويب للتجارة الإلكترونية مستضاف على مثيلات Azure App Service مع قواعد بيانات Azure SQL وهو أمام Azure Front Door.

تدفق المستخدم: تسجيل دخول المستخدم والبحث عن المنتج وتفاعل عربة التسوق

المكونات	خطر	الاحتمالية	التأثير/التخفيف/الملاحظة	انقطاع
Microsoft Entra ID	انقطاع الخدمة	منخفض	انقطاع كامل في حمل العمل. تعتمد على Microsoft للمعالجة.	كامل
Microsoft Entra ID	خطأ في التكوين	متوسط	المستخدمون غير قادرين على تسجيل الدخول. لا يوجد تأثير انتقال البيانات من الخادم. يبلغ مكتب المساعدة عن مشكلة التكوين إلى فريق الهوية.	بلا
Azure Front Door	انقطاع الخدمة	منخفض	الانقطاع الكامل للمستخدمين الخارجيين. تعتمد على Microsoft للمعالجة.	خارجي فقط
Azure Front Door	الانقطاع الإقليمي	منخفض جداً	الحد الأدنى من التأثير. Azure Front Door هي خدمة عالمية، لذلك يوجه توجيه نسبة استخدام الشبكة العالمية نسبة استخدام الشبكة عبر مناطق Azure غير المتأثرة.	بلا
Azure Front Door	خطأ في التكوين	متوسط	يجب اكتشاف التكوينات الخاطئة أثناء التوزيع. إذا حدث ذلك أثناء تحديث التكوين، يجب على المسؤولين التراجع عن التغييرات. يؤدي تحديث التكوين إلى انقطاع خارجي قصير.	خارجي فقط
Azure Front Door	هجوم موزع لحجب الخدمة	متوسط	احتمالية التعطيل. تدير Microsoft حماية DDoS (L3 وL4) ويحظر Azure Web Application Firewall معظم التهديدات. خطر التأثير المحتمل من هجمات L7.	احتمال الانقطاع الجزئي
Azure SQL	انقطاع الخدمة	منخفض	انقطاع كامل في حمل العمل. تعتمد على Microsoft للمعالجة.	كامل
Azure SQL	الانقطاع الإقليمي	منخفض جداً	فشل مجموعة تجاوز الفشل التلقائي إلى المنطقة الثانوية. الانقطاع المحتمل أثناء تجاوز الفشل. أهداف وقت الاسترداد (RTOs) وأهداف نقطة الاسترداد (RPOs) التي سيتم تحديدها أثناء اختبار الموثوقية.	كامل محتمل
Azure SQL	انقطاع منطقة التوفر	منخفض	لا يوجد تأثير	بلا
Azure SQL	هجوم ضار (حقن)	متوسط	الحد الأدنى من المخاطر. جميع مثيلات Azure SQL مرتبطة بالشبكة الظاهرية من خلال نقاط النهاية الخاصة ومجموعات أمان الشبكة (NSGs) تضيف المزيد من حماية الشبكة داخل الشبكة الظاهرية.	مخاطر منخفضة محتملة
App Service	انقطاع الخدمة	منخفض	انقطاع كامل في حمل العمل. تعتمد على Microsoft للمعالجة.	كامل
App Service	الانقطاع الإقليمي	منخفض جداً	الحد الأدنى من التأثير. زمن الانتقال للمستخدمين في المناطق المتأثرة. يقوم Azure Front Door تلقائيا بتوجيه نسبة استخدام الشبكة إلى المناطق غير المتأثرة.	بلا
App Service	انقطاع منطقة التوفر	منخفض	لا يوجد تأثير. تم نشر خدمات التطبيقات كمنطقة زائدة عن الحاجة. بدون تكرار المنطقة، هناك احتمال للتأثير.	بلا
App Service	هجوم موزع لحجب الخدمة	متوسط	الحد الأدنى من التأثير. نسبة استخدام الشبكة للدخول محمية بواسطة Azure Front Door وAzure Web Application Firewall.	بلا

الروابط ذات الصلة

• تحليل وضع الفشل لتطبيقات Azure
• المرونة والتبعيات

قائمة التحقق من الموثوقية

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

قائمة التحقق من الموثوقية