كنا ننتظر الكارثة لتقع: كيف أنقذتنا ‘هندسة الفوضى’ (Chaos Engineering) من جحيم الأعطال غير المتوقعة؟

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

قضينا أسابيع في الاختبارات على بيئة الـ Staging (بيئة الاختبار الشبيهة بالإنتاج)، كل شي كان شغال “زي الليرة”. الاختبارات الوظيفية، اختبارات التحمل (Load Testing)، كله تمام التمام. إحنا كفلسطينية، بنحب شغلنا يكون متكتك ومتقن، وكنت حاسس بفخر كبير بالفريق وباللي أنجزناه.

جاء يوم الإطلاق. ضغطنا الزر… والموقع انطلق. أول ساعة كانت احتفالات وفرحة. لكن فجأة، بدأت التنبيهات تنهال علينا زي المطر. “High CPU Usage”, “503 Service Unavailable”, “Database Connection Timeout”. الله وكيلكم، كأنو حدا كبّ علينا سطل مي باردة. الموقع صار بطيئًا جدًا، وبعدها وقع تمامًا.

قضينا الـ 12 ساعة التالية في “غرفة حرب” افتراضية، بنحاول نفهم شو اللي بصير. الكارثة كانت إنه سبب المشكلة ما كان في الخدمات الأساسية (المنتجات، الدفع…)، بل في خدمة صغيرة ومهمشة كنا بنستخدمها لتتبع سلوك المستخدمين (Analytics). هاي الخدمة صار عليها ضغط ما توقعناه، فصارت بطيئة، وبسبب خطأ بسيط في تصميمنا، كل طلب لصفحة منتج كان ينتظر رد هاي الخدمة البطيئة، مما أدى لانهيار كل شي وراها (Cascading Failure). كنا ننتظر الكارثة لتقع، ونحن لا ندري.

بعد ما حلينا المشكلة (بشكل مؤقت طبعًا، بس فصلنا الخدمة المشبوهة)، جلست مع نفسي وسألت: “كيف ما شفناها؟ كيف كل اختباراتنا ما كشفت هاي المشكلة؟”. الجواب كان بسيطًا ومؤلمًا: لأننا لم نحاول كسر نظامنا بأنفسنا بالطريقة الصحيحة. ومن هنا بدأت رحلتي مع ما يسمى بـ “هندسة الفوضى”.

شو هي ‘هندسة الفوضى’ بالزبط؟ هل هي مجرد تخريب؟

لما يسمع الواحد مصطلح “هندسة الفوضى” (Chaos Engineering)، أول شي بيخطر بباله هو مجموعة من المبرمجين المجانين اللي بيكسّروا في السيرفرات وبيفصلوا الكوابل بشكل عشوائي. الحقيقة أبعد ما يكون عن هيك.

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

لاحظوا الكلمات المهمة: “تجارب مضبوطة”، “بناء الثقة”، “تحمل الظروف”. الفكرة مش التخريب العشوائي، بل هي منهج علمي لاكتشاف نقاط الضعف.

الفكرة مش تخريب، الفكرة لقاح!

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

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

ليش لازم نهتم؟ المبادئ الأساسية لهندسة الفوضى

في الأنظمة الحديثة المعقدة (Microservices, Cloud-native)، الفشل ليس احتمالًا، بل هو حقيقة لا مفر منها. الخوادم ستتعطل، الشبكات ستصبح بطيئة، والخدمات ستتوقف عن الاستجابة. السؤال ليس “هل سيفشل النظام؟” بل “ماذا سيحدث عندما يفشل النظام؟”. هندسة الفوضى تساعدنا على الإجابة على هذا السؤال بثقة.

الخطوات الأربعة لتجربة الفوضى

أي تجربة فوضى علمية تتبع أربع خطوات أساسية:

1. تحديد الحالة المستقرة (Steady State): ابدأ بتعريف كيف يبدو “السلوك الطبيعي” لنظامك. قد يكون هذا مقاييس تقنية (مثل معدل استجابة الـ API أقل من 200ms) أو مقاييس عمل (مثل عدد الطلبات المكتملة في الدقيقة).
2. صياغة فرضية (Hypothesize): ضع فرضية حول ما سيحدث. على سبيل المثال: “نعتقد أن النظام سيظل في حالته المستقرة (الصفحات ستُعرض بشكل طبيعي) حتى لو فشلت خدمة التوصيات بشكل كامل، لأننا بنينا آلية احتياطية (Fallback)”.
3. حقن الفشل (Introduce Real-World Events): هنا يأتي الجزء الممتع. قم بمحاكاة أعطال حقيقية. أوقف الخادم الذي تعمل عليه خدمة التوصيات، أو زد من زمن الاستجابة (Latency) للشبكة بين الخدمات.
4. التحقق من الفرضية (Verify): راقب النظام. هل بقيت الحالة المستقرة كما هي؟ هل انهارت فرضيتك؟ إذا انهارت، فهذا رائع! لقد وجدت للتو نقطة ضعف حقيقية يمكنك إصلاحها قبل أن يكتشفها عملاؤك في أسوأ وقت ممكن.

