يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.
خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علمتني درسًا قاسيًا لكنه ثمين. كنا في الشركة على وشك إطلاق منتج جديد، تطبيق ضخم اشتغلنا عليه ليل نهار لأكثر من سنة. الكل كان متوتر ومتحمس، وخصوصًا أنا، كوني قائد الفريق التقني. ليلة الإطلاق، كانت ليلة خميس، والكل متوقع ضغط كبير على السيرفرات.
بدأ الإطلاق، الأرقام بدأت ترتفع، المستخدمون يتدفقون… وفجأة، بدأت التنبيهات تصرخ كأنها في حالة حرب. أولًا، قاعدة البيانات الرئيسية بدأت تستجيب ببطء شديد. ثم، إحدى الخدمات الصغيرة (microservice) المسؤولة عن توثيق الدخول توقفت عن العمل تمامًا. خلال دقائق، حدث ما يُعرف بـ “الانهيار المتتالي” (Cascading Failure). خدمة أسقطت خدمة، والنظام بأكمله انهار كبيت من ورق. قضينا ليلة الخميس كلها واحنا بنحاول نصلح ونطفي حرايق، والمستخدمين غاضبون، والإدارة بتضغط. كانت بحق “ليلة الخميس الحزينة”.
بعد ما هدأت العاصفة، قعدنا مع الفريق نسأل حالنا: “شو اللي صار؟ إحنا عملنا كل أنواع الاختبارات!”. عملنا اختبارات الوحدة (Unit Tests)، واختبارات التكامل (Integration Tests)، وحتى اختبارات الأداء (Performance Tests). لكننا اكتشفنا أننا كنا نختبر “السيناريو المثالي”، ولم نكن مستعدين أبدًا لـ”فوضى” العالم الحقيقي. من هنا، بدأت رحلتنا مع مفهوم غيّر طريقة تفكيرنا بالكامل: هندسة الفوضى.
ما هي هندسة الفوضى (Chaos Engineering)؟ مش مجرد تخريب!
لما تسمع كلمة “فوضى”، يمكن أول إشي يخطر في بالك هو التخريب العشوائي. لكن في عالم البرمجيات، هندسة الفوضى هي العكس تمامًا. هي مش فوضى، هي “علم الفوضى المنظم”.
هندسة الفوضى (Chaos Engineering): هي عملية إجراء تجارب مدروسة ومنظمة على نظامك البرمجي في بيئة الإنتاج (Production) أو بيئة شبيهة بها، بهدف بناء الثقة في قدرة النظام على الصمود أمام الظروف الصعبة وغير المتوقعة.
فكر فيها زي التطعيم أو اللقاح. إحنا بنحقن النظام “بجرعة صغيرة ومُسيطَر عليها” من الفشل (مثل إيقاف خادم، زيادة استهلاك الذاكرة، أو قطع الاتصال بين خدمتين)، وبنراقب كيف بتصرف النظام. هل ينهار؟ هل يتعافى بنفسه؟ هل يتدهور أداؤه بشكل مقبول؟ الهدف هو اكتشاف نقاط الضعف هذه في بيئة مُتحكّم بها، قبل ما يكتشفها المستخدم في أسوأ وقت ممكن.
ليست مجرد “اختبارات”
هناك فرق جوهري بين الاختبار التقليدي وهندسة الفوضى. في الاختبار، أنت تتحقق من شيء معروف. مثلًا: “هل الدالة X تُرجع القيمة Y؟”. لكن في هندسة الفوضى، أنت تستكشف المجهول. أنت تسأل: “ماذا سيحدث لنظامنا إذا فشلت الخدمة Z بشكل مفاجئ؟”. أنت لا تختبر، بل تُجري تجربة علمية.
مبادئ هندسة الفوضى الخمسة
عشان يكون شغلنا صح ومش مجرد “طق حنك”، هندسة الفوضى بتقوم على مبادئ واضحة:
- تحديد “الحالة المستقرة” (Define Steady State): قبل ما تبدأ تعمل أي فوضى، لازم تعرف كيف يبدو نظامك وهو في أفضل حالاته. ما هي المقاييس الأساسية (Key Metrics) التي تدل على أن النظام “صحي”؟ (مثلًا: عدد الطلبات في الثانية، نسبة الأخطاء أقل من 0.1%، زمن الاستجابة أقل من 200ms).
- وضع فرضية (Hypothesize): ضع فرضية بأن النظام سيحافظ على حالته المستقرة رغم الاضطراب الذي ستحدثه. مثلًا: “نحن نفترض أن الموقع سيبقى متاحًا للمستخدمين حتى لو تعطلت إحدى قواعد البيانات الثانوية للقراءة فقط”.
- إحداث اضطرابات حقيقية (Introduce Real-World Variables): هنا يبدأ الأكشن. قم بمحاكاة أعطال حقيقية قد تحدث: إيقاف خوادم، زيادة استهلاك المعالج (CPU) أو الذاكرة (RAM)، إضافة تأخير في الشبكة (Network Latency)، أو حتى قطع الاتصال بخدمات خارجية.
- محاولة دحض الفرضية (Try to Disprove the Hypothesis): قم بتشغيل التجربة وراقب المقاييس. هل بقيت “الحالة المستقرة” كما هي؟ إذا انهارت فرضيتك والنظام تأثر سلبًا، مبروك! لقد وجدت نقطة ضعف حقيقية يمكنك الآن إصلاحها. إذا صمد النظام، فهذا يعزز ثقتك به.
- تقليل نطاق التأثير (Minimize the Blast Radius): هذا المبدأ هو الأهم. ابدأ دائمًا على نطاق صغير جدًا. جرب على خادم واحد، أو على نسبة قليلة من المستخدمين. لا تقم بتجربة قد تُسقط النظام بأكمله من أول مرة. الهدف هو التعلم، وليس التدمير.
كيف تبدأ رحلتك مع هندسة الفوضى؟ (مثال عملي)
طيب يا أبو عمر، حكيت كتير، خلينا نخش في المفيد. كيف أطبق هالكلام؟
لنأخذ سيناريو بسيط: لديك خدمة مصغرة (Microservice) تعتمد على خدمة أخرى لجلب بيانات المستخدمين. ماذا لو تأخرت خدمة المستخدمين في الرد؟ هل ستنهار خدمتك؟
الخطوات العملية للتجربة
- الحالة المستقرة: خدمتنا تستجيب لـ 99.9% من الطلبات في أقل من 100ms.
- الفرضية: نعتقد أن خدمتنا ستستمر في العمل بشكل مقبول (ربما مع تدهور طفيف في الأداء) حتى لو أصبحت خدمة المستخدمين بطيئة جدًا (تأخير 3 ثوانٍ).
- الأداة: سنستخدم أداة مفتوحة المصدر اسمها Chaos Toolkit. هذه الأداة تسمح لنا بتعريف تجاربنا بشكل وصفي (declarative).
- التجربة (الكود): يمكن تعريف التجربة بملف JSON أو YAML بسيط.
{
"version": "1.0.0",
"title": "هل تصمد خدمتنا أمام بطء خدمة المستخدمين؟",
"description": "نتحقق من أن خدمتنا لا تنهار عند وجود تأخير في الشبكة.",
"steady_state_hypothesis": {
"title": "الخدمة الرئيسية متاحة وتستجيب بسرعة",
"probes": [
{
"type": "probe",
"name": "service-is-healthy",
"tolerance": 200,
"provider": {
"type": "http",
"url": "https://my-awesome-service.com/health"
}
}
]
},
"method": [
{
"type": "action",
"name": "add-3-seconds-latency",
"provider": {
"type": "python",
"module": "chaospumba.actions",
"func": "add_network_latency",
"arguments": {
"service_name": "user-service",
"duration": "3s",
"interface": "eth0"
}
},
"pauses": {
"after": 60
}
}
],
"rollbacks": []
}
شرح الكود المبسط:
steady_state_hypothesis: هنا نعرّف الحالة المستقرة. نقول للأداة أن تتحقق من صحة خدمتنا (عبر مسار/health) قبل وبعد التجربة.method: هنا نعرّف “الفوضى” التي سنحدثها. في هذا المثال، نستخدم أداة مساعدة (مثل Pumba) لإضافة تأخير (latency) مقداره 3 ثوانٍ على الاتصالات الموجهة إلىuser-service.pauses: ننتظر 60 ثانية بعد إحداث الفوضى لنرى التأثير.
عند تشغيل هذه التجربة، سيقوم Chaos Toolkit بالتحقق من صحة النظام، ثم إضافة التأخير، ثم التحقق من صحة النظام مرة أخرى. إذا فشل التحقق الثاني، فهذا يعني أن فرضيتك خاطئة، ونظامك هش أمام هذا النوع من الفشل. الآن لديك مشكلة واضحة ومحددة للعمل عليها (مثل إضافة Timeouts، أو آلية Circuit Breaker).
نصائح من خبرة أبو عمر
- ابدأ صغيرًا وفي بيئة آمنة: لا تقفز مباشرة إلى بيئة الإنتاج. ابدأ ببيئة التطوير (Staging)، ثم على جزء صغير جدًا من بيئة الإنتاج.
- الأتمتة هي مفتاح النجاح: اجعل تجارب الفوضى جزءًا من خط أنابيب النشر والتكامل المستمر (CI/CD). شغلها تلقائيًا مع كل تغيير جديد.
- اجعلها ثقافة فريق: هندسة الفوضى ليست وظيفة شخص واحد. يجب أن يشارك فيها الجميع (المطورون، مهندسو الجودة، مهندسو DevOps/SRE). اعقدوا جلسات “Game Day” حيث يقوم الفريق بمحاكاة الأعطال معًا والتعلم منها.
- ركّز على التعلم، وليس على اللوم: عندما تكشف تجربة ما عن ضعف، فهذا نجاح! نجاح في اكتشاف مشكلة قبل أن تؤثر على المستخدمين. لا تبحث عن المخطئ، بل ابحث عن حل للمشكلة.
– التواصل ثم التواصل: قبل تشغيل أي تجربة فوضى، تأكد من أن الفريق بأكمله على علم. لا شيء أسوأ من أن يقضي مهندس ساعات في البحث عن سبب مشكلة ليكتشف في النهاية أنها كانت “تجربة فوضى” لم يخبره بها أحد!
الخلاصة: ابنِ قلعتك قبل العاصفة 🏰
بعد “ليلة الخميس الحزينة” تلك، تبنينا هندسة الفوضى كجزء أساسي من ثقافتنا. لم نعد ننتظر الكارثة لنتحرك، بل أصبحنا نبحث عن نقاط الضعف بأنفسنا وبشكل استباقي. نعم، في البداية كان الأمر مخيفًا، لكن الثقة التي بنيناها في أنظمتنا لا تقدر بثمن.
هندسة الفوضى هي تحول في العقلية من “نأمل ألا يتعطل نظامنا” إلى “نحن نعرف كيف سيتعطل نظامنا، ونحن مستعدون له”. هي ليست رفاهية للشركات الكبرى فقط، بل هي ضرورة لكل من يريد بناء أنظمة برمجية قوية وقادرة على الصمود في وجه فوضى العالم الحقيقي.
لا تنتظر “ليلة الخميس الحزينة” الخاصة بك. ابدأ اليوم، ابدأ صغيرًا، واجعل أنظمتك أقوى من أي وقت مضى. وزي ما بحكوها عنا، “ما تستنى المصيبة تيجي لعندك، روح دور عليها في عقر دارها وتحكم فيها!”.
وفقكم الله، والسلام عليكم. 👋
