لماذا نكسر الأشياء عن قصد؟
لماذا نكسر الأشياء عن قصد؟
كل نظام موزع يتعرض للفشل في النهاية. تتقطع الشبكات، وتمتلئ الأقراص، وتنتهي مهل الاستجابة، وتتراكم تسريبات الذاكرة، وتتعطل العمليات تحت أحمال لم تُختبر قط. السؤال ليس هل سيتعرض نظامك لهذه الظروف — بل هل ستكتشف نمط الفشل في تجربة محكومة الساعة الثانية ظهرًا يوم الثلاثاء، أم في ذعر كامل الساعة الثالثة صباحًا حين يُنبَّه مهندس مناوب وتتأثر مستخدمون حقيقيون؟
هندسة الفوضى (Chaos Engineering) هي ممارسة إحداث العطل المتعمد في النظام بطريقة علمية محكومة، بهدف كشف نقاط الضعف قبل أن تظهر من تلقاء نفسها في بيئة الإنتاج. تُجيب هذه الممارسة على سؤال واحد: هل يتصرف هذا النظام فعلًا بالطريقة التي نعتقد أنه يتصرف بها في ظروف الأعطال؟
قصة نشأة هندسة الفوضى في Netflix
في عام 2008، تعرضت Netflix لحادثة تلف كبيرة في قاعدة البيانات أوقفت الخدمة ثلاثة أيام كاملة. كانت هذه الحادثة نقطة تحول جذرية. أدرك الفريق الهندسي أن انتقالهم من مركز بيانات تقليدي إلى Amazon Web Services قد غيّر طبيعة الأعطال تغييرًا جوهريًا. في مركز البيانات كانت لديك حفنة من الخوادم الكبيرة والمكلفة ذات خصائص فشل معروفة. أما على AWS فلديك آلاف الحالات الصغيرة القابلة للاستبدال — والمبدأ الأساسي للبنية التحتية السحابية هو أن المكونات الفردية ستفشل، وعلى نظامك أن يتحمل ذلك.
في عام 2010، بنى مهندس Netflix غريغ أورزيل وفريقه أداة داخلية صغيرة أسموها Chaos Monkey. وظيفتها الوحيدة كانت إنهاء حالات EC2 عشوائيًا خلال ساعات العمل. المنطق كان مباشرًا: إذا كانت الحالات يمكن أن تتوقف في أي وقت في بيئة الإنتاج، فيجب على المهندسين بناء خدمات تنجو من توقف هذه الحالات — والطريقة الوحيدة للتحقق من هذه النجاة هي ممارستها باستمرار، لا تصميمها نظريًا والأمل في أنها ستعمل.
كانت Chaos Monkey بذرة ما نشرته Netflix عام 2012 باسم Simian Army — مجموعة أدوات فوضى تستهدف كل منها نوعًا مختلفًا من الأعطال: Chaos Gorilla لعطل منطقة التوافر الكاملة، وChaos Kong لعطل المنطقة الجغرافية، وLatency Monkey لحقن تأخير الشبكة، وConformity Monkey لاكتشاف الانحراف في التهيئة. وفي عام 2014، رسّخت Netflix المبادئ الكامنة وراء كل هذه الأدوات في منهج أطلقت عليه هندسة الفوضى.
فجوة الثقة
تعمل معظم الفرق الهندسية انطلاقًا من مجموعة من الافتراضات غير المُختبرة حول مرونة نظامها. لديها دلائل تشغيلية تقول "إذا توقفت قاعدة البيانات الأساسية، يُرقَّى النسخ الاحتياطي تلقائيًا". لديها مخططات معمارية تُظهر منطق إعادة المحاولة وقواطع الدائرة. لديها التزامات SLO لمستخدميها. لكن لم يُتحقق من أي من هذه الافتراضات في ظروف حقيقية على نطاق الإنتاج.
هذه الفجوة بين المرونة المفترضة والمرونة الفعلية هي ما تُغلقه هندسة الفوضى. تأمل خدمة ويب نموذجية تعتمد على ثلاث APIs خارجية. لديك مهلة 3 ثوانٍ ومنطق إعادة محاولة بتراجع أسي. تعتقد أنه إذا تدهورت أي من هذه الـ APIs ستتراجع خدمتك بسلاسة. لكن هل تحققت من:
- هل يفتح قاطع الدائرة فعلًا بعد عتبة الفشل المُهيَّأة، أم أن التهيئة تحتوي على خطأ مر دون أن يُلاحَظ؟
- عندما يفتح قاطع الدائرة، هل تُعيد الخدمة استجابة مخزنة مؤقتًا، أم خطأ 503، أم تنتظر في حالة توقف تام حتى ينضب تجمع الاتصالات؟
- هل تأخذ مهلتك البالغة 3 ثوانٍ في الحسبان أن مكتبة HTTP لديها مهلة اتصال منفصلة عن مهلة القراءة، وأن خطأ في تهيئة أي منهما يعني تعليق الطلبات لـ 30 ثانية؟
- عندما تتدهور جميع الـ APIs الثلاث في آنٍ واحد — سيناريو لم يحدث قط في بيئة التجهيز — هل يتسلسل استنزاف تجمع الخيوط ليُحوّل خدمتك ذاتها إلى خدمة متعطلة؟
كل من هذه الأسئلة هو فرضية. وهندسة الفوضى هي ممارسة إجراء تجارب محكومة لتأكيد هذه الفرضيات أو دحضها، تمامًا كما يُجري العلماء تجاربهم لتأكيد أو دحض الفرضيات حول العالم المادي.
الإطار العلمي
نشرت Netflix تعريفًا دقيقًا لهندسة الفوضى يتضمن خمسة مبادئ. هذه ليست اقتراحات — بل تُحدد الفرق بين تجربة الفوضى والاختبار التدميري العشوائي:
- تحديد الحالة المستقرة — حدد مخرجًا قابلًا للقياس يمثل السلوك الطبيعي (طلبات في الثانية، معدل الخطأ، تأخير p99، امتثال SLO). هذا هو خط الأساس الضابط لك.
- افترض استمرار الحالة المستقرة — فرضيتك هي أن النظام سيحافظ على الحالة المستقرة رغم العطل الذي ستُحدثه. اكتبها صراحةً.
- أدخل أحداثًا من العالم الحقيقي — احقن أعطالًا تعكس واقع الإنتاج: تعطل الخوادم، تأخير الشبكة، امتلاء القرص، فشل الاعتماديات، تشبع المعالج. لا حالات حافة اصطناعية يستحيل حدوثها.
- التشغيل في بيئة الإنتاج — بيئة التجهيز لا تملك أنماط حركة مرور الإنتاج، ولا توزيعات بيانات الإنتاج، ولا حِمل الإنتاج. آليات المرونة التي تعمل في بيئة التجهيز تحت 10 طلبات في الثانية كثيرًا ما تفشل في الإنتاج تحت 50,000 طلب في الثانية. يجب أن تُجرى التجربة حيث يعيش السلوك الحقيقي.
- أتمتة التجارب لتعمل باستمرار — تجربة الفوضى الواحدة مجرد لقطة لحظية. تتغير الأنظمة مع كل نشر. الفوضى المستمرة تمنح ثقة مستمرة.
لماذا ساعات العمل؟
صُمِّمت Chaos Monkey لتعمل خلال ساعات العمل عن قصد. يبدو هذا غير بديهي — لماذا نُحدث أعطالًا والمستخدمون نشطون؟ الإجابة هي أن هدف هندسة الفوضى هو اكتشاف نقاط الضعف، وتريد أن يكون المهندسون الكبار متاحين للاستجابة حين تُكشف نقطة ضعف. إذا كشفت تجربة الفوضى أن خدمتك لا تتعافى من إنهاء حالة ما، فأنت تريد فريقًا هندسيًا كاملًا في مكاتبهم للتحقيق في السبب الجذري وإصلاحه — لا مهندسًا مناوبًا وحيدًا في منتصف الليل بسياق محدود. كما تُجبر التجارب في ساعات العمل الفرق على التعامل مع المرونة كاهتمام هندسي من الدرجة الأولى، لا كحالة طوارئ في الثالثة صباحًا.
حلقة تجربة هندسة الفوضى
هندسة الفوضى مقابل اختبار الحِمل ومقابل حقن الأعطال
كثيرًا ما تختلط هذه المصطلحات. اختبار الحِمل يسأل: كم من حركة المرور يستطيع هذا النظام استيعابها؟ وهو يستكشف الطاقة الاستيعابية. حقن الأعطال (كما يُستخدم في اختبارات الوحدة) يسأل: هل تتعامل هذه الدالة بشكل صحيح مع مدخل خاطئ؟ وهو يستكشف الصحة على مستوى المكون. أما هندسة الفوضى فتسأل: هل يحافظ هذا النظام الموزع على سلوك مقبول في ظروف الأعطال الواقعية؟ وهو يستكشف السلوك الناشئ — كيف تتفاعل المكونات المستقلة والصحيحة منفردةً حين تتدهور البيئة. النطاق هو النظام الاجتماعي-التقني بأكمله: البرمجيات والبنية التحتية والعمليات البشرية المحيطة بها.
مؤشر النضج الهندسي
ممارسة هندسة الفوضى من عدمها مؤشر موثوق على النضج الهندسي. تتعامل المنظمات غير الناضجة مع بيئة الإنتاج باعتبارها مقدسة لا تُمَس — إنها تخشى الفشل لأنها لم تبنِ الأدوات والرؤية والثقافة الكافية لاحتوائه. أما المنظمات الناضجة فتتعامل مع بيئة الإنتاج باعتبارها بيئة الاختبار الأهم، وتُجري فيها تجارب محكومة لأن لديها الثقة المستمدة من رؤية عميقة، وتراجع سريع، وعمليات مناوبة قادرة على التعامل مع نطاق تأثير معروف ومحدد زمنيًا.
هدف هذا البرنامج التعليمي هو أن ينتقل بك من الصفر إلى ممارسة هندسة فوضى فاعلة: الأدوات، والتجارب، وعملية يوم اللعبة، وأنماط المرونة التي تُثبتها الفوضى. الدرس الأول ينتهي هنا — بالـلماذا. وبقية البرنامج هو الـكيف.