مشاركة عبر

تحليل وضع الفشل لتطبيقات Azure

  • مقالة

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

فيما يلي العملية العامة لإجراء تحليل وضع الفشل FMA:

  1. تحديد جميع المكونات في النظام. قم بتضمين التبعيات الخارجية، مثل موفري الهوية وخدمات الجهات الخارجية وغيرها.

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

  3. تصنيف كل وضع فشل وفقا لمخاطره الإجمالية. خذ بعين الاعتبار هذه العوامل:

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

  4. حدد كيفية استجابة التطبيق واسترداده لكل وضع فشل. ضع في اعتبارك المفاضلات في التكلفة وتعقيد التطبيق.

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

App Service

إيقاف تشغيل تطبيق App Service.

الكشف عن المشكلات. الأسباب المحتملة:

  • توقع إيقاف التشغيل

    • يقوم العامل بإيقاف تشغيل التطبيق؛ على سبيل المثال، باستخدام مدخل Microsoft Azure.
    • إلغاء تحميل التطبيق لأنه كان خاملًا. (فقط في حالة تعطيل الإعداد Always On.)

  • إيقاف تشغيل غير متوقع

    • تعطل التطبيق.
    • مثيل App Service VM غير متوفر.

سيؤدي تسجيل Application_End إلى إيقاف تشغيل مجال التطبيق (تعطل جزئي) وهو الطريقة الوحيدة لإيقاف تشغيل مجال التطبيق.

التعافي:

  • في حالة توقع إيقاف التشغيل، استخدم حدث إيقاف تشغيل التطبيق لإيقاف التشغيل بأمان. على سبيل المثال، في ASP.NET، استخدم الأسلوب Application_End.
  • في حالة إلغاء تحميل التطبيق أثناء الخمول، يتم إعادة تشغيله تلقائيا عند الطلب التالي. لكن في هذه الحالة، ستضطر لتحمل «بدء التطبيق من البداية»
  • لمنع إلغاء تحميل التطبيق أثناء الخمول، قم بتمكين الإعداد Always On في تطبيق الويب. راجع تكوين تطبيقات الويب في Azure App Service.
  • لمنع عامل تشغيل من إيقاف تشغيل التطبيق، قم بتعيين تأمين مورد بالمستوى ReadOnly. لمزيد من المعلومات، راجع تأمين الموارد باستخدام إدارة موارد Azure.
  • في حالة تعطل التطبيق أو عدم توفر الجهاز الظاهري لخدمة التطبيقات، تقوم App Service تلقائيا بإعادة تشغيل التطبيق.

التشخيصات. سجلات التطبيق وسجلات خادم الويب. راجع تمكين تسجيل التشخيص لتطبيقات الويب في Azure App Service.

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

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

التعافي:

التشخيصات. سجل جميع طلبات المصادقة.

توزيع تحديث غير صالح.

الكشف عن المشكلات. مراقبة صحة التطبيق من خلال مدخل Microsoft Azure (راجع مراقبة أداء تطبيق الويب Azure) أو تنفيذ نمط مراقبة نقطة النهاية الصحية.

الاسترداد:. استخدم فتحات التوزيع متعددة والعودة إلى آخر توزيع معروف جيدًا. لمزيد من المعلومات، راجع تطبيق الويب الأساسي.

Microsoft Entra ID

فشل مصادقة الاتصال OpenID.

الكشف عن المشكلات. فيما يلي أوضاع الفشل المحتملة:

  1. معرف Microsoft Entra غير متوفر، أو لا يمكن الوصول إليه بسبب مشكلة في الشبكة. فشل إعادة التوجيه إلى نقطة نهاية المصادقة، ويُصدر البرنامج الوسيط لـ OpenID استثناء.
  2. مستأجر Microsoft Entra غير موجود. ترجع إعادة التوجيه إلى نقطة نهاية المصادقة رمز HTTP خطأ، ويُصدر البرنامج الوسيط لـ OpenID استثناء.
  3. تعذر المصادقة على المستخدم. لا يلزم وجود استراتيجية للكشف؛ يعالج معرف Microsoft Entra حالات فشل تسجيل الدخول.

