فشل خدمة واحدة كان يُسقط نظامنا بأكمله: كيف أنقذنا ‘نمط قاطع الدائرة’ من جحيم الفشل المتتالي؟

يا أهلاً وسهلاً فيكم جميعاً، معكم أبو عمر.

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

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

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

ما هو الفشل المتتالي (Cascading Failure)؟ ولماذا هو كابوس المطورين؟

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

في الأنظمة الحديثة المبنية على الخدمات المصغرة (Microservices)، تتواصل الخدمات مع بعضها البعض باستمرار. خدمة المستخدمين تطلب بيانات من خدمة الطلبات، وخدمة الطلبات تتواصل مع خدمة الدفع، وخدمة الدفع تتواصل مع بوابة دفع خارجية. ماذا يحدث لو أن بوابة الدفع الخارجية أصبحت بطيئة أو توقفت عن العمل؟

1. خدمة الدفع سترسل طلباً وتنتظر الرد.
2. أثناء انتظارها، هي تحجز موارد (اتصال شبكة، عامل/Thread).
3. إذا جاء طلب دفع آخر، ستحجز موارد جديدة.
4. مع استمرار فشل بوابة الدفع، ستستنفد خدمة الدفع كل مواردها المتاحة وهي تنتظر ردوداً لن تأتي أبداً.
5. عندما تستنفد مواردها، تتوقف خدمة الدفع عن الاستجابة.
6. الآن، خدمة الطلبات التي تعتمد على خدمة الدفع تبدأ في مواجهة نفس المشكلة… وهكذا ينتشر الفشل كالنار في الهشيم حتى ينهار النظام بأكمله.

هذا هو الكابوس الذي نخشاه جميعاً: انهيار كامل بسبب مشكلة صغيرة في جزء واحد من النظام.

الحل السحري: نمط قاطع الدائرة (Circuit Breaker Pattern)

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

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

حالات قاطع الدائرة الثلاث

يعمل قاطع الدائرة من خلال التنقل بين ثلاث حالات رئيسية:

• الحالة المغلقة (Closed):
  هذا هو الوضع الطبيعي. يتم توجيه الطلبات إلى الخدمة البعيدة كالمعتاد. يحتفظ قاطع الدائرة بعدّاد لعدد مرات الفشل. إذا نجح الطلب، يتم إعادة تعيين هذا العداد. إذا فشل، يزداد العداد. عندما يصل عدد مرات الفشل المتتالية إلى حد معين (مثلاً، 5 مرات فشل في الدقيقة)، ينتقل قاطع الدائرة إلى الحالة “المفتوحة”.
• الحالة المفتوحة (Open):
  هنا يحدث السحر. عندما يكون القاطع “مفتوحاً”، فإن أي طلب جديد يفشل على الفور دون محاولة الاتصال بالخدمة المتعثرة. هذا يريح نظامنا بشكل كبير. بدلاً من الانتظار 30 ثانية لكل طلب، نحصل على فشل فوري في أجزاء من الثانية. يبقى القاطع في هذه الحالة لمدة زمنية محددة مسبقاً (مثلاً، 60 ثانية).
• الحالة نصف المفتوحة (Half-Open):
  بعد انتهاء مهلة “الفتح”، لا يعود القاطع مباشرة إلى الحالة “المغلقة”. بدلاً من ذلك، يدخل في حالة حذرة تسمى “نصف مفتوحة”. في هذه الحالة، يسمح لطلب واحد فقط بالمرور إلى الخدمة البعيدة كاختبار.
  • إذا نجح هذا الطلب: يعتبر القاطع أن الخدمة قد تعافت ويعود إلى الحالة “المغلقة” ويعيد تعيين عداد الفشل.
  • إذا فشل هذا الطلب: يستنتج القاطع أن المشكلة لا تزال قائمة، فيعود مرة أخرى إلى الحالة “المفتوحة” ويبدأ مؤقت المهلة من جديد.

هذه الآلية الذكية تجعل النظام مرناً وقادراً على “شفاء نفسه” ذاتياً دون تدخل يدوي.

لنطبق الأمر عملياً: مثال برمجي بلغة Python

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

أولاً، قم بتثبيت المكتبة:

pip install pybreaker

الآن، تخيل أن لدينا خدمة خارجية غير مستقرة. سنحاكيها بدالة تنجح أحياناً وتفشل أحياناً أخرى.

import time
import random
from pybreaker import CircuitBreaker, CircuitBreakerError

# 1. إعداد قاطع الدائرة
# سيفصل القاطع إذا فشلت العملية 3 مرات
# وسيبقى مفصولاً لمدة 10 ثوانٍ
breaker = CircuitBreaker(fail_max=3, reset_timeout=10)

# 2. خدمة خارجية غير مستقرة (لأغراض التوضيح)
def call_flaky_service():
    """
    هذه الدالة تحاكي الاتصال بخدمة قد تفشل.
    في الواقع، قد تكون هذه الدالة عبارة عن طلب HTTP لخدمة أخرى.
    """
    if random.random() > 0.6:
        print("--> الخدمة استجابت بنجاح!")
        return "Success"
    else:
        print("--> فشل في الاتصال بالخدمة!")
        raise IOError("Service is down")

