نظام سريع التعطل

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

تُعد الأنظمة أو الوحدات التي تفشل بسرعة مرغوبة في العديد من الظروف:

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

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

شاع استخدام هذا المصطلح كاستعارة في عالم الأعمال، ويعود تاريخه إلى عام 2001 على الأقل، ^{[ 1 ]} بمعنى أن على الشركات أن تُجري تجارب جريئة لتحديد جدوى منتج أو استراتيجية على المدى الطويل، بدلاً من التريث واستثمار سنوات في نهج محكوم عليه بالفشل. وقد أصبح هذا المصطلح بمثابة شعار في ثقافة الشركات الناشئة ، أي "افشل بسرعة، افشل كثيراً". ^{[ 2 ]}

• برنامج خاص بحالات الأعطال فقط
• التصميم بموجب عقد
• الفشل الذريع مقابل الفشل الجيد
• نظام أمان ضد الأعطال
• إيقاف الفشل
• نظام صامت عند حدوث عطل

• غراي، جيم (1985). " لماذا تتوقف أجهزة الكمبيوتر وما العمل حيال ذلك؟" . CiteSeerX 10.1.1.110.9127 تقديم برنامج "الفشل السريع"
• مقال "الفشل السريع" بقلم جيم شور يشرح استخدام مفهوم "الفشل السريع" في تطوير البرمجيات (من "أعمدة لبرمجيات IEEE" التي حررها مارتن فاولر )