ما المقصود بهندسة الفوضى؟

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

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

تعد هندسة الفوضى مهمة لأن الخطأ أو الاضطراب يمكن أن يبطئ زخم المؤسسة، مما يؤدي إلى إضاعة وقت ثمين في اكتشاف حل سريعًا مع زيادة فترة التعطل. وقد تعلمت Netflix هذا المفهوم عن كثب عندما تحولت من البيئة المحلية إلى السحابية¹- فقد واجهت انقطاعًا أدى إلى انقطاع الخدمة لمدة ثلاثة أيام في عام 2008.

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

أنشأت Netflix برنامج Chaos Monkey²، وهو أداة مفتوحة المصدر تعمل على إنشاء حوادث عشوائية في خدمات تكنولوجيا المعلومات والبنية التحتية بهدف تحديد نقاط الضعف التي يمكن إصلاحها أو معالجتها من خلال إجراءات الاسترداد التلقائية. لقد طبقوا "chaos monkey" عند الانتقال من مركز البيانات الخاص إلى خدمات أمازون السحابية (AWS) استجابةً لعدم الموثوقية من السحابة. تستخدم العديد من المؤسسات الآن Chaos Monkey لإجراء تجارب هندسة الفوضى الخاصة بها.

تُعد هندسة الفوضى وسيلة دفاع مهمة ضد أعطال البنية التحتية أو انقطاع التيار الكهربائي أو فقدان المكونات في بيئة إنتاج المؤسسة. فهي تساعد مهندسي موثوقية الموقع (SREs) وأعضاء آخرين في فريق عمليات التطوير على توفير تسليم مستمر للخدمات من خلال تجنب الانقطاعات الكبيرة في الخدمة. وتساعدهم هندسة الفوضى على فهم نقاط ضعفهم بشكل أفضل وتوضح لهم كيفية تقليل التأثير في حالة حدوث عطل.

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

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

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

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

لا تزال الشركات التي تستخدم السحابة تتعامل في كثير من الأحيان مع حوادث تكنولوجيا المعلومات دون مراعاة كيفية تأثير السحابة والبرمجيات كخدمة (SaaS) على تلك الحوادث بشكل مختلف وفقًا لـ Constellation Research5⁵.

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

يمكن أن تساعد هندسة الفوضى أيضًا المؤسسات على تحسين سرعة مسارات التكامل المستمر والتسليم المستمر (CI/CD). دمج هندسة الفوضى في CI/CD كما فعلت Netflix⁶ يتيح لمؤسسات أتمتة التجارب المستمرة مع التحكم في تأثيرها المحتمل.

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

تساعد هندسة الفوضى الناجحة المؤسسة على تقليل الأعطال الفنية التي لها تأثير كبير على العملاء، كما أنها تدعم بناء بُنى أنظمة معقدة وأكثر مرونة. بمجرد أن تقرر المؤسسة متابعة هندسة الفوضى، فإن الخطوة التالية هي تحديد ما إذا كان سيتم تنفيذها في بيئة ما قبل الإنتاج أو بيئة الإنتاج.

لدى فرق عمليات التطوير العديد من الخيارات لإجراء تجارب هندسة الفوضى لاختبار عمليات النظام المختلفة.

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

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

• فهم النظام: هذا يتضمن معرفة شاملة بالنظام الكلي، وخصائصه ووظائفه الناشئة، وطوبولوجيته، وبنيته، وتبعياته، وسلوكه في حالة الاستقرار، واستجابة المخرجات وخصائصه مثل التوافر، وزمن الانتقال، والإنتاجية.
  
