السلام عليكم يا جماعة الخير، معكم أخوكم أبو عمر.
اسمحوا لي أن أرجع بالذاكرة لبضع سنوات، إلى ليلة لن أنساها ما حييت. كنا على وشك إطلاق ميزة انتظرها المستخدمون بفارغ الصبر. الفريق كله كان سهرانًا، الأكواب المليئة بالقهوة كانت أكثر من عدد الشاشات المفتوحة، والثقة كانت تملأ الأجواء. لقد قمنا بكل أنواع الاختبارات: اختبارات الوحدة (Unit Tests)، اختبارات التكامل (Integration Tests)، واختبارات الحمل (Load Tests). كل المؤشرات كانت خضراء، والنظام كان يبدو صامدًا كجبل.
ضغطنا على زر الإطلاق… وفي الدقائق الأولى، كان كل شيء مثاليًا. بدأت أرقام المستخدمين النشطين بالارتفاع، والبيانات تتدفق بسلاسة. ثم، فجأة، بدأت التنبيهات تصرخ كصافرات الإنذار في ليلة هادئة. خدمة صغيرة، تبدو غير مهمة، مسؤولة عن إرسال إشعارات الترحيب، توقفت عن الاستجابة بسبب ضغط بسيط من واجهة برمجية خارجية (Third-party API). “مش مشكلة كبيرة”، قلنا لأنفسنا، “مجرد إشعارات”.
لكننا كنا مخطئين… خطأً فادحًا. الخدمة الرئيسية، التي تعتمد على هذه الخدمة الصغيرة، بدأت بإعادة محاولات الاتصال بها بشكل مجنون وغير منضبط. كل إعادة محاولة كانت تفتح اتصالاً جديداً وتستهلك جزءًا من الذاكرة. في غضون دقائق، تضخمت قائمة الانتظار، واستُهلكت كل موارد الخادم. هذا الضغط انتقل بدوره إلى قاعدة البيانات التي بدأت ترفض الاتصالات الجديدة. فجأة، لم يعد النظام بطيئًا فحسب، بل انهار بالكامل. ما بدأ كعطل في خدمة هامشية تحول إلى انهيار متتالٍ (Cascading Failure) أسقط القلعة بأكملها.
تلك الليلة، ونحن نحاول يائسين إعادة النظام للعمل قطعة قطعة، شعرت بمزيج من الإحباط والتساؤل. كيف حدث هذا؟ لقد اختبرنا كل شيء! وهنا كانت الصدمة: نحن اختبرنا السيناريوهات “المتوقعة”، لكننا لم نختبر “الفوضى” الحقيقية التي تحدث في العالم الواقعي. من رحم تلك المعاناة، بدأت رحلتي مع ما يُعرف بـ “هندسة الفوضى”.
ما هي هندسة الفوضى (Chaos Engineering) بالضبط؟
كثيرون عندما يسمعون هذا المصطلح يظنون أننا مجموعة من المبرمجين المجانين الذين يستمتعون بتخريب الأنظمة عمدًا. القصة وما فيها أن هندسة الفوضى هي عكس ذلك تمامًا. هي ليست فوضى، بل هي علم منضبط لاكتشاف نقاط الضعف في نظامك قبل أن يكتشفها المستخدمون في أسوأ وقت ممكن.
ببساطة، هندسة الفوضى هي إجراء تجارب مُتحكّم بها على نظامك للكشف عن نقاط ضعفه الخفية وبناء ثقة حقيقية في قدرته على الصمود أمام الظروف غير المتوقعة.
فكر فيها كأنها لقاح لنظامك. نحن نحقن جرعة صغيرة ومُسيطَر عليها من “الفشل” (مثل إيقاف خدمة، أو زيادة زمن الاستجابة للشبكة) لنرى كيف يتفاعل الجسم (النظام بأكمله)، ومن ثم نقوي مناعته.
الفرق بينها وبين الاختبارات التقليدية
قد يقول قائل: “يا أبو عمر، ما هذا نفس اختبارات الفشل (Failure Testing)”. والجواب هو: لا، مش بالضبط. الاختبارات التقليدية تتحقق من حالات معروفة ومتوقعة: “هل يستطيع النظام التعامل مع 1000 مستخدم في نفس الوقت؟”. أما هندسة الفوضى فتسأل سؤالًا مختلفًا وأكثر عمقًا: “هل سيبقى النظام صامدًا إذا انقطعت الشبكة فجأة عن نصف خوادمنا في مركز البيانات الأوروبي؟”. إنها تبحث عن “المجهول غير المتوقع” (Unknown Unknowns).
كيف نبدأ رحلتنا مع هندسة الفوضى؟ (خطوات عملية)
جميل، تحمست للفكرة وتريد تطبيقها. ممتاز! لكن مهلًا، لا تذهب وتغلق خادم قاعدة البيانات في بيئة الإنتاج مباشرة! (لا تفعلها، أتحدث بجدية). الأمر يتطلب منهجية. إليك الخطوات التي نتبعها:
الخطوة الأولى: تحديد الحالة المستقرة (Steady State)
قبل أن تُحدث أي فوضى، يجب أن تعرف كيف يبدو “الوضع الطبيعي”. حدد مؤشرات الأداء الرئيسية (KPIs) التي تدل على أن نظامك بصحة جيدة. قد تكون هذه المؤشرات:
- معدل الأخطاء (Error Rate) أقل من 1%.
- زمن الاستجابة (Latency) للطلبات أقل من 200ms.
- عدد الطلبات في الثانية (Throughput) ضمن النطاق الطبيعي.
هذه هي “نبضات قلب” نظامك. هدفنا من التجربة هو التأكد من أن هذه النبضات تبقى مستقرة قدر الإمكان رغم الفوضى التي سنحدثها.
الخطوة الثانية: صياغة فرضية
هنا يبدأ العلم. ضع فرضية واضحة وقابلة للقياس. على سبيل المثال:
“نعتقد أنه إذا قمنا بإيقاف خدمة الدفع (Payment Service) بشكل مفاجئ، فإن النظام سيعطل ميزة الشراء مؤقتًا ويعرض رسالة لطيفة للمستخدم، بينما تبقى بقية وظائف الموقع (مثل تصفح المنتجات) تعمل بشكل كامل دون أي تأثر في الأداء.”
لاحظ كيف أن الفرضية محددة جدًا. نحن لا نقول “إذا فشلت خدمة الدفع، لن ينهار كل شيء”. نحن نحدد السلوك المتوقع بالتفصيل.
الخطوة الثالثة: تصميم وتنفيذ التجربة
هنا يبدأ الأكشن. يجب أن تكون التجربة محدودة التأثير (Small Blast Radius). ابدأ دائمًا في بيئة الاختبار (Staging)، ومع مجموعة صغيرة من الخوادم أو حتى نسبة ضئيلة من المستخدمين إذا كنت جريئًا وتعمل على بيئة الإنتاج.
يمكنك استخدام أدوات متخصصة مثل Chaos Mesh أو Gremlin، أو حتى كتابة سكربت بسيط. على سبيل المثال، إذا كنت تستخدم Docker و Kubernetes، يمكنك محاكاة فشل خدمة بقتل حاويتها (Pod):
# تحذير: لا تنفذ هذا الأمر على نظام لا تفهمه بالكامل!
# هذا مجرد مثال توضيحي
# 1. احصل على اسم الـ Pod الذي تريد إيقافه
POD_NAME=$(kubectl get pods -l app=payment-service -o jsonpath='{.items[0].metadata.name}')
# 2. اطرح فرضيتك: "إذا قُتل هذا الـ Pod، يجب أن يقوم Kubernetes بإعادة تشغيله تلقائيًا في غضون 30 ثانية، والنظام يجب أن يتعامل مع الخطأ برشاقة"
echo "💣 محاكاة فشل مفاجئ لخدمة الدفع. إيقاف الـ Pod: $POD_NAME"
# 3. تنفيذ الفوضى (حذف الـ Pod)
kubectl delete pod $POD_NAME
echo "⏳ نراقب الآن سلوك النظام..."
# ... هنا تقوم بمراقبة لوحات المراقبة (Dashboards) الخاصة بك ...
الأمر لا يقتصر على إيقاف الخدمات. يمكنك محاكاة:
- زيادة زمن الاستجابة (Latency): ماذا لو أصبح الاتصال بقاعدة البيانات بطيئًا؟
- استهلاك الموارد: ماذا لو استهلكت إحدى الخدمات كل الـ CPU أو الذاكرة؟
- فشل الشبكة: ماذا لو لم تتمكن خدمة A من الوصول لخدمة B؟
الخطوة الرابعة: القياس والتحقق من الفرضية
أثناء وبعد التجربة، راقب مؤشرات الحالة المستقرة التي حددتها في الخطوة الأولى. هل تحققت فرضيتك؟
- إذا نعم: رائع! لقد أثبتت أن نظامك صامد في هذا السيناريو. عزز هذه النتيجة ووثقها.
- إذا لا: أروع! لقد وجدت نقطة ضعف حقيقية في بيئة آمنة ومتحكم بها، وليس أثناء ذروة استخدام العملاء. هذا هو الكنز الحقيقي لهندسة الفوضى.
الخطوة الخامسة: الإصلاح والتحسين
الآن بعد أن وجدت نقطة الضعف، حان وقت العمل. هل تحتاج إلى إضافة آلية “قاطع الدائرة” (Circuit Breaker)؟ هل تحتاج إلى تحسين سياسة إعادة المحاولة (Retry Policy) لتجنب العصف على الخدمات الأخرى؟ هل تحتاج إلى نظام تراجع (Fallback) يعرض بيانات قديمة بدلًا من رسالة خطأ؟ قم بالإصلاح، ثم أعد التجربة لتتأكد من أن الإصلاح يعمل كما هو متوقع.
نصائح من قلب التجربة (من مطبخ أبو عمر)
- ابدأ صغيرًا جدًا: أول تجربة لك لا يجب أن تكون إغلاق نصف مركز البيانات. جرب حقن تأخير بمقدار 50ms لخدمة غير حرجة.
- أعلن عن تجاربك: لا تكن “العميل السري”. أخبر فريقك أنك ستجري “يوم فوضى” (GameDay) في وقت محدد. هذا يمنع الذعر ويجعل الجميع جزءًا من عملية التعلم.
- اجعل الإيقاف سهلاً: يجب أن يكون لديك دائمًا “زر أحمر كبير” لإيقاف التجربة فورًا إذا خرجت الأمور عن السيطرة.
- ركز على التأثير على المستخدم: الهدف النهائي ليس فقط منع الخوادم من الانهيار، بل ضمان أن تجربة المستخدم تبقى جيدة قدر الإمكان حتى في ظل الظروف الصعبة.
- الأتمتة هي الهدف الأسمى: في النهاية، يجب أن تصبح هذه التجارب جزءًا من خط أنابيب النشر والتكامل المستمر (CI/CD)، تعمل تلقائيًا لتضمن أن أي تغيير جديد لا يُدخل نقاط ضعف جديدة.
الخلاصة: من الفوضى إلى الثقة 💪
الرحلة من تلك الليلة المظلمة المليئة بالانهيارات إلى اليوم الذي نجري فيه تجارب الفوضى على بيئة الإنتاج بثقة كانت طويلة ومليئة بالدروس. هندسة الفوضى غيرت طريقة تفكيرنا جذريًا. لم نعد نسأل “هل سينجح النظام؟”، بل أصبحنا نسأل “كيف سيفشل، وكيف يمكننا الصمود عند فشله؟”.
إنها ليست مجرد تقنية، بل هي ثقافة. ثقافة تقبل الفشل كفرصة للتعلم، والبحث الاستباقي عن نقاط الضعف بدلًا من انتظارها لتفاجئنا. تذكروا يا جماعة، النظام القوي ليس هو الذي لا يفشل أبدًا، بل هو الذي يتعافى من الفشل برشاقة وقوة، ويجعل التجربة تبدو سلسة للمستخدم حتى في قلب العاصفة.
لا تخافوا من الفوضى، بل تعلموا كيف تهندسونها لصالحكم. صدقوني، النوم ليلًا يصبح أسهل بكثير.
