المحتوى
- التحضير للفشل
- الخطوات التالية
- No Bugs، No Stress - دليلك خطوة بخطوة لإنشاء برامج لتغيير الحياة دون تدمير حياتك
- التعلم والتحسين من خلال التدريبات
المصدر: الضغط UA / iStockphoto
يبعد:
يجب أن تكون الأنظمة الحديثة قادرة على التعامل مع الفوضى لتجنب التوقف. ولهذا السبب من المهم أكثر من أي وقت مضى اختبار أنظمة شاملة وضمان مرونتها.
على الرغم من الجهود الكبيرة التي نبذلها لتجنبها ، فإن حوادث تكنولوجيا المعلومات جزء لا مفر منه من العمل - ومحاولة البقاء متوقفة عن وقت التوقف عن العمل التي تؤثر على الأعمال التجارية تزداد صعوبة. الأنظمة اليوم مقترنة بإحكام ومعقدة على نحو متزايد ، ومع وجود أجزاء متحركة أكثر ، تأتي المزيد من الفرص للأشياء الخاطئة.
هذا هو أحد الأسباب وراء تحول المزيد والمزيد من المؤسسات إلى الخدمات المصغرة لزيادة توفر الخدمة ومقاومة الفشل بشكل أفضل. ولكن على الرغم من أنها أماكن رائعة لكسر التطبيقات المتجانسة ، إلا أنها قد تؤدي أيضًا إلى زيادة مخاطر الفشل - ما لم يتم تصميمها صراحة مع مراعاة المرونة.
التحضير للفشل
نظرًا للطبيعة الفوضوية بطبيعتها للأنظمة الموزعة ، ينبغي تطوير الخدمات ليس فقط لتوقع الفشل ، ولكن لاستردادها تلقائيًا في حالة الفشل. هذا يعني إثارة الإخفاقات بشكل منتظم للتأكد من أن أنظمتك قادرة على التعامل مع الفوضى دون تعطيل الخدمة للعملاء النهائيين. ولتحقيق ذلك ، تحتاج إلى القدرة على محاكاة حركة المرور المشابهة للإنتاج في بيئات الاختبار.
بالطبع ، من الجيد اختبار المرونة قبل إجراء التغييرات على الإنتاج. إذا لم تقم بذلك ، فلن تتمكن من التحقق من أن خدماتك يمكن أن تدعم كلاً من الأحمال المتوسطة والقصيرة. في الواقع ، فإن الرهان الأكثر أمانًا هو ضمان قدرة منتجك على التعامل مع ضعف مبلغ الذروة دون الحاجة إلى زيادة الحجم.
عندما يتعلق الأمر باختبار المرونة ، لا ينبغي أن تكون الأدوات المناسبة قلقة للغاية بشأن كيفية معالجة الطلبات ، تمامًا حيث يكون لها التأثير الصحيح في النهاية. تذكر أنه في ظل ظروف معينة ، قد تفشل خدمة الإدخال في تسليم طلب إلى بقية النظام دون الإبلاغ عن الفشل. لا تخاطر بالمشاكل تحت رادار المراقبة من خلال التأكد من أن التحقق من البداية إلى النهاية يحدث في الواقع. (لمزيد من المعلومات ، راجع الأعطال التقنية: هل يمكننا التعايش معها؟)
الخطوات التالية
بعد فهم كيف تتصرف الخدمات تحت الحمل ، حان الوقت لبدء تقديم أحداث الفشل. كما هو الحال مع جميع اختبارات البرامج ، من الأفضل أن يكون لديك أدوات تلقائية تتيح لك إمكانية إعادة إنتاج السيناريوهات بسهولة وبسرعة ، بحيث يمكنك تنسيق الأحداث المعقدة التي تؤثر على تقنيات البنية التحتية المختلفة. بالإضافة إلى القدرة على التحقق من الإصلاحات والتغييرات في الخدمات ، يتيح لك ذلك تشغيل سيناريوهات الفشل العشوائي في أي بيئة وفي جدول زمني.
تعتمد أحداث الفشل الهادفة إلى حد كبير على تصميم خدماتك ، ويمكنك صياغة هذه الأسئلة بطرح أسئلة محددة ذات صلة بك. على سبيل المثال ، ما هو تأثير الأشخاص الذين يستخدمون الواجهة الأمامية عندما تصبح قاعدة البيانات غير قابلة للوصول لفترة زمنية معينة؟ هل يمكن لهؤلاء المستخدمين التنقل في واجهة مستخدم الويب؟ هل ما زال بإمكانهم إصدار تحديثات لمعلوماتهم ، وهل ستتم معالجة هذه التحديثات بشكل صحيح عندما تصبح قاعدة البيانات قابلة للوصول مرة أخرى؟
إذا قمت بتشغيل العديد من الخدمات المصغرة ، فيمكنك أن تسأل عما إذا كان هناك انقطاع عالمي في حالة تعطل أي خدمة فردية. أو إذا كان لديك آلية قائمة انتظار لتخزين الاتصال بين الخدمات ، فما الذي يحدث عندما تتوقف خدمة المستهلك (أو الخدمات) عن العمل؟ هل سيظل المستخدمون قادرين على العمل مع التطبيق الخاص بك؟ ونظرا لحمل متوسط ، كم من الوقت لديك قبل أن تفيض قوائم الانتظار وتبدأ في خسارة ق؟
No Bugs، No Stress - دليلك خطوة بخطوة لإنشاء برامج لتغيير الحياة دون تدمير حياتك
لا يمكنك تحسين مهارات البرمجة لديك عندما لا يهتم أحد بجودة البرنامج.
بمجرد تحديد بعض الأسئلة الأساسية حول البنية الأساسية الخاصة بك ، يمكنك بعد ذلك البدء في سرد طرق مختلفة لمحاكاة هذه الإخفاقات. قد يكون كافيا لإيقاف خدمة معينة أو خادم قاعدة البيانات. قد ترغب في حظر الخيط الرئيسي للخدمة لمحاكاة حالة توقف تام ، في حين أن الحاوية الخاصة بها لا تزال تستجيب وتعمل. قد تقرر إدخال قواعد في شبكتك لمنع حركة المرور بين خدمات معينة. في بيئات Linux ، يمكنك استخدام أدوات مثل "tc" لمحاكاة مواقف الشبكة مثل الحزم العالية أو الحزم المسقطة أو التالفة أو المكررة. (قد يكون من المهم إشراك المستخدمين في الاختبار. اقرأ المزيد في 4 أسباب لماذا يحتاج المستخدمون النهائيون للمشاركة في الاختبار قبل UAT.)
التعلم والتحسين من خلال التدريبات
أحد الجوانب الأكثر أهمية في إنشاء سيناريوهات الفشل هو أنها يمكن أن تكشف جميع الطرق المحتملة التي يمكن أن يفشل بها النظام ، وبالتالي نحت الطريق إلى منطق الشفاء الذاتي. سيتعرف فريقك على خطوات استعادة الخدمات يدويًا - تمرين رائع ، بالمناسبة ، للتأكد من أنهم قادرون على القيام بذلك ضمن اتفاقيات مستوى الخدمة. يمكن العمل على أتمتة عملية الاسترداد هذه ، ولكن في غضون ذلك ، يمكنك أن تشعر بالراحة مع العلم أن فريقك قد تابع عملية إعادة الخدمات إلى مسارها الصحيح. من خلال جعل سيناريوهات الفشل عشوائية ومنتظمة وعدم الإفصاح عن التفاصيل الكاملة للتشغيل ، يمكنك أيضًا تضمين الاكتشافات والتشخيصات في التدريبات - التي تعد ، في النهاية ، جزءًا مهمًا من اتفاقيات مستوى الخدمة.
في جوهرها ، تأخذ هندسة الفوضى تعقيد النظام كما هو محدد ، وتختبره من خلال محاكاة الظروف الجديدة والغريبة ، ويلاحظ كيف يستجيب النظام. هذا هو ما تحتاجه فرق هندسة البيانات لإعادة تصميم النظام وإعادة تكوينه لتحقيق مرونة أعلى. هناك العديد من الفرص لتعلم أشياء جديدة ومفيدة. على سبيل المثال ، قد تجد حالات لا تحصل فيها الخدمات على تحديثات عند تغيير الخدمات المتلقية للمعلومات ، أو المناطق التي تفتقد فيها المراقبة تمامًا. لا يوجد نقص في الطرق المثيرة لجعل منتجك أكثر مرونة وقوة!