هندسة الفوضى!
Chaos Engineering
مع صعود الميكروسيرفزس والDistributed Cloud Architectures، نمى الويب بشكل متزايد. ,وأصبحنا نعتمد على هذه الأنظمة أكثر من أي وقت مضى، ومع ذلك فقد أصبح من الصعب التنبؤ بفشلها والمشاكل الناجمة عن إستخدامها
تُسبب هذه المشاكل انقطاعًا مكلفًا للشركات Outage. إن انقطاع الخدمات يضر بالمستخدمين الذين يحاولون التسوق والتعامل في الأعمال وإنجاز العمل.
حتى الانقطاعات القصيرة يمكن أن تؤثر على النتيجة النهائية للشركة، وبالتالي فإن تكلفة التوقف أصبحت مؤشر KPI للعديد من الفرق الهندسية داخل الشركات
على سبيل المثال، في عام 2017، 98٪ من المؤسسات سجلت إن التوقف عن العمل لمدة ساعة واحدة سيكلف أعمالهم أكثر من 100،000 دولار. يمكن أن يكلف انقطاع واحد شركة بملايين الدولارات.
أوضح الرئيس التنفيذي لشركة بريتش إيروايز مؤخراً كيف أن أحد الإخفاقات العالقة لعشرات الآلاف من ركاب الخطوط الجوية البريطانية (BA) في مايو 2017 كلف الشركة 80 مليون جنيه استرليني (102.19 مليون دولار أمريكي).
تحتاج الشركات إلى حل لهذا التحدي، فانتظار الانقطاع المكلف التالي ليس خيارًا. لمواجهة التحدي المباشر، تتجه المزيد والمزيد من الشركات إلى Chaos Engineering (هندسة الفوضى)
هندسة الفوضى هي الطب الوقائي
هي طريقة منضبطة لتحديد حالات الفشل قبل حدوثها. من خلال اختبار استباقي كيف يستجيب النظام تحت الضغط، يمكنك تحديد وإصلاح الأعطال قبل أن يتم نشر الموضوع في الأخبار
تتيح لك Chaos Engineering مقارنة ما تعتقد أنه سيحدث مع ما يحدث بالفعل في أنظمتك. أنت حرفيا "تضرب الأنظمة عن عمد" لمعرفة كيفية بناء أنظمة أكثر مرونة.
تاريخ موجز لهندسة الفوضى
2010
أنشأ فريق مهندسي الأدوات بشركة نت فليكس أداة Chaos Monkey. تم إنشاء Chaos Monkey استجابةً لانتقال Netflix للعمل على البنية التحتية السحابية التي توفرها Amazon Web Services، والحاجة إلى التأكد من أن فقدان أحد الخوادم على Amazon لن يؤثر على تجربة البث عبر Netflix.
2011
في عام 2011 وُلدت مجموعة من الأدوات تحت اسم Simian Army
تقوم تلك الأدوات بإضافة أوضاع فشل إضافية على Chaos Monkey والتي من شأنها أن تسمح باختبار مجموعة أكثر اكتمالا من حالات الفشل، وبالتالي بناء القدرة على الصمود أكثر. وعندما تعمل على بيئة الكلاود يجب ان تهتم دائماً
ب redundancy،fault-tolerance.
نظرًا لعدم وجود مكون واحد يمكنه ضمان وقت التشغيل بنسبة 100٪ (وحتى أغلى الأجهزة , والخوادم تفشل أيضاً) ، فيتعين علينا تصميم بنية سحابية قوية بحيث يمكن أن يفشل أي جزء دون التأثير على توفر النظام بأكمله "(Netflix ، 2011).
2012
قامت شركة نت فليكس بنشر كود مشروع Chaos Monkey على GitHub مع وضع المقولة التالية
وجدنا أن أفضل دفاع ضد الإخفاقات غير المتوقعة الكبرى هو الفشل في كثير من الأحيان. من خلال التسبب في حالات الفشل بشكل متكرر، نجبر خدماتنا على أن تكون مبنية بطريقة أكثر مرونة
2014
أنشأت شركة نت فليكس مسمى وظيفي جديد Chaos Engineer وفي شهر أكتوبر من نفس العام تم إطلاق أداة جديدة Failure Injection Testing – FIT والمبنية بشكل أساسي على Simian Army والتي أعطت المطورين تحكم أكثر في إنشاء حالات الفشل وبالفعل تم تجربتها على خوادم فعلية وسببت إخفاقات مفتعلة سببت إزعاج كبير للمطورين ومع التجربة لأكثر من مرة يقل فيها الجانب السلبي لحالات الإخفاق تدريجياً.
ما هي مبادئ هندسة الفوضى؟
تتضمن إجراء تجارب مدروسة ومخطط لها وتعلمنا كيفية تتصرف أنظمتنا في مواجهة الفشل
تتبع هذه التجارب ثلاث خطوات:
1. التخطيط:
إنشاء الفرضية والسيناريو وتوقع ماذا سيحدث!
2. تنفيذ الفرضية:
تجربة اختبارات صغيرة على الأنظمة والتي ستٌعلمك شيء ما يمكنك تجنبه مستقبلاً
3. زيادة الضغط:
بعد التجربة تسأل نفسك هل وجدت مشكلة؟ إذا كانت الإجابة بنعم أنت على الطريق الصحيح
وإذا كانت ب لا قم بزيادة الضغط على الأنظمة وتجربة سيناريو أقوى للوصول لمشكلة! وبالتالي تفهم أكثر لسلوك الأنظمة وقت استخدامها من قبل العملاء
ماهي الشركات التي تمارس Chaos Engineering ؟
على سبيل المثال لا الحصر
Twilio, Netflix, LinkedIn, Facebook, Google, Microsoft, Amazon
ولكن في كثير من القطاعات التقليدية مثل البنوك اعتمدت على نفس الطريقة على سبيل المثال في 2014 قام بنك أستراليا الوطني بنقل كل خدماته إلى بيئة أمازون السحابية واعتمد على منهجية هندسة الفوضى التي نتحدث عنها وذلك لتقليل عدد الشكاوى التي يتلقاها البنك من العملاء على خدماته
لماذا نضرب الأنظمة عن عمد؟!
من المفيد التفكير في لقاح. كلقاح الأنفلونزا حيث تحقن نفسك بكمية صغيرة من جسم غريب محتمل الضرر من أجل الوقاية من المرض. Chaos engineering هي أداة نستخدمها لبناء مثل هذه المناعة في أنظمتنا الفنية عن طريق حقن الضرر (مثل latency, CPU failure, or network black holes, storage issue) من أجل العثور على نقاط الضعف المحتملة وتخفيفها.
تتمتع هذه التجارب بفائدة إضافية تتمثل في مساعدة الفرق على بناء ذاكرة قوية في حل الانقطاعات الشبيهة. وأيضاً نتعرض لمشاكل غير معروفة قد تؤثر على أنظمتنا وعملائنا.
مغالطات في الأنظمة الموزعة (Distributed Systems)!
دائما ما يفترض المطورين الجدد على الأنظمة الموزعة عدة افتراضات خطأ مثل
· الشبكة ممتازة
· معدل بطيء الأنظمة لدينا هو صفر (Latency)
· النطاق التي تتحمله الشبكة لانهائي (Bandwidth)
· الشبكة مؤمنة
· تصميم النظام ثابت لا يتغير أبداً
· يكون هناك مسئول واحد فقط (Administrator)
· المساحة التخزينية مفتوحة!
· قواعد البيانات تتحمل المزيد!
كل هذه المغالطات تقودنا لافتراض تجارب لإفشال النظام عن عمد مثل
Packet-loss attacks
Latency attacks
على سبيل المثال انقطاع واحد في الشبكة من الممكن أن يسبب مشاكل كثيرة للتطبيقات مثل:
· قد تتعطل عن العمل لانتظارها نتيجة من الخوادم او الخوادم لا تستقبل الطلبات من الأساس!
· التطبيقات تستهلك الذاكرة بشكل كبير حتى بعد حل مشكلة الشبكة
· التطبيقات لا تعود للعمل كما كانت
· التطبيقات تحتاج لعمل إعادة تشغيل لها
كل هذه الأمثلة تتطلب تجارب لاختبارها ووضع الحل المناسب حين حدوثها فوراً
ماهي فائدة Chaos Engineering بالنسبة للعملاء والبيزنس والتقنيين
العملاء: زيادة توافر ومتانة الخدمة لا يعني أي انقطاع يعطل حياتهم اليومية
البيزنس: يمكن أن تساعد في منع خسائر كبيرة للغاية في تكاليف الإيرادات والصيانة، جعل المهندسين أكثر سعادة وأكثر انخراطًا، وتحسين التدريب أثناء الطلب للفرق الهندسية (On-Call)، وتحسين برنامج إدارة المشاكل (Incidents)(SEVs) للشركة بأكملها
التقنيين: التقليل من المشاكل المرسلة من العملاء (Incidents) – التقليل من وقت الدعم خارج الدوام (On-Call Support) -المزيد من فهم سلوكيات الأنظمة وقت الفشل – تحسين وتطوير تصميم الأنظمة لتصبح أكثر قوة – وقت أسرع لتحديد المشكلة – تقليل تكرار المشاكل
ما هي تجارب Chaos Engineering التي تؤديها أولاً؟
تُصنف التجارب حسب الجدول التالي:
لتوضيح التجارب بمثال عملي:
سنفترض ان لدينا Cluster قواعد بيانات وعدد السيرفرات 100 مع multiple shards للسيرفر الواحد
لدينا منطقتين 2 Regions وفي المنطقة الواحدة لدينا قاعدة بيانات أساسية Primary مع 2 نسخة مطابقة Replicas وفي المنطقة الأخرى نفس التصميم
إذا بدأنا في تطبيق الجدول السابق على المثال سيكون كالتالي
معروف – معروف
نحن نعلم أنه إذا أغلقنا احد ال replica سيتم حذفها من ال Cluster وأيضا نعلم ان أي replica جديدة سيتم أخذها من ال primary وستضاف لل Cluster
معروف – غير معروف
نحن نعلم أن عملية نسخ نسخه replica من ال primary ستحدث ، لأن لدينا Logs تؤكد نجاحها أو فشلها ، لكننا لا نعرف المتوسط الأسبوعي للوقت الذي يستغرق لمواجهة فشل في إضافة Replica إلى Cluster بشكل فعال.
نعلم أننا سنتلقى تنبيهًا بأن Cluster يحتوى على نسخة متماثلة واحدة Replica فقط بعد 5 دقائق ، لكننا لا نعرف ما إذا كان يجب ضبط حد التنبيه الخاص بنا threshold لمنع حدوث المشاكل بشكل أكثر فعالية.
غير معروف – معروف
إذا قمنا بإغلاق نسختين متماثلتين Replicas من ال Cluster في نفس الوقت ، فإننا لا نعرف بالضبط الوقت المتوسط خلال صباح الاثنين مثلاً الذي سيُستغرق منا لاستنساخ نسختين جديدتين من ال Primary الحالي. لكننا نعرف أن لدينا نسخة احتياطية في منطقة أخرى مثيلة للPrimary واثنين من النسخ المتماثلة التي سيكون بها كل ال Transactions.
غير معروف – غير معروف
لا نعرف بالضبط ما الذي سيحدث إذا قمنا بإغلاق الCluster في منطقتنا الرئيسية ، ولا نعرف ما إذا كانت المنطقة الإحتياطية ستتمكن من الFailover بشكل فعال لأننا لم نقم بتشغيل هذا السيناريو من قبل.
بناء عليه سنقوم بعمل chaos experiments
في حالة معروف – معروف
قم بإغلاق replica واحدة وقياس الوقت الذي يستغرقه
الكشف عن الإغلاق ، وإزالة replica ، ,والبدء في النسخ ، وإكمال النسخ ، والإضافة إلى الCluster.
قبل أن تبدأ هذه التجربة ، قم بزيادة ال Replicas من اثنين إلى ثلاثة. قم بتشغيل تجربة إيقاف التشغيل بتردد منتظم ولكن حاول تجنب التجربة التي ينتج عنها 0 Replicas في أي وقت.
قم بالإبلاغ عن متوسط الوقت المستغرق في الاسترداد لفشل إيقاف تشغيل replica وقم بتقسيمه على اليوم لحساب ساعات الذروة.
في حالة معروف – غير معروف
استخدم نتائج وبيانات التجربة السابقه للإجابة على الأسئلة التي ستكون حاليًا "مجهولة بالنسبة لك". ستتمكن الآن من معرفة تأثير المتوسط الأسبوعي للوقت الذي تستغرقه في مواجهة فشل في إضافة Replica إلى Cluster بشكل فعال. ستعرف أيضًا ما إذا كانت 5 دقائق تمثل وقت تنبيه مناسب لمنع حدوث المشاكل مع العملاء SEVs.
في حالة غير معروف – معروف
قم بزيادة عدد replicas إلى أربعة قبل إجراء هذه التجربة. قم بإيقاف تشغيل اثنين من replicas في نفس الوقت ، قم بجمع الوقت المتوسط خلال صباح الاثنين على مدى عدة أشهر لتحديد المدة التي ستستغرقها لنسخ نسختين جديدتين من النسخة الأساسية الحالية. قد تحدد هذه التجربة مشكلات غير معروفة ، على سبيل المثال ، يتعذر على النسخة الأساسية Primary معالجة الحمل من الاستنساخ Cloning والنسخ الاحتياطي في نفس الوقت وتحتاج إلى استخدام replicas بشكل أفضل.
في حالة غير معروف – غير معروف
ستقوم بإيقاف تشغيل مجموعة كاملة (Cluster). قد يحدث هذا الفشل بشكل غير متوقع، لكننا لست مستعدون بعد لمعالجته. حدد أولوية العمل للتعامل مع سيناريو الفشل هذا قبل إجراء chaos experiments
وبذلك نكون أوضحنا مفهوم هندسة الفوضى بشكل عام وتاريخها والممارسات الخاصة بها
تحياتي
أحمد سمير