هندسة الفوضى أو الإصلاح في بيئة الإنتاج
تُستثمر كميات كبيرة من الموارد في اختبار منتجات البرمجيات عندما تسعى الشركات لبناء منتج مستقر ومرن للغاية. ومع ذلك، قد لا يحقق ذلك النتائج المرجوة دائمًا.
هل يبدو إصلاح منتج برمجي في بيئة الإنتاج أفضل من إتلاف البرنامج؟ حسنًا، قد يعتمد ذلك على من نسأل.
لذلك ربما ينبغي أن نختار الكلمات التي نستخدمها عند تقديم هذا لأصحاب المصلحة أو المديرين. قد لا يحب البعض المصطلحات "التدميرية"، وأحياناً قد نحتاج إلى استخدام مصطلحات "إبداعية". لكن كسر البرمجيات لرؤية نقاط ضعفها وجعلها أكثر متانة وموثوقية واستقراراً يقودنا إلى التفكير بأننا بحاجة إلى كسرها أولاً ثم إصلاحها.
ماذا يُسمى عندما تجري تجارب على البرمجيات لمعرفة مدة صمودها تحت الضغط المعطى ومدى قدرتها على الحفاظ على سلامتها قبل أن تتعطل؟ هل لهذا اسم؟
اسمحوا لي أن أعرّفكم على هندسة الفوضى (المشار إليها لاحقاً في النص بـ CE).
ما هي هندسة الفوضى؟
تقول بعض تعريفات CE إنها discipline إجراء التجارب على نظام من أجل بناء الثقة في قدرة النظام على تحمل الظروف المضطربة في بيئة الإنتاج.
لنفترض أنك تبني برمجيات تؤدي بعض الوظائف. تعمل هذه البرمجيات بشكل جيد وتؤدي أداءً جيداً في جميع الاختبارات التي خضعت لها. ولكن ماذا لو تعرضت هذه البرمجيات في بيئة الإنتاج إلى أقصى حدودها وأدى ذلك في النهاية إلى خلل في عملها. قد تكون الخسارة في الإيرادات ضخمة. وكلما كان النظام أكبر، كان حجم الخسارة المحتملة أكثر أهمية. ولتجنب ذلك، ينبغي لنا تقليل المخاطر المذكورة سابقاً.
ينبغي تطبيق هندسة السحابة (CE) في الأنظمة الضخمة المتاحة للمستخدمين طوال الوقت تقريبًا. فكلما زاد عدد المستخدمين، زاد التأثير.
لنتعمق في الموضوع المطروح بشكل أعمق.
هندسة الفوضى في الممارسة العملية
عندما نتحدث عن تطوير البرمجيات، علينا أن نفكر في مرونة نظام البرمجيات التي تُحدد عادةً كمتطلب برمجي. وهي قدرة نظام برمجي معين على تحمل الأعطال مع ضمان جودة خدمة (QoS) كافية. وغالباً ما يكون تحقيق هذا المتطلب صعباً على فرق التطوير بسبب قلة الخبرة أو ضيق الجدول الزمني للمشروع. وهنا يأتي دور هندسة الفوضى.
CE هي تقنية تساعد في تلبية متطلبات المرونة ويمكن استخدامها ضد أعطال التطبيقات وأعطال البنية التحتية وأعطال الشبكة.
يتم ذلك عبر إدخال أعطال في نظام محدّد بطريقة خاضعة للتحكم والمراقبة، بهدف الحصول على رؤية واضحة لمدى مرونة النظام المعني. وإذا ظهرت عيوب جسيمة، ينبغي لنا معالجة الوضع لإيجاد حل يخفّف من آثارها. ومن خلال هندسة الفوضى (CE)، يمكننا كشف نقاط الضعف في نظام محدّد، وإيجاد حل للتعامل معها، وبناء نظام أكثر مرونة بأدنى مخاطر ممكنة لخسارة الإيرادات أو "الفضيحة السوقية" التي قد يتسبب بها مستخدمونا من خلال تقييم برنامج معيّن.
تتبع تجارب هندسة العملاء بعض الإرشادات أو الخطوات.
الخطوة #1
يجب أن نحدد حالة طبيعية للنظام المرصود ينبغي أن تمثل السلوك الطبيعي وأن يكون لها مخرجات قابلة للقياس. لهذا الغرض، يجب أن نقيس مخرجات النظام على مدى فترة زمنية قصيرة ونضع تلك البيانات كحالة طبيعية أو مستقرة.
الخطوة #2
ينبغي لنا أن نضع فرضية مفادها أن هذه الحالة الطبيعية ستكون موجودة في كل من المجموعة الضابطة والمجموعة التجريبية. وينبغي أن تستند إلى بيانات قابلة للقياس جمعناها بالفعل.
الخطوة #3
ينبغي لنا أن نقدّم الحالات التي تمثل أحداثًا واقعية تحاكي مشكلات الخادم (إيقاف تشغيل الخادم، الاستجابات المشوّهة، الارتفاعات المفاجئة في حركة المرور، استنفاد الموارد)، ومشكلات الشبكة (عرض نطاق منخفض، زمن استجابة مرتفع، فقدان الحزم أو انقطاع الرابط بالكامل)، ومشكلات القرص الصلب (استنفاد الموارد، تلف البيانات)، وما إلى ذلك.
من الأفضل إجراء هذه التجارب مباشرة في بيئة الإنتاج لضمان أصالة وملاءمة النظام المنشور حالياً. ولكن احرص على عدم التأثير على المستخدمين أثناء العملية. وإذا تأثرت تجربة المستخدم، فأوقف الاختبار فوراً. تعلّم من هذه التجربة وعدّل استراتيجية الاختبار لديك. ثم حاول مرة أخرى.
الخطوة #4
ينبغي لنا دحض الفرضية بالحالات المختلفة في كل من المجموعة الضابطة والمجموعة التجريبية.
الخطوة #5
أتمتة العملية لتشغيل تلك التجارب بشكل مستمر. قد يكون القيام بذلك يدويًا غير مستدام.
يجب أن يعمل النظام على الرغم من أعطاله، وهنا يصبح Chaos Engineering ذا صلة.
فوائد هندسة الفوضى
قد يكون إعداد CE صعباً بعض الشيء في البداية، لكنه سيثمر على المدى الطويل. يمكننا رؤية فوائده من منظور الأعمال والعملاء والتقنية.
من منظور الأعمال، يمكن أن تؤدي أعطال النظام إلى دفع الشركة إلى حالة غير مرغوب فيها في السوق، مما قد يؤدي إلى خسارة الإيرادات، وسمعة سيئة، وارتفاع تكاليف الصيانة، وصعوبات في جذب موظفين جدد وإبرام عقود تجارية جديدة، وغير ذلك.
من منظور العميل، يمكن لـ CE الحفاظ على مراجعات منتج جيدة، وتوافر عالٍ للمنتج، وسمعة جيدة بين المستخدمين الحاليين، وتدفق مستقر للمستخدمين الجدد.
من المنظور التقني، يمكن أن تساعد هذه التقنية في تقليل مشكلات النظام أو الحوادث، والمساعدة على فهم نقاط ضعف النظام بشكل أفضل، وتحسين النظام وتحسين السرعة اللازمة لإصلاح الحوادث.
الأمثلة الواقعية على ما قد يحدث كثيرة.
نستخدم جميعًا وسائل التواصل الاجتماعي للتواصل. معظمنا أعضاء في مجموعات ما. لنفترض أنك فوّت إشعارًا واحدًا كان ينبغي أن يصل في الوقت المناسب تمامًا لاتخاذ إجراء معين. يصل متأخرًا جدًا. سيناريو آخر: تخيل أن لديك حلًا على هاتفك الذكي يمكنه تتبع موقعك الجغرافي ويعطيك معلومات غير صحيحة.
إليك بعض الأمثلة الإضافية. تخيل كم من الأمور قد تسوء في حالة التقنية المستخدمة في القيادة الذاتية. ومن الأمثلة الأخرى حل برمجي داخلي ينشئ ملفات PDF التي يحتاج الموظفون غالباً إليها لإبرام أعمال جديدة. وإذا توقف ذلك الحل البرمجي عن العمل بينما توجد أمور يجب تسليمها في الوقت المحدد، فقد يكون التأثير على أرباح الشركة ملحوظاً.
أخيرًا، تخيل أن شركتك عبارة عن بنك كبير له العديد من الفروع ويحتل حصة جيدة من حصة سوق بلد معين. تم إصدار نسخة جديدة من تطبيق البنك. تم اختبار التطبيق اختبارًا سطحيًا بسبب نقص الموارد، لكن تقرر إطلاقه في بيئة الإنتاج. عند الانتقال إلى الإنتاج، تظهر بعض المشكلات البيئية، ويصبح التطبيق غير متاح لجميع مستخدميه. ينخفض تقييم التطبيق في المتجر. كما تتراجع سمعة الشركة. يجب تجنب أمور كهذه من خلال المرونة وتثقيف المهندسين.
ربما مع وجود CE، لما حدثت تلك الأمور.
لنوضح بعض الأمور
إذا لم تكن قد صادفت مصطلح هندسة الفوضى بعد، فقد تتساءل عن بعض الأمور، لذا دعني أوضحها.
- علامة CE ليست meant لإحداث الفوضى بل لتكون حلاً في حال ظهور المشكلات المذكورة.
- كل شيء يتم في بيئة محكومة (على الأقل يجب أن يكون كذلك إذا كنت لا تريد إفساد الأمور).
- يتم أيضاً مراقبة كل شيء لأننا نحتاج تلك البيانات لاحقاً
- بالإضافة إلى إضافة ميزات جديدة، يهتم المطورون بالموثوقية، ويكتبون اختبارات الوحدة وينفذونها.
- يجب اختبار حلول البرمجيات جيدًا قبل الإنتاج، ويذهب اختبار CE إلى أبعد من ذلك. يوفر الاختبار بيانات نتوقعها. بينما يوفر اختبار CE بيانات غير متوقعة يمكن استخدامها لإنشاء حلول مرنة.
- CE مخصصة بشكل أساسي للأنظمة الكبيرة، كما ذُكر سابقًا، لكنها مفيدة أيضًا للأنظمة الأصغر.
- لا حاجة إلى أدوات خاصة.
- من الأفضل أن تكون هندسة الفوضى مؤتمتة.
- من خلال التجارب في هندسة الفوضى، نتعلم خصائص جديدة للنظام ونكتسب معرفة جديدة أو نبني ثقتنا في الحل البرمجي.
استخدام هندسة الفوضى
في عام 2011، نشرت Netflix مقالاً بعنوان "جيش القرود في Netflix" (The Netflix Simian Army)، وكانت تلك أول مرة يتم فيها تقديم هندسة الفوضى (Chaos Engineering). ومن تلك القصة ظهر أيضاً "قرد الفوضى" (Chaos Monkey) (الذي طوره فريق هندسة Netflix في عام 2010) كأداة برمجية تحاكي بشكل عشوائي أعطال نسخ الإنتاج. ربما شاهد بعضنا جنوداً من غرب أفريقيا وهم يسلمون بندقية AK-47 لقرد (على يوتيوب: "Ape With AK-47")، وهو أمر مشابه للنتائج - غير متوقع. كذلك، لا يعمل Chaos Monkey كخدمة، بل هو أشبه بمهمة مجدولة (cron job) تستدعي Chaos Monkey مرة واحدة أسبوعياً لإنشاء جدول زمني لعمليات الإنهاء.
ذكرنا "جيش السعالي" قبل لحظة – فما هو؟ إنه مجموعة كاملة من الأدوات المسبّبة للأعطال التي تتجاوز Chaos Monkey نفسه. وتضم Latency Monkey وConformity Monkey وDoctor Monkey وJanitor Monkey وSecurity Monkey و10-18 Monkey وChaos Gorilla وChaos Kong. وسنترك الأمر عند هذا الحد الآن لأنه قد يكون من المفرط تحديد ما تفعله كل أداة بالضبط. وقد أُنشئت هذه المجموعة في عام 2011. وفي عام 2012، أصبح Chaos Monkey متاحًا للعموم.
في عام 2016، قدّم Kolton Andrus وMatthew Fornaciari أداة "Gremlin"، وفي أواخر عام 2017 أصبحت متاحة للجمهور كأول حل CE مؤسسي مُدار في العالم.
في عام 2019، تحولت CE إلى اعتبارات جدية للتبني، بشكل أساسي من قبل التجارة الإلكترونية وشركات التكنولوجيا الكبرى. وهذا مفهوم نظرًا للتأثير المباشر على الإيرادات بسبب التوقف الذي قد يحدث.
في عام 2020، أضافت "Amazon Web Services" (AWS) هندسة الفوضى إلى "إطار العمل جيد التصميم" (WAF)، وتم تقديم "محاكي حقن الأخطاء" (FIS) كخدمة لتشغيل تجارب الفوضى بشكل أصلي على AWS. وسرعان ما بدأت بعض الشركات الكبرى في تبني هندسة الفوضى.
في عام 2021، ولأول مرة على الإطلاق، نشرت Gremlin تقرير حالة هندسة الفوضى مُظهرةً أهمية هندسة الفوضى.
يُعد انخفاض متوسط الوقت اللازم للحل (MTTR) ومتوسط الوقت اللازم للاكتشاف (MTTD)، وتراجع عدد الأخطاء، وارتفاع مرونة النظام، من الفوائد التي خلصت إليها دراسة حول أثر هندسة السحابة (CE) في الشركات التي اعتمدتها.
من الأدوات التي يمكننا ذكرها Chaos Mesh وLitmus وChaosBlade، إلى جانب Gremlin وSimian Army وChaos Monkey المذكورة سابقًا. تتوفر أدوات أخرى أيضًا، لكنني سأترك هذا لك.
قد يشير استخدام هندسة الفوضى إلى أن بعض الشركات تستخدم استراتيجية اختبار "الإزاحة لليسار" الموضوعة في المراحل الأولى جداً من دورة حياة تطوير البرمجيات (SDLC).
وأخيرًا، إليك كيفية إعداد CE وفق أفضل الممارسات:
- تصميم مرونة النظام على مستويات البنية التحتية والشبكات والبيانات والتطبيقات والأفراد والثقافة.
- استخدم المهلات وإعادة المحاولات والبدائل الاحتياطية – وهي تقنيات اعتمدتها Netflix.
- عند البدء في صياغة فرضية، جرّب تقنية التفكير الحسابي.
- استخدم فريق هندسة الفوضى لتزويدك بكل ما تحتاجه لهندسة الفوضى.
- ثقّفوا أنفسكم وموظفيكم.
- استخدم استراتيجية النشر التدريجي والاختبار التدريجي (Canary Deployment and Canary Testing) فهي الطريقة الأكثر أمانًا لحقن الأخطاء ومراقبة النتائج.
يمكن أن يحقق اعتماد هندسة الفوضى (Chaos Engineering) عوائد على الاستثمار (ROI) فيما يتعلق بتوافر خدمات الشركة وموثوقيتها.
آمل أن يستخدم تطوير البرمجيات المستقبلي أفضل الاستراتيجيات والممارسات المتاحة والموضحة.
الملخص
هندسة الفوضى (Chaos Engineering) هي نهج منضبط لاختبار مرونة البرمجيات من خلال إدخال أعطال مضبوطة عمدًا في النظام. وبدلاً من الاعتماد فقط على الاختبار التقليدي، فإنها تساعد المؤسسات على فهم كيفية تصرف التطبيقات تحت الضغط الواقعي، بما في ذلك مشكلات البنية التحتية أو انقطاعات الشبكة أو الارتفاعات غير المتوقعة في حركة المرور. ومن خلال إجراء التجارب في بيئات مراقَبة، يمكن للفرق تحديد نقاط الضعف مبكرًا، وتحسين موثوقية النظام، وتقليل خطر التوقف المكلف في بيئة الإنتاج.
تُعد هذه الطريقة ذات قيمة خاصة للأنظمة واسعة النطاق وعالية التوافر حيث يمكن أن تؤثر الأعطال على الإيرادات والسمعة وثقة العملاء. تدعم هندسة الفوضى استجابة أفضل للحوادث، وتقلل من متوسط الوقت اللازم للكشف والحل، وتعزز استقرار النظام بشكل عام. ومع اعتمادها المثبت من قبل شركات مثل Netflix وAWS، أصبحت ممارسة مهمة لبناء أنظمة برمجية حديثة ومرنة.
هندسة الفوضى هي ممارسة تتضمن إدخال أعطال بشكل متعمد في النظام لاختبار مرونته وقدرته على تحمل الاضطرابات الواقعية. وهي تساعد الفرق على تحديد نقاط الضعف قبل أن تسبب مشكلات في بيئة الإنتاج.
الأنظمة الحديثة معقدة وموزعة، مما يجعلها أكثر عرضة للأعطال غير المتوقعة. تتيح هندسة الفوضى للمؤسسات اختبار هذه السيناريوهات بشكل استباقي، مما يقلل من وقت التوقف ويحسن الموثوقية ويحمي الإيرادات.
لا. يركّز الاختبار التقليدي على السلوكيات المتوقعة في بيئات مضبوطة، بينما تستكشف هندسة الفوضى الظروف غير المتوقعة في بيئات حقيقية أو شبيهة ببيئات الإنتاج للكشف عن نقاط الضعف الخفية في النظام.
يمكنه ذلك إذا لم يُدار بعناية. ومع ذلك، تتضمّن أفضل الممارسات إجراء تجارب مضبوطة ومراقَبة، غالباً مع ضمانات مثل عمليات النشر الكناري، لتقليل أي تأثير سلبي على المستخدمين أو تجنّبه.
تعد هندسة الفوضى (Chaos Engineering) الأكثر فائدة للأنظمة التي تتطلب توافرية عالية، مثل منصات التجارة الإلكترونية والتطبيقات المصرفية والخدمات الرقمية واسعة النطاق. كما يمكن إدخالها في وقت مبكر من دورة حياة التطوير لبناء المرونة منذ البداية.
اتبع أفضل استراتيجيات وممارسات تطوير البرمجيات. عهد بمشروعك إلى خبرائنا.
Marcin Zyga
الرئيس التنفيذي للذكاء الاصطناعي والمعلومات