مشاركة عبر

معالجة الخطأ العابر

  • مقالة

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

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

لماذا تحدث أخطاء عابرة في السحابة؟

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

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

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

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

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

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

التحديات

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

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

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

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

المبادئ التوجيهية العامة

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

تحديد ما إذا كانت هناك آلية إعادة محاولة مضمنة

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

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

تحديد ما إذا كانت العملية مناسبة لإعادة المحاولة

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

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

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

تحديد عدد مرات إعادة المحاولة المناسبة والفاصل الزمني

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

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

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

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

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

    • الفواصل الزمنية المنتظمة. التطبيق ينتظر نفس الفترة الزمنية بين كل محاولة. على سبيل المثال، قد يعيد محاولة العملية كل 3 ثوان.

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

    • العشوائية. يمكن أن تتضمن أي من إستراتيجيات إعادة المحاولة المدرجة سابقا عشوائيا لمنع مثيلات متعددة من العميل الذي يرسل محاولات إعادة المحاولة اللاحقة في نفس الوقت. على سبيل المثال، قد يعيد مثيل واحد محاولة العملية بعد 3 ثوان و11 ثانية و28 ثانية وما إلى ذلك، بينما قد يعيد مثيل آخر محاولة العملية بعد 4 ثوان و12 ثانية و26 ثانية وما إلى ذلك. العشوائية هي تقنية مفيدة يمكن دمجها مع استراتيجيات أخرى.

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

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

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

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

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

تجنب مضادات التناثر

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

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

  • لا تقم أبدًا بإجراء إعادة محاولة فورية أكثر من مرة.

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

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

اختبار استراتيجية إعادة المحاولة وتنفيذها

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

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

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

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

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

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

إدارة تكوينات نهج إعادة المحاولة

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

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

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

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

تسجيل الأخطاء العابرة وغير المتعنتة وتعقبها

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

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

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

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

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

إدارة العمليات التي تفشل باستمرار

  • ضع في اعتبارك كيفية التعامل مع العمليات التي تستمر في الفشل في كل محاولة. مواقف مثل هذه حتمية.

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

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

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

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

اعتبارات أخرى

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

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

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

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

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