التعافي:

  1. التقاط الاستثناءات غير المعالجة من البرنامج الوسيط.
  2. معالجة أحداث AuthenticationFailed.
  3. إعادة توجيه المستخدم إلى صفحة خطأ.
  4. إعادة محاولة المستخدم.

فشل كتابة البيانات إلى Azure Search.

الكشف عن المشكلات. التقاط أخطاء Microsoft.Rest.Azure.CloudException.

التعافي:

يعيد Search .NET SDK المحاولة تلقائيا بعد حالات الفشل العابرة. يجب التعامل مع أي استثناءات يطرحها عميل SDK كأخطاء غير عابرة.

يستخدم سياسة إعادة المحاولة الافتراضية محاولة التراجع. لاستخدام سياسة إعادة محاولة مختلف، قم باستدعاء SetRetryPolicy على SearchIndexClient أو الفئة SearchServiceClient. لمزيد من المعلومات، راجع إعادة المحاولة التلقائية.

التشخيصات. استخدم بحث تحليلات نسبة استخدام الشبكة.

فشل قراءة البيانات من Azure Search.

الكشف عن المشكلات. التقاط أخطاء Microsoft.Rest.Azure.CloudException.

التعافي:

يعيد Search .NET SDK المحاولة تلقائيا بعد حالات الفشل العابرة. يجب التعامل مع أي استثناءات يطرحها عميل SDK كأخطاء غير عابرة.

يستخدم سياسة إعادة المحاولة الافتراضية محاولة التراجع. لاستخدام سياسة إعادة محاولة مختلف، قم باستدعاء SetRetryPolicy على SearchIndexClient أو الفئة SearchServiceClient. لمزيد من المعلومات، راجع إعادة المحاولة التلقائية.

التشخيصات. استخدم بحث تحليلات نسبة استخدام الشبكة.

Cassandra

فشل القراءة أو الكتابة إلى عقدة.

الكشف عن المشكلات. التقاط الاستثناء. بالنسبة لعملاء .NET، System.Web.HttpException هو الاستثناء المعتاد. قد يكون لدى عميل آخر أنواع استثناء أخرى. لمزيد من المعلومات، راجع معالجة أخطاء Cassandra بشكل صحيح.

التعافي:

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

التشخيصات. سجلات التطبيق

خدمة السحابة

توقف غير متوقع لأدوار الويب أو العامل.

الكشف عن المشكلات. تشغيل الحدث RoleEnvironment.Stopping.

الاسترداد. منع الأسلوب RoleEntryPoint.OnStop للتنظيف بأمان. لمزيد من المعلومات، راجع الطريقة الصحيحة للتعامل مع أحداث Azure OnStop (مدونة).

Azure Cosmos DB

فشل قراءة البيانات.

الكشف عن المشكلات. التقاط System.Net.Http.HttpRequestException أو Microsoft.Azure.Documents.DocumentClientException.

