اختر صفحة

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

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

مع ظهور ممارسات 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 كاملة يتم إسقاطها أو حذفها لمعرفة كيفية تعافي النظام واستجابته عن طريق نقل حركة المرور إلى منطقة مختلفة دون تدهور الأداء. مرة أخرى ، نادرا ما يحدث هذا ، ولكن في نطاق هندسة الفوضى ، لا شيء خارج الحدود.

المطابقة

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

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

Chaos Gorilla يشبه Chaos Monkey ، ولكن على نطاق أوسع. بدلا من محاكاة حالات الفشل على مثيلات 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 وغيرها الكثير ، والتي يمكن للمؤسسات استخدامها. بناء أنظمة مرنة ليس فقط لشركات التكنولوجيا. أصبحت الأنظمة الموزعة أكثر تعقيدا ، مما يعني أنه من الصعب التنبؤ بالفشل. أيضا ، نظرا لمختلف القضايا التنظيمية والامتثال ، تحتاج البنوك والكيانات الحكومية وشركات الأدوية والمؤسسات التعليمية ، وما إلى ذلك ، إلى اختبار أنظمتها وخدماتها بانتظام للتأكد من أنها تلبي متطلبات الأعمال والمهام الحرجة. اختبار الأداء واختبار الفوضى هي أساليب استباقية لتعلم كيفية بناء أنظمة مرنة من خلال مراقبة الفشل.