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

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

في تلك اللحظات، كل الثقة التي بنيناها في نظامنا على مدار أشهر تبخرت. نحن، الفريق الذي كان يتباهى بأن نسبة عمل النظام (Uptime) لدينا 99.9%، وجدنا أنفسنا في حالة من الفوضى الحقيقية. بعد ساعات طويلة من التوتر والبحث المحموم، اكتشفنا السبب: خدمة طرف ثالث صغيرة، كنا نعتبرها ثانوية ومضمونة، توقفت عن العمل بشكل مفاجئ، وهذا التوقف الصغير تسبب في سلسلة من الانهيارات (Cascading Failure) أدت إلى شلل نظامنا بالكامل.

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

ما هي هندسة الفوضى (Chaos Engineering)؟ مش مجرد “طوشة” برمجية!

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

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

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

لماذا نحتاج لهذه “الفوضى المنظمة”؟ أليست الاختبارات كافية؟

هذا سؤال مهم جداً. كلنا نكتب اختبارات الوحدات (Unit Tests)، واختبارات التكامل (Integration Tests)، وحتى اختبارات التحمل (Load Tests). فلماذا نضيف طبقة أخرى من التعقيد؟

الجواب بسيط: الاختبارات التقليدية تتحقق من “المسارات المعروفة” و”السيناريوهات المتوقعة”.

• اختبار الوحدة: هل هذه الدالة الصغيرة تعمل كما هو متوقع؟
• اختبار التكامل: هل الخدمة (أ) تتحدث مع الخدمة (ب) بشكل صحيح؟
• اختبار التحمل: هل يستطيع النظام تحمل 10,000 مستخدم في نفس الوقت؟

لكن ماذا عن “المجهول غير المتوقع” (Unknown Unknowns)؟

• ماذا لو زاد زمن الاستجابة (Latency) في الشبكة فجأة بمقدار 200 ميلي ثانية؟
• ماذا لو توقفت إحدى قواعد البيانات الثانوية عن العمل؟
• ماذا لو استهلكت عملية أخرى موارد المعالج (CPU) بشكل مفاجئ؟
• ماذا لو حدث خطأ في شهادة SSL لواحدة من خدماتك الداخلية؟

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

مبادئ هندسة الفوضى: دليل أبو عمر العملي

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

1. ابدأ بتحديد “الحالة المستقرة” (Steady State)

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

مثال: بالنسبة لمتجر إلكتروني، الحالة المستقرة قد تكون:

• معدل إتمام الطلبات > 50 طلب في الدقيقة.
• متوسط زمن استجابة الـ API < 200ms.
• نسبة الأخطاء (HTTP 5xx) < 0.1%.

نصيحة أبو عمر: جهّز لوحة المراقبة (Dashboard) تبعتك وخلي عينك على هاي الأرقام. بدونها، أنت تقود وأنت أعمى.

2. ضع فرضية (Hypothesize)

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

مثال لفرضية: “نعتقد أنه إذا قمنا بإيقاف خادم الـ Cache بشكل مؤقت، سيزداد زمن استجابة الصفحات بنسبة 30%، لكن النظام لن ينهار وستبقى نسبة الأخطاء أقل من 1% لأن لدينا آلية Fallback للقراءة من قاعدة البيانات مباشرة.”

3. صمم ونفّذ التجربة (Run the Experiment)

هنا يبدأ الجزء الممتع. عليك الآن محاكاة الفشل الذي افترضته. الأهم هنا هو التحكم في “نصف قطر الانفجار” (Blast Radius)، أي التأكد من أن التجربة لن تخرج عن السيطرة.

• ابدأ صغيراً: جرب أولاً على بيئة التطوير (Dev) ثم بيئة الاختبار (Staging).
• قلل التأثير: عندما تنتقل لبيئة الإنتاج، ابدأ بجزء صغير جداً من الزيارات أو على خادم واحد فقط.
• استخدم أدوات: هناك أدوات رائعة تساعد في هذا المجال مثل Chaos Monkey (لإيقاف الخوادم عشوائياً)، وGremlin (منصة متكاملة)، وAWS Fault Injection Simulator (FIS).

مثال كود (مبسط): يمكنك حتى البدء بأدوات بسيطة على لينكس لمحاكاة بطء الشبكة باستخدام tc. (تحذير: لا تنفذ هذا على خادم إنتاج حي دون فهم كامل لتبعاته!).

# أمر لإضافة تأخير 300 ميلي ثانية على كل الحزم الخارجة من كرت الشبكة eth0
# هذا يحاكي شبكة بطيئة
sudo tc qdisc add dev eth0 root netem delay 300ms

# بعد انتهاء التجربة، لا تنسَ إزالة القاعدة!
sudo tc qdisc del dev eth0 root netem delay 300ms

4. تحقق من النتائج (Verify the Outcome)

بعد انتهاء التجربة، ارجع إلى لوحة المراقبة وقارن النتائج بفرضيتك.

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

5. حسّن النظام (Improve and Repeat)

إذا كشفت التجربة عن ضعف، فالخطوة التالية هي إصلاحه. قد يكون الإصلاح بإضافة آلية إعادة محاولة (Retry)، أو قاطع دارة (Circuit Breaker)، أو تحسين رسائل الخطأ، أو إضافة آلية Fallback. بعد الإصلاح، أعد التجربة مرة أخرى لتتأكد من أن المشكلة حُلّت فعلاً. هندسة الفوضى هي عملية مستمرة، وليست مشروعاً له بداية ونهاية.

نصائح من قلب المطبخ البرمجي

• المراقبة أولاً (Observability First): أكرر هذه النقطة لأهميتها. إذا ما بتقدر تشوف شو بصير، ما تعمل فوضى. استثمر في أدوات المراقبة (Monitoring)، تسجيل الأحداث (Logging)، والتتبع (Tracing) قبل أي شيء.
• الأتمتة هي صديقك: لا تجعلها مهمة يدوية. ادمج تجارب الفوضى ضمن الـ CI/CD Pipeline الخاص بك لتصبح جزءاً من ثقافة الفريق.
• ثقافة عدم اللوم (Blameless Culture): عندما تكشف تجربة ما عن مشكلة، الفريق لا يلوم الشخص الذي كتب الكود، بل يحتفل الجميع باكتشاف نقطة الضعف وإتاحة الفرصة لتقوية النظام.
• ابدأ بالبساطة: أول تجربة فوضى لك يمكن أن تكون بسيطة جداً، مثل إيقاف إحدى نسخ الخدمة يدوياً (إذا كان لديك أكثر من نسخة) ومراقبة ما يحدث. لا داعي للقفز إلى الأدوات المعقدة مباشرة.

الخلاصة: من الثقة الزائفة إلى المرونة الحقيقية 🚀

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

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