التعافي:

  • يعيد SDK المحاولات الفاشلة تلقائيا. لتعيين عدد مرات إعادة المحاولة والحد الأقصى لوقت الانتظار، قم بتكوين ConnectionPolicy.RetryOptions. الاستثناءات التي يطرحها العميل تكون إما خارج سياسة إعادة المحاولة أو تكون أخطاء غير عابرة.
  • إذا خنق Azure Cosmos DB العميل، فإنه يرجع خطأ HTTP 429. التحقق من حالة التعليمة البرمجية DocumentClientException. إذا كنت تتلقى الخطأ 429 باستمرار، فكر في زيادة قيمة معدل النقل للمجموعة.
    • إذا كنت تستخدم MongoDB API، سترجع الخدمة رمز الخطأ 16500 عند التقييد.
  • تمكين تكرار المنطقة عند العمل مع منطقة تدعم مناطق التوفر. عند استخدام تكرار المنطقة، يفشل Azure Cosmos DB تلقائيا في حالة انقطاع المنطقة. لمزيد من المعلومات، راجع تحقيق قابلية وصول عالية باستخدام Azure Cosmos DB.
  • إذا كنت تقوم بتصميم حل متعدد المناطق، فنسخ قاعدة بيانات Azure Cosmos DB عبر منطقتين أو أكثر. جميع النسخ المتماثلة قابلة للقراءة. باستخدام حزم SDK للعميل، حدد المعلمة PreferredLocations. هذه قائمة مرتبة لمناطق Azure. ستُرسَل جميع القراءات إلى المنطقة المتوفرة الأولى في القائمة. في حالة فشل الطلب، سيجرب العميل المناطق الأخرى في القائمة، بالترتيب. لمزيد من المعلومات، راجع كيفية إعداد التوزيع العمومي في Azure Cosmos DB ل NoSQL.

التشخيصات. سجل جميع الأخطاء الخاصة بالعميل.

فشل كتابة البيانات.

الكشف عن المشكلات. التقاط System.Net.Http.HttpRequestException أو Microsoft.Azure.Documents.DocumentClientException.

التعافي:

  • يعيد SDK المحاولات الفاشلة تلقائيا. لتعيين عدد مرات إعادة المحاولة والحد الأقصى لوقت الانتظار، قم بتكوين ConnectionPolicy.RetryOptions. الاستثناءات التي يطرحها العميل تكون إما خارج سياسة إعادة المحاولة أو تكون أخطاء غير عابرة.
  • إذا خنق Azure Cosmos DB العميل، فإنه يرجع خطأ HTTP 429. التحقق من حالة التعليمة البرمجية DocumentClientException. إذا كنت تتلقى الخطأ 429 باستمرار، فكر في زيادة قيمة معدل النقل للمجموعة.
  • تمكين تكرار المنطقة عند العمل مع منطقة تدعم مناطق التوفر. عند استخدام التكرار في المنطقة، يقوم Azure Cosmos DB بشكل متزامن بنسخ جميع عمليات الكتابة عبر مناطق التوفر. لمزيد من المعلومات، راجع تحقيق قابلية وصول عالية باستخدام Azure Cosmos DB.
  • إذا كنت تقوم بتصميم حل متعدد المناطق، فنسخ قاعدة بيانات Azure Cosmos DB عبر منطقتين أو أكثر. في حالة فشل المنطقة الأساسية، سيتم ترقية منطقة أخرى للكتابة. يمكنك أيضا تشغيل تجاوز الفشل يدويا. يقوم SDK بعمل اكتشاف وتوجيه تلقائي، لذلك تستمر التعليمات البرمجية للتطبيق في العمل بعد تجاوز الفشل. خلال فترة تجاوز الفشل (غالبًا دقائق)، سيكون لعمليات الكتابة زمن انتقال أعلى، حيث تعثر SDK على منطقة الكتابة الجديدة. لمزيد من المعلومات، راجع كيفية إعداد التوزيع العمومي في Azure Cosmos DB ل NoSQL.
  • كنسخة احتياطية، احتفظ بالمستند في قائمة انتظار النسخ الاحتياطي، ثم قم بمعالجة قائمة الانتظار لاحقا.

التشخيصات. سجل جميع الأخطاء الخاصة بالعميل.

تخزين قائمة الانتظار

تفشل كتابة رسالة إلى تخزين Azure Queue باستمرار.

الكشف عن المشكلات. بعد محاولات إعادة المحاولة N، استمرار فشل عملية الكتابة.

التعافي:

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

التشخيصات. استخدم مقاييس تخزين.

لا يمكن للتطبيق معالجة رسالة معينة من قائمة الانتظار.

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