# 3. استخدام قاطع الدائرة لحماية استدعاء الخدمة
print("--- بدء محاكاة استدعاء الخدمة ---")
for i in range(15):
    try:
        # نستخدم @breaker.call لتنفيذ الدالة من خلال قاطع الدائرة
        result = breaker.call(call_flaky_service)
        print(f"الطلب رقم {i+1}: النتيجة = {result}n")
    except CircuitBreakerError:
        # هذا الخطأ يحدث عندما يكون القاطع "مفتوحاً"
        print(f"الطلب رقم {i+1}: فشل فوري! الدائرة مفتوحة.n")
    except IOError as e:
        # هذا الخطأ يأتي من الدالة نفسها عندما يكون القاطع "مغلقاً" أو "نصف مفتوح"
        print(f"الطلب رقم {i+1}: فشل في الخدمة: {e}n")
    
    time.sleep(1)

إذا قمت بتشغيل هذا الكود، ستلاحظ سلوكاً مثيراً للاهتمام:

1. في البداية، ستمر بعض الطلبات وتفشل أخرى (الدائرة مغلقة).
2. بعد 3 محاولات فاشلة، سترى رسالة “فشل فوري! الدائرة مفتوحة.” لعدة طلبات متتالية. هذا هو القاطع وهو في الحالة المفتوحة، يحمي نظامك.
3. بعد 10 ثوانٍ، سيحاول القاطع إرسال طلب واحد (الحالة نصف المفتوحة).
4. إذا نجح، ستعود الدائرة للحالة المغلقة. إذا فشل، ستعود للحالة المفتوحة مرة أخرى.

نصائح أبو عمر الذهبية لتطبيق قاطع الدائرة

بعد سنوات من التعامل مع هذه الأنماط، اسمحوا لي أن أقدم لكم بعض النصائح العملية التي تعلمتها بالطريقة الصعبة:

1. لا تفرط في الاستخدام

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

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

2. اضبط إعداداتك بحكمة

الأرقام السحرية (fail_max و reset_timeout) هي قلب وروح قاطع الدائرة. اختيار قيم سيئة يمكن أن يأتي بنتائج عكسية.

نصيحة عملية: ابدأ بقيم متحفظة. مثلاً، fail_max=5 و reset_timeout=60 ثانية. ثم راقب سلوك النظام. هل القاطع “يفصل” كثيراً؟ ربما تحتاج لزيادة fail_max. هل الخدمة تتعافى أسرع من 60 ثانية؟ يمكنك تقليل reset_timeout. الضبط يعتمد على طبيعة الخدمة وأهميتها.

3. ماذا تفعل عندما يكون القاطع مفتوحاً؟ (Fallback)

الفشل الفوري أفضل من الانتظار، لكن الأفضل منه هو تقديم تجربة مستخدم لائقة حتى أثناء الفشل. هذا ما نسميه “الاستراتيجية البديلة” أو (Fallback).

عندما يرمي قاطع الدائرة خطأ CircuitBreakerError، لا تعرض للمستخدم رسالة خطأ تقنية. بدلاً من ذلك، قم بتنفيذ إجراء بديل:

• خدمة التوصيات فشلت؟ اعرض قائمة بالمنتجات الأكثر مبيعاً بشكل عام (بيانات محفوظة مسبقاً أو Cached).
• خدمة البحث فشلت؟ اعرض رسالة لطيفة تقترح على المستخدم المحاولة لاحقاً أو تصفح الأقسام يدوياً.
• بوابة الدفع فشلت؟ اعرض رسالة “نواجه ضغطاً حالياً، يرجى المحاولة بعد دقائق” أو اعرض بوابة دفع بديلة إن وجدت.

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

4. الرصد والتنبيهات هما عيناك اللتان لا تنامان

قاطع الدائرة ليس حلاً سحرياً تضعه وتنساه. يجب أن يكون جزءاً من نظام المراقبة (Monitoring) الخاص بك. يجب أن تقوم بـ:

• تسجيل تغييرات الحالة: سجل (Log) كل مرة ينتقل فيها القاطع من حالة لأخرى (خاصة عند انتقاله إلى “مفتوح”).
• إرسال تنبيهات: قم بإعداد تنبيه (Alert) يُرسل لفريق التطوير فوراً عندما “يفتح” قاطع دائرة مهم. هذا مؤشر مبكر وقوي جداً على وجود مشكلة في خدمة ما، وقد يتيح لك التدخل قبل أن يلاحظ العملاء أي شيء.

الخلاصة: من الفوضى إلى المرونة ✅

في عالم الأنظمة الموزعة المعقد، لم يعد السؤال “هل ستفشل خدمتي؟” بل “متى ستفشل وكيف سأتعامل مع هذا الفشل؟”. الفشل حتمي، ولكن الانهيار الكامل هو خيار يمكننا تجنبه.

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

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