يلا نطبق عملي: مثال بسيط يوضح الفكرة

لنعد إلى قصة منصة التجارة الإلكترونية. لنتخيل أن لدينا خدمتين أساسيتين (Microservices):

• ProductService: مسؤولة عن عرض تفاصيل المنتج (الاسم، السعر، الصورة).
• ReviewService: مسؤولة عن جلب تقييمات المنتج من قاعدة بيانات أخرى.

صفحة المنتج تستدعي كلتا الخدمتين لتعرض صفحة كاملة للمستخدم.

سيناريو “سقوط خدمة التقييمات”

باستخدام هندسة الفوضى، سنصمم التجربة التالية:

• الحالة المستقرة: صفحة المنتج يتم تحميلها بالكامل في أقل من 500ms.
• الفرضية: “نعتقد أنه إذا توقفت ReviewService عن العمل، ستظل صفحة المنتج تُحمَّل، ولكن بدون قسم التقييمات، وستبقى سرعة التحميل ضمن الحدود الطبيعية”.
• حقن الفشل: سنستخدم أداة (مثل Chaos Mesh أو حتى iptables) لمنع الاتصال بين ProductService و ReviewService.

الكود الذي كان سينقذنا (قبل وبعد)

قبل هندسة الفوضى، ربما كان الكود في ProductService يبدو هكذا (مثال بلغة Go):

// الكود السيء الذي يسبب الكارثة
func getProductPageData(productID string) {
    // ... جلب تفاصيل المنتج الأساسية ...

    // استدعاء خدمة التقييمات وانتظارها إلى الأبد!
    reviews := reviewServiceClient.GetReviews(productID) // هذه الدالة قد تعلق هنا

    // ... عرض الصفحة مع المنتج والتقييمات ...
}

عند إجراء تجربة الفوضى، سنكتشف أن reviewServiceClient.GetReviews ستستمر في المحاولة إلى أن تنتهي مهلة الاتصال (Timeout) الطويلة جدًا، مما يتسبب في تعليق الطلب بأكمله وانهيار النظام تحت الضغط.

بعد اكتشاف المشكلة، سنقوم بتطبيق نمط تصميم يسمى “Circuit Breaker” أو ببساطة إضافة مهلة زمنية قصيرة وآلية احتياطية:

// الكود المرن بعد تجربة الفوضى
func getProductPageData(productID string) {
    // ... جلب تفاصيل المنتج الأساسية ...

    // إنشاء قناة لاستقبال التقييمات
    reviewChan := make(chan []Review)

    go func() {
        // استدعاء خدمة التقييمات في goroutine منفصلة
        reviews, err := reviewServiceClient.GetReviews(productID)
        if err != nil {
            reviewChan <- nil // إرسال قيمة فارغة في حال الفشل
            return
        }
        reviewChan <- reviews
    }()

    var reviews []Review
    select {
    case res := <-reviewChan:
        reviews = res // استقبلنا التقييمات بنجاح
    case <-time.After(250 * time.Millisecond):
        // انتهت المهلة! لا تنتظر أكثر، استمر بدون تقييمات
        log.Println("Review service timed out. Serving page without reviews.")
        reviews = []Review{} // اعرض قسم تقييمات فارغ
    }

    // ... عرض الصفحة مع المنتج والتقييمات (أو بدونها) ...
}

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

نصائح أبو عمر الذهبية للبدء بهندسة الفوضى

هل تحمست للفكرة؟ ممتاز. لكن تذكر، لا تركض قبل أن تتعلم المشي. إليك بعض النصائح العملية من خبرتي:

1. ابدأ صغيرًا وفي بيئة الاختبار: لا تطلق “قرد الفوضى” (Chaos Monkey) على بيئة الإنتاج في يومك الأول! ابدأ في بيئة الـ Staging. جرب إيقاف خدمة غير حرجة يدويًا وشاهد ما يحدث.
2. قلل نصف القطر الانفجاري (Blast Radius): ابدأ تجاربك على جزء صغير جدًا من النظام. ربما على خادم واحد فقط، أو على مستخدمين داخليين فقط. ثم قم بتوسيع النطاق تدريجيًا كلما زادت ثقتك.
3. نظم “أيام اللعب” (GameDays): خصص بضع ساعات كل شهر ليجتمع فيها فريقك (المطورون، مهندسو العمليات SRE، مدراء المنتجات) لإجراء تجارب فوضى بشكل يدوي. الهدف هو بناء ذاكرة عضلية للفريق في التعامل مع الأعطال.
4. الأتمتة هي الهدف النهائي: بعد أن تصبح مرتاحًا مع التجارب اليدوية، ابدأ في أتمتة هذه التجارب باستخدام أدوات مثل Chaos Mesh, Gremlin, أو حتى كتابة نصوصك البرمجية الخاصة. الهدف هو أن تصبح هذه التجارب جزءًا من دورة التطوير والنشر (CI/CD).

الخلاصة: اكسر نظامك بنفسك قبل أن يكسره الواقع 🔧

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

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

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