التعافي:

نقل الرسالة إلى قائمة انتظار منفصلة. قم بتشغيل عملية منفصلة لفحص الرسائل في قائمة الانتظار.

فكر في استخدام قوائم انتظار ناقل خدمة Azure، التي توفر وظيفة قائمة انتظار غير مستخدمة لهذا الغرض.

إشعار

إذا كنت تستخدم قوائم انتظار التخزين مع WebJobs، يوفر WebJobs SDK معالجة مضمنة للرسائل غير قابلة للمعالجة. راجع كيفية استخدام تخزين قائمة انتظار Azure مع WebJobs SDK.

التشخيصات. استخدم تسجيل التطبيق.

ذاكرة التخزين المؤقت في Azure لـ Redis

فشل القراءة من ذاكرة التخزين المؤقت.

الكشف عن المشكلات. التقاط StackExchange.Redis.RedisConnectionException.

التعافي:

  1. إعادة المحاولة بعد حالات الفشل العابرة. يدعم Azure Cache for Redis إعادة المحاولة المضمنة. لمزيد من المعلومات، راجع أداء Azure للتخزين المؤقت لإعادة محاولة Redis.
  2. تعامل مع حالات الفشل غير العابرة كخطأ في ذاكرة التخزين المؤقت، وارجع مصدر البيانات الأصلي.

التشخيصات. استخدم ذاكرة تخزين مؤقت Azure لتشخيصات Redis.

فشل الكتابة إلى ذاكرة التخزين المؤقت.

الكشف عن المشكلات. التقاط StackExchange.Redis.RedisConnectionException.

التعافي:

  1. إعادة المحاولة بعد حالات الفشل العابرة. يدعم Azure Cache for Redis إعادة المحاولة المضمنة. لمزيد من المعلومات، راجع أداء Azure للتخزين المؤقت لإعادة محاولة Redis.
  2. إذا كان الخطأ غير عابر، فتجاهله واسمح للمعاملات الأخرى بالكتابة إلى ذاكرة التخزين المؤقت لاحقا.

التشخيصات. استخدم ذاكرة تخزين مؤقت Azure لتشخيصات Redis.

قاعدة بيانات SQL

تعذر الاتصال بقاعدة البيانات في المنطقة الأساسية.

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

التعافي:

  • تمكين تكرار المنطقة. من خلال تمكين تكرار المنطقة، تقوم قاعدة بيانات Azure SQL تلقائيا بنسخ عمليات الكتابة عبر مناطق توفر Azure متعددة داخل المناطق المدعومة. لمزيد من المعلومات، راجع توفر المنطقة المكررة.

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

    المتطلبات الأساسية: يجب تكوين قاعدة البيانات للنسخ المتماثل الجغرافي النشط. راجع النسخ المتماثل الجغرافي النشط لقاعدة بيانات SQL.

    تستخدم النسخة المتماثلة سلسلة اتصال مختلفة، لذلك ستحتاج إلى تحديث سلسلة الاتصال في التطبيق الخاص بك.

نفدت اتصالات العميل في تجمع الاتصال.

الكشف عن المشكلات. التقاط أخطاء System.InvalidOperationException.

التعافي:

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

التشخيصات. سجلات التطبيق.

الوصول إلى حد اتصال قاعدة البيانات.

الكشف عن المشكلات. يحد Azure SQL Database من عدد العمال المتزامنين وتسجيلات الدخول والجلسات. تعتمد الحدود على مستوى الخدمة. لمزيد من المعلومات، راجع حدود موارد قاعدة بيانات SQL.

للكشف عن هذه الأخطاء، قم بالتقاط System.Data.SqlClient.SqlException وتحقق من قيمة SqlException.Number لرمز خطأ SQL. للحصول على قائمة رموز الأخطاء ذات الصلة، راجع رموز الخطأ SQL لتطبيقات عميل قاعدة البيانات SQL: خطأ اتصال قاعدة البيانات والمشكلات الأخرى.

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

