ما هي هندسة الفوضى؟

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

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

هندسة الفوضى مقابل اختبار الأداء

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

ولدت الفوضى (الهندسة)

نشأت ممارسة هندسة الفوضى مع Netflix حوالي عام 2008 بعد أن أطلقت خدمة البث الخاصة بها رسميا. بعد مشكلة تلف قاعدة البيانات حوالي عام 2011 ، خططت Netflix لنقل مركز البيانات الخاص بها إلى السحابة عبر AWS (Amazon Web Services). في الواقع ، استغرق الأمر ثماني سنوات لإكمال الهجرة أخيرا. في عام 2015 ، واجهت AWS انقطاعا ، مما تسبب في تعطل Netflix لعدة ساعات. كانت هذه هي الأيام الأولى للحوسبة السحابية ، لذلك لم تكن قوية ومستقرة وآمنة من الفشل كما هي الآن. عندما اكتشفوا أن الانتقال إلى السحابة لم يخلق بعض الفوائد التي توقعوها ، مثل قابلية التوسع ، ووقت التشغيل ، وتجنب نقاط الفشل الفردية ، التحجيم التلقائي، وما إلى ذلك ، قرروا أنهم بحاجة إلى طريقة لاختبار هذه الأشياء غير المتوقعة قضايا لضمان تشغيل خدماتهم، وفي النهاية ، تجنب التأثير على المستخدمين والتسبب في الإحباط. من هذه التجربة ، ولدت هندسة الفوضى.

مبادئ وخطوات هندسة الفوضى

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

الخطوة 1: إنشاء فرضية

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

الخطوة 2: تحديد المتغيرات وتوقع التأثيرات

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

الخطوة 3: بدء التجربة

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

الخطوة 4: قياس التأثير

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

أدوات هندسة الفوضى

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

في حين أنه قد يبدو من غير المنطقي تخصيص الموارد والأفراد للالتفاف حول “كسر” الأشياء ، فإن إجراء اختبارات الفوضى هذه بشكل استباقي يساعد على بناء شبكة أكثر مرونة وخلق تجربة مستخدم أفضل وأكثر موثوقية. العالم الحقيقي لا يعمل في بيئة اختبار خاضعة للرقابة. منذ بداية Chaos Monkey ، مر بالعديد من التحديثات وأصبح تطبيقا شائعا مفتوح المصدر. وفي وقت من الأوقات ، كان مجرد جزء واحد من مجموعة أدوات هندسة الفوضى تسمى جيش سيميان. تم حل جناح Simian Army في عام 2018 ، ولكنه تضمن المرافق الهندسية التالية الخاصة بالفوضى:

فوضى كونغ

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

المطابقة

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

فوضى الغوريلا

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

الكمون

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

دكتور مونكي

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

10-18

يأتي اسم 10-18 Monkey من اختصارات التعريب والتدويل والتعريب ، L10n و i18n. تمثل الأرقام عدد الأحرف بين الحرفين الأول والأخير. نظرا لأن عملاء Netflix يقيمون في جميع أنحاء العالم ، فإن وجود طريقة لمراقبة موثوقية خدمات البث الخاصة بهم ، عبر مناطق مختلفة ، كان ذا أهمية قصوى. تتمثل ميزة الأداة المساعدة 10-18 Monkey في أنه يمكنها التحقق من مشكلات التكوين والأداء عبر مناطق جغرافية متعددة تخدم وتستخدم لغات ومجموعات أحرف مختلفة.

بواب القرد

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

الخلاصة: هندسة الفوضى – المبادئ والأمثلة والأدوات

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