مقدمة في Fault Analysis Service

تم تصميم Fault Analysis Service لاختبار الخدمات المنشأة على Microsoft Azure Service Fabric. باستخدام Fault Analysis Service، يمكنك إحداث أخطاء ذات مغزى وتشغيل سيناريوهات اختبار كاملة ضد تطبيقاتك. تمارس هذه الأخطاء والسيناريوهات وتتحقق من صحة الحالات والتحولات العديدة التي ستختبرها الخدمة طوال حياتها، وكل ذلك بطريقة محكومة وآمنة ومتسقة.

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

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

السيناريوهات عبارة عن عمليات معقدة تتكون من إجراء واحد أو أكثر. توفر Fault Analysis Service سيناريوهين كاملين مضمنين:

• Chaos Scenario
• Failover Scenario

الاختبار كخدمة

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

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

اختبار الأنظمة الموزعة

يجعل Service Fabric مهمة كتابة وإدارة التطبيقات القابلة للتطوير الموزعة أسهل بشكل كبير. تسهل Fault Analysis Service اختبار التطبيق الموزع بالمثل. هناك ثلاث مشكلات رئيسية يجب حلها أثناء الاختبار:

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

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

محاكاة/إنشاء سيناريوهات الفشل في العالم الحقيقي

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

1. من العميل، قم بإصدار طلب عقدة إيقاف التشغيل.

2. أرسل الطلب إلى العقدة اليمنى.

   أ. إذا لم يتم العثور على العقدة، يجب أن تفشل.

   ب. إذا تم العثور على العقدة، يجب أن تعود فقط في حالة إغلاق العقدة.

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

توليد الأحداث والسيناريوهات المطلوبة

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

1. يتم تسجيل حصة الكتابة فقط للنسخ المتماثلة عند النسخ المتماثل. جميع النسخ المتماثلة الثانوية متخلفة عن الأساسي.
2. ينخفض حصة الكتابة بسبب انخفاض النسخ المتماثلة (بسبب انخفاض حزمة التعليمات البرمجية أو العقدة).
3. لا يمكن استعادة حصة الكتابة مرة أخرى بسبب فقد بيانات النسخ المتماثلة (بسبب تلف القرص أو إعادة تصوير الجهاز).

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

تجربة موحدة عبر بيئات مختلفة

جرت العادة على إنشاء ثلاث مجموعات مختلفة من الخبرات، واحدة لبيئة التطوير، وواحدة للاختبارات، وواحدة للإنتاج. النموذج كان:

1. في بيئة التطوير، أنتج انتقالات الحالة التي تسمح باختبارات الوحدة للطرق الفردية.
2. في بيئة الاختبار، أنتج حالات فشل للسماح باختبارات شاملة تمارس سيناريوهات فشل مختلفة.
3. حافظ على بيئة الإنتاج نقية لمنع أي أعطال غير طبيعية ولضمان وجود استجابة بشرية سريعة للغاية للفشل.

في Service Fabric، من خلال Fault Analysis Service، نقترح تغيير ذلك واستخدام نفس المنهجية من بيئة المطورين إلى الإنتاج. هناك طريقتان لتحقيق ذلك:

1. للحث على حالات الفشل الخاضعة للرقابة، استخدم Fault Analysis Service APIs من بيئة المربع الواحد وصولاً إلى نظام مجموعات الإنتاج.
2. لإعطاء مجموعة النظام الدفع اللازم لإحداث الحث التلقائي للفشل، استخدم Fault Analysis Service لإنشاء حالات فشل تلقائية. يتيح التحكم في معدل الفشل من خلال التكوين إمكانية اختبار نفس الخدمة بشكل مختلف في بيئات مختلفة.

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

استخدام Fault Analysis Service

C#‎

توجد ميزات Fault Analysis Service في مساحة الاسم System.Fabric في حزمة Microsoft.ServiceFabric NuGet. لاستخدام ميزات Fault Analysis Service، ضمِّن حزمة nuget كمرجع في مشروعك.

PowerShell

لاستخدام PowerShell، يجب عليك تثبيت Service Fabric SDK. بعد تثبيت SDK، يتم تحميل وحدة ServiceFabric PowerShell تلقائياً لتستخدمها.

الخطوات التالية

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

ابدأ في اختبار تطبيقاتك وخدماتك باستخدام سيناريوهات الاختبارالمضمنة، أو قم بتأليف سيناريوهات الاختبار الخاصة بك باستخدام إجراءات الخطأ التي توفرها Fault Analysis Service.