التشخيصات. - يقوم استعلام sys.event_log بإرجاع اتصالات قاعدة البيانات الناجحة، وفشل الاتصال، والتوقف التام.

Service Bus Messaging

فشلت قراءة رسالة من قائمة انتظار ناقل خدمة Microsoft Azure.

الكشف عن المشكلات. التقاط الاستثناءات من SDK للعميل. الفئة الأساسية لاستثناءات ناقل خدمة Microsoft Azure هي MessagingException. إذا كان الخطأ عابرًا، تكون الخاصية IsTransient صحيحة.

ولمزيد من المعلومات، راجع استثناءات المراسلة لناقل خدمة Microsoft Azure.

التعافي:

  1. إعادة المحاولة بعد حالات الفشل العابرة. راجع إرشادات إعادة محاولة ناقل خدمة Microsoft Azure.
  2. توضع الرسائل التي لا يمكن تسليمها إلى أي جهاز استقبال في قائمة انتظار غير مستخدمة. استخدم قائمة الانتظار لمعرفة الرسائل التي تعذر استلامها. لا يوجد تنظيف تلقائي لقائمة انتظار الرسائل غير المستخدمة. تبقى الرسائل هناك حتى تقوم باستردادها بشكل صريح. راجع نظرة عامة على قوائم انتظار Service Bus غير المستخدمة.

فشلت كتابة رسالة من قائمة انتظار ناقل خدمة Microsoft Azure.

الكشف عن المشكلات. التقاط الاستثناءات من SDK للعميل. الفئة الأساسية لاستثناءات ناقل خدمة Microsoft Azure هي MessagingException. إذا كان الخطأ عابرًا، تكون الخاصية IsTransient صحيحة.

ولمزيد من المعلومات، راجع استثناءات المراسلة لناقل خدمة Microsoft Azure.

التعافي:

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

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

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

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

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

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

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

الرسائل المكررة.

الكشف عن المشكلات. فحص خصائص MessageId و DeliveryCount للرسالة.

التعافي:

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

  • تمكين الكشف عن التكرارات، بإنشاء قائمة الانتظار وتعيين RequiresDuplicateDetection إلى خيار صحيح. باستخدام هذا الإعداد، يحذف ناقل خدمة Microsoft Azure تلقائيا أي رسالة يتم إرسالها بنفس MessageId على غرار الرسالة السابقة. لاحظ ما يلي:

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

التشخيصات. تسجيل الرسائل المكررة.

لا يمكن للتطبيق معالجة رسالة معينة من قائمة الانتظار.

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

التعافي:

هناك وضعان للفشل يجب مراعاتهما.

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

لمزيد من المعلومات، اطلع على "Overview of Service Bus dead-letter queues".

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

التخزين

فشل كتابة البيانات إلى Azure Storage

الكشف عن المشكلات. يتلقى العميل أخطاء عند الكتابة.

التعافي:

  1. أعد محاولة العملية، للتعافي من حالات الفشل العابرة. تعالج سياسة إعادة المحاولة هذا الأمر تلقائيًا في SDK العميل.

  2. تنفيذ نمط قاطع الدائرة لتجنب التخزين الزائد عن الحد.

  3. عند فشل إعادة المحاولة N، قم بإجراء تراجع آمن. على سبيل المثال:

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

التشخيصات. استخدم مقاييس تخزين.

فشل قراءة البيانات من Azure Storage.

الكشف عن المشكلات. يتلقى العميل أخطاء عند القراءة.

التعافي:

  1. أعد محاولة العملية، للتعافي من حالات الفشل العابرة. تعالج سياسة إعادة المحاولة هذا الأمر تلقائيًا في SDK العميل.
  2. بالنسبة لتخزين RA-GRS، حاول القراءة من نقطة النهاية الثانوية إذا فشلت القراءة من نقطة النهاية الأساسية. يمكن للعميل SDK التعامل مع هذا تلقائيا. راجع النسخ المتماثل لوحدة تخزين Azure .
  3. إذا فشلت محاولات إعادة المحاولة N، قم بعمل تراجع آمن. على سبيل المثال، إذا تعذر استرداد صورة منتج من التخزين، قم بعرض صورة عنصر نائب عام.