• تقبّل الفشل: يبدو متناقضاً في البداية أن يسمح مهندسو البرمجيات بوقوع حادث في حين أنهم مهيأون لمنع وقوع مثل هذه الحوادث. ومع ذلك، فإن الأعطال ستحدث دائمًا في خدمات تكنولوجيا المعلومات ومن الأفضل تجربتها في بيئة خاضعة للرقابة لتحديد الحل بشكل استباقي بدلاً من أن يحدث ذلك بعد ساعات العمل عندما يكون فريق المؤسسة خارج أوقات العمل أو لم يواجه تلك المشكلة المحددة من قبل.
• تحديد سلوك الحالة المستقرة: أولاً، يجب على الفريق الهندسي أن يحدد كيف يجب أن يتصرف النظام عند تشغيله بشكل صحيح، حتى يتمكن من مقارنة كيفية تأثير التجارب على تلك الحالة المستقرة.
• تحديد الحوادث الواقعية: يجب أن تتعامل تجارب هندسة الفوضى قدر الإمكان مع ما قد يحدث في يوم عادي بدلاً من خلق مواقف غير محتملة. من المحتمل حدوث أعطال في الشبكة والبنية التحتية والتعليمات البرمجية السيئة ومشكلات الطاقة والحمل الزائد لحركة البيانات.
• إنشاء يوم اللعبة: يمكن لهندسة الفوضى دراسة البيئة في يوم اللعبة، حيث تحدث اختبارات متعددة خلال يوم محدد لزيادة مواردها إلى أقصى حد لتحديد وحل أكبر عدد ممكن من المشكلات.
• استخدام الأتمتة: يمكن للمؤسسات من جميع الأحجام استخدام هندسة الفوضى من خلال أتمتة التجارب، والتي قد تتطلب عمالة كثيفة للغاية إذا أجرتها المؤسسة يدوياً. وهذا يقلل من بعض العبء على فرق تكنولوجيا المعلومات في أثناء عملية هندسة الفوضى. ويُعد تصميم التجارب وحقن الأعطال وتوفير البنية التحتية كلها جوانب من التجارب التي يمكن للمؤسسة أتمتتها.
• انتبه إلى نصف قطر الانفجار: يجب أن يبذل مهندس الفوضى جهدًا كبيرًا لتقليل نصف قطر الانفجار بحيث يكون الضرر الفعلي الذي يلحق بالعملاء طفيفًا قدر الإمكان. فيما يلي بعض الطرق لتقليل نصف قطر الانفجار:
  • استهداف مجموعة فرعية من الخدمات: يجب ألا تؤدي هندسة الفوضى، خاصة في بيئة الإنتاج، إلى تعطيل خدمة المؤسسة بشكل أساسي. استهداف مجموعة فرعية محددة من الخدمات يمكن أن يقلل من تأثير الحادث في حال وقوعه، مما يضمن عدم تعطيل النظام بأكمله.
  • إجراء التجربة لفترة زمنية محددة: يجب أن يكون للتجربة بداية ونهاية. إن الهدف من التجربة هو خلق حادثة وحلها مقابل تركها دون حل لفترة طويلة.
  • إجراء التجربة بعيداً عن أوقات ذروة حركة البيانات: يجب على المؤسسة أن تحاول تجنب إجراء التجارب خلال أوقات الذروة إلا إذا كانت تحاول تحديداً قياس مدى تأثير السعة العالية على النظام أثناء وقوع حادث ما.
  • تشغيل التجربة في بيئة التطوير: أسهل طريقة لضمان عدم تعرض العملاء لانقطاع الخدمة هي التشغيل في بيئة ما قبل الإنتاج. ومع ذلك، هذا يعني أن الظروف ستختلف عن بيئة الإنتاج، مما قد يعطي صورة خاطئة لما يحدث. لتقليل ذلك، تأكد من أن بيئات ما قبل الإنتاج وبيئات الإنتاج تعكس بعضها البعض قدر الإمكان.
  • التجربة على كل مكون:تجربة الفوضى لا تنتهي أبدًا لأن نظام المؤسسة يتغير باستمرار. يجب أن يكون الهدف الآخر هو اختبار "كل شيء"- فحص جميع المكونات والطبقات والخدمات وتوابعها خلال العملية.

يجب على المؤسسة التي تستخدم هندسة الفوضى أن تقرر ما إذا كانت ستستخدم اختبار الفوضى في بيئات الإنتاج أو ما قبل الإنتاج. هناك عدة أسباب تجعل هندسة الفوضى أكثر فائدة في بيئات الإنتاج.

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

على سبيل المثال، قد لا يؤدي وقوع حادث في بيئة ما قبل الإنتاج إلى استجابة واقعية لأنها تفتقر إلى نفس مستويات حركة البيانات مثل البيئة الحية. فهي قد لا تحتوي على تكوينات الأمان نفسها في تلك البيئة.

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

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

توفر هندسة الفوضى للمؤسسات العديد من الميزات الرئيسية.

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

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

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

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

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