مبادئ تصميم حمل العمل الحرج للمهمة

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

هام

هذه المقالة هي جزء من سلسلة حمل العمل الحرجة للمهمة في Azure Well-Architected . إذا لم تكن على دراية بهذه السلسلة، نوصيك بالبدء بما هو حمل العمل الحرج للمهمة؟

تصدي مبادئ التصميم ذات المهام الحرجة هذه ركائز الجودة ل Azure Well-Architected Framework وتوسعها - الموثوقيةوالأمانوتحسين التكلفةوالتميز التشغيليوكفاءة الأداء.

الموثوقية

الحد الأقصى من الموثوقية - السعي الأساسي للحل الأكثر موثوقية، وضمان فهم المفاضلات بشكل صحيح.

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

كفاءة الأداء

الأداء المستدام وقابلية التوسع - تصميم لقابلية التوسع عبر الحل الشامل دون اختناقات في الأداء.

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

التميز التشغيلي

العمليات حسب التصميم - مصممة لتدوم مع إدارة تشغيلية قوية وحازمة.

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

الأمان

آمن دائما - تصميم للأمان الشامل للحفاظ على استقرار التطبيق وضمان التوفر.

مبدأ التصميم	الاعتبارات
مراقبة أمان الحل بأكمله وتخطيط الاستجابات للحوادث	ربط أحداث الأمان والتدقيق بنمذجة صحة التطبيق وتحديد التهديدات النشطة. إنشاء إجراءات تلقائية ويدوية للاستجابة للحوادث باستخدام أدوات إدارة معلومات الأمان والأحداث (SIEM) للتعقب.
وضع نماذج واختبارات ضد التهديدات المحتملة	تأكد من تقوية الموارد المناسبة ووضع إجراءات لتحديد التهديدات المعروفة والتخفيف من حدتها، باستخدام اختبار الاختراق للتحقق من التخفيف من التهديدات، بالإضافة إلى تحليل التعليمات البرمجية الثابتة ومسح التعليمات البرمجية.
تحديد نقاط النهاية وحمايتها	مراقبة وحماية تكامل الشبكة لنقاط النهاية الداخلية والخارجية من خلال قدرات الأمان والأجهزة، مثل جدران الحماية أو جدران حماية تطبيقات الويب. استخدم أساليب الصناعة القياسية للحماية من ناقلات الهجوم الشائعة مثل هجمات رفض الخدمة الموزعة (DDoS)، مثل SlowLoris.
الحماية من الثغرات الأمنية على مستوى التعليمات البرمجية	تحديد الثغرات الأمنية على مستوى التعليمات البرمجية والتخفيف من حدتها، مثل البرمجة النصية عبر المواقع أو حقن SQL، ودمج تصحيح الأمان في دورات الحياة التشغيلية لجميع أجزاء قاعدة التعليمات البرمجية، بما في ذلك التبعيات.
أتمتة أقل امتياز واستخدامه	محرك الأتمتة لتقليل الحاجة إلى التفاعل البشري وتنفيذ أقل امتياز عبر كل من التطبيق ومستوى التحكم للحماية من النقل غير المصرح للبيانات وسيناريوهات الجهات الفاعلة الضارة.
تصنيف البيانات وتشفيرها	قم بتصنيف البيانات وفقا للمخاطر وتطبيق التشفير القياسي للصناعة في حالة الثبات وفي أثناء النقل، ما يضمن تخزين المفاتيح والشهادات بشكل آمن وإدارتها بشكل صحيح.

تحسين التكلفة

هناك مفاضلات واضحة في التكلفة مرتبطة بإدخال قدر أكبر من الموثوقية، والتي ينبغي النظر فيها بعناية في سياق متطلبات حمل العمل.

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

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

تصميم السحابة الأصلي

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

• محاذاة المخطط - دمج إمكانات خدمة Azure الجديدة والمحسنة القادمة عندما تصبح متاحة بشكل عام (GA) للبقاء بالقرب من الحافة الرائدة ل Azure.

• احتضان قدرات المعاينة والتخفيف من الثغرات المعروفة - بينما يتم إعطاء الأولوية للخدمات المتوفرة بشكل عام (GA) لقابلية الدعم، يتم استكشاف معاينات خدمة Azure بنشاط للتأسيس السريع، ما يوفر ملاحظات تقنية وقابلة للتنفيذ لمجموعات منتجات Azure لمعالجة الثغرات.

• محاذاة منطقة هبوط Azure - قابلة للنشر داخل منطقة Azure المنتقل إليها ومحاذاتها لمنهجية تصميم منطقة هبوط Azure، ولكن أيضا تعمل بكامل طاقتها وقابلة للنشر في بيئة عارية خارج منطقة هبوط.

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

مراجعة المخاوف الشاملة المرتبطة بأحمال العمل الحرجة للمهام.

مخاوف شاملة