التشخيصات. استخدم مقاييس تخزين.

الجهاز الظاهري

فشل الاتصال بالجهاز الظاهري الخلفي.

الكشف عن المشكلات. أخطاء اتصال الشبكة.

التعافي:

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

التشخيصات. سجل الأحداث في حدود الخدمة.

يصبح مثيل الجهاز الظاهري غير متوفر أو غير سليم.

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

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

التشخيصات. - استخدام تحليلات سجل موازن التحميل.

  • تكوين نظام المراقبة لمراقبة جميع نقاط نهاية مراقبة السلامة.

يقوم عامل التشغيل عن طريق الخطأ بإيقاف تشغيل جهاز ظاهري.

الكشف عن المشكلات. ‏‫غير متوفر‬

الاسترداد. تعيين تأمين مورد بالمستوى ReadOnly. لمزيد من المعلومات، راجع تأمين الموارد باستخدام إدارة موارد Azure.

التشخيصات. استخدم سجلات نشاط Azure.

WebJobs

تتوقف المهمة المستمرة عن التشغيل عندما يكون مضيف SCM خاملًا.

الكشف عن المشكلات. تمرير رمز إلغاء إلى وظيفة WebJob. لمزيد من المعلومات، راجع إيقاف التشغيل بأمان.

الاسترداد. تمكين الإعداد Always On في تطبيق الويب. لمزيد من المعلومات، راجع تشغيل مهام الخلفية باستخدام WebJobs.

تصميم التطبيق

لا يمكن للتطبيق معالجة زيادة الطلبات الواردة.

الكشف عن المشكلات. يعتمد على التطبيق. وتشمل الأعراض النموذجية:

  • يبدأ موقع الويب في إرجاع رموز الخطأ HTTP 5xx.
  • تبدأ الخدمات التابعة، مثل قاعدة البيانات أو التخزين، في تقييد الطلبات. ابحث عن أخطاء HTTP مثل HTTP 429 (طلبات زائدة عن الحد)، حسب الخدمة.
  • زيادة قائمة انتظار Http.

التعافي:

  • توسيع النطاق للتعامل مع الحمل المتزايد.

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

التشخيصات. استخدم تسجيل تشخيص App Service. استخدم خدمة مثل تحليلات السجل Azure أو application Insights أو New Relic للمساعدة في فهم سجلات التشخيص.

تتوفر عينة هنا. يستخدم Polly لهذه الاستثناءات:

  • 429 - التقييد
  • 408 - المهلة
  • 401 – غير مصرح به
  • 503 أو 5xx - الخدمة غير متوفرة

فشل إحدى العمليات في سير العمل أو المعاملة الموزعة.

الكشف عن المشكلات. بعد إعادة المحاولة N، استمرار الفشل.

التعافي:

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

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

فشل استدعاء خدمة عن بعد.

الكشف عن المشكلات. رمز خطأ HTTP.

التعافي:

  1. إعادة المحاولة بعد حالات الفشل العابرة.
  2. إذا فشل الاستدعاء بعد محاولات N، اتخذ إجراء احتياطيا. (تطبيق محدد.)
  3. تنفيذ نمط قاطع الدائرة لتجنب حالات الفشل المتتالية.

التشخيصات. تسجيل جميع حالات فشل الاستدعاء عن بعد.

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

راجع المرونة والتبعيات في Azure Well-Architected Framework. يجب أن تكون عملية استعادة فشل البناء في النظام جزءًا من مرحلتي الهندسة المعمارية والتصميم من البداية لتجنب مخاطر الفشل.