الإجراءات التشغيلية لأحمال العمل الحرجة للمهام على Azure

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

يستكشف مجال التصميم هذا كيفية تنفيذ إجراءات تشغيلية فعالة ومتسقة.

هام

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

عمليات DevOps

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

يجب أن يكون فريق DevOps لتطبيق مهم للغاية مسؤولا عن هذه المهام:

• إنشاء وإدارة موارد التطبيقات والبنية الأساسية عبر أتمتة CI/CD.
• مراقبة التطبيق ومراقبته.
• التحكم في الوصول استنادا إلى الدور في Azure (RBAC) وإدارة الهوية لمكونات التطبيق.
• إدارة الشبكة لمكونات التطبيق.
• إدارة التكلفة لموارد التطبيق.

يقوم DevSecOps بتوسيع نموذج DevOps من خلال دمج مراقبة الأمان وتدقيق التطبيقات وضمان الجودة مع التطوير والعمليات طوال دورة حياة التطبيق. فرق DevOps مطلوبة للسيناريوهات الحساسة للأمان والمنظمة بدرجة عالية لضمان دمج الأمان طوال دورة حياة التطوير بدلا من مرحلة إصدار أو بوابة محددة.

اعتبارات التصميم

• عملية الإصدار والتحديث. تجنب العمليات اليدوية لأي تغيير في مكونات التطبيق أو البنية الأساسية. يمكن أن تؤدي العمليات اليدوية إلى نتائج غير متسقة.

• التبعيات على فرق تكنولوجيا المعلومات المركزية. قد يكون من الصعب تطبيق عمليات DevOps عندما تكون هناك تبعيات ثابتة على الوظائف المركزية لأن هذه التبعيات تمنع العمليات الشاملة.

• إدارة الوصول والهوية. يمكن لفرق DevOps التفكير في أدوار Azure RBAC الدقيقة لمختلف الوظائف التقنية، مثل AppDataOps لإدارة قاعدة البيانات. تطبيق نموذج ثقة معدومة عبر أدوار DevOps.

توصيات التصميم

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

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

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

• تخصيص نسبة من القدرة الهندسية خلال كل دورة متكررة لدفع تحسينات النظام الأساسي وتعزيز الموثوقية. نوصي بتخصيص 20-40 بالمائة من السعة لهذه التحسينات.

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

  يمكنك أيضا استخدام معايير الهندسة الشائعة والبيانات الاصطناعية المرتبطة بها، مثل نهج Azure وموارد Terraform لأنماط التصميم الشائعة، عبر أحمال العمل الأخرى داخل النظام البنائي للتطبيق الأوسع لمؤسستك.

• تطبيق نموذج ثقة معدومة في بيئات التطبيقات الهامة. استخدم تقنيات مثل Microsoft Entra إدارة الهويات المتميزة لضمان اتساق العمليات وعدم حدوثها إلا من خلال عمليات CI/CD أو الإجراءات التشغيلية التلقائية.

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

• تحديد عمليات الطوارئ للوصول في الوقت المناسب إلى بيئات الإنتاج. تأكد من وجود حسابات break glass في حالة وجود مشكلات خطيرة مع موفر المصادقة.

• ضع في اعتبارك استخدام AIOps لتحسين الإجراءات التشغيلية والمشغلات باستمرار.

عمليات التطبيق

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

اعتبارات التصميم

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

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

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

• تعديل الموارد وحذفها. يمكنك تأمين موارد Azure لمنع تعديلها أو حذفها. ومع ذلك، تقدم التأمينات النفقات العامة للإدارة في مسارات التوزيع. بالنسبة لمعظم الموارد، نوصي بعملية RBAC قوية مع قيود مشددة بدلا من تأمين الموارد.

توصيات التصميم

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

• تحديد أولويات استخدام التحجيم التلقائي الأصلي ل Azure للخدمات التي تدعمه. بالنسبة للخدمات التي لا تدعم التحجيم التلقائي الأصلي، استخدم العمليات التشغيلية التلقائية لتوسيع نطاق الخدمات. استخدم وحدات القياس مع خدمات متعددة لتحقيق قابلية التوسع.

• استخدم الإمكانات الأصلية للنظام الأساسي للنسخ الاحتياطي والاستعادة، ما يضمن محاذاتها مع متطلبات RTO/RPO واستبقاء البيانات. حدد استراتيجية لاستبقاء النسخ الاحتياطي على المدى الطويل حسب الحاجة.

• استخدم الإمكانات المضمنة لإدارة شهادة SSL وتجديدها، مثل تلك التي يوفرها Azure Front Door.

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

• ممارسة عمليات الاسترداد مسبقا، على الموارد والبيانات غير الإنتاجية، كجزء من الاستعدادات القياسية لاستمرارية الأعمال.

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

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

• تجنب استخدام تأمين الموارد على الموارد الإقليمية سريعة الزوال. بدلا من ذلك، الاعتماد على الاستخدام المناسب للبنية الأساسية لبرنامج ربط العمليات التجارية RBAC وCI/CD للتحكم في التحديثات التشغيلية. يمكنك تطبيق تأمين الموارد لمنع حذف الموارد العمومية طويلة الأمد.

إدارة التحديثات

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

اعتبارات التصميم

• المحاذاة مع مخططات Azure. قم بمحاذاة حمل العمل مع مخططات Azure بحيث يتم تحديث موارد النظام الأساسي وتبعيات وقت التشغيل بانتظام.

• الكشف التلقائي عن التحديثات. إعداد العمليات لمراقبة التحديثات واكتشافها تلقائيا. استخدم أدوات مثل GitHub Dependabot.

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

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

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

توصيات التصميم

• مراقبة هذه الموارد وإبقائها محدثة:

  • النظام الأساسي لاستضافة التطبيق. على سبيل المثال، تحتاج إلى تحديث إصدار Kubernetes في Azure Kubernetes Service (AKS) بانتظام، خاصة بالنظر إلى أن دعم الإصدارات القديمة غير مستدام. تحتاج أيضا إلى تحديث المكونات التي تعمل على Kubernetes، مثل cert-manager وAzure Key Vault CSI، ومحاذاتها مع إصدار Kubernetes في AKS.
  • المكتبات الخارجية وSDKs (.NET، Java، Python).
  • موفرو Terraform.

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

• إنشاء إجراء تلقائي لإزالة الإصدارات القديمة من الصور من Azure Container Registry.

إدارة البيانات السرية

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

تدعم العديد من خدمات Azure المصادقة Microsoft Entra بدلا من الاعتماد على سلاسل / مفاتيح الاتصال. يؤدي استخدام معرف Microsoft Entra إلى تقليل النفقات التشغيلية بشكل كبير. إذا كنت تستخدم حل إدارة سرية، فيجب أن يتكامل مع الخدمات الأخرى، ويدعم التكرار النطاقي والإقليمي، ويوفر التكامل مع معرف Microsoft Entra للمصادقة والتخويل. يوفر Key Vault هذه الميزات.

اعتبارات التصميم

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

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

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

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

  لتنفيذ التحديثات السرية أو التدوير، تحتاج إلى إجراء إعادة توزيع كاملة.

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

  تتضمن خيارات التخزين الشائعة Azure Key Vault Provider لبرنامج تشغيل Secrets Store CSIوakv2k8s. يتوفر أيضا حل Azure أصلي، Key Vault إعدادات التطبيق المشار إليها.

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

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

  ومع ذلك، بالنسبة لهذا النهج، تتطلب مكونات التطبيق تبعية مباشرة واتصالا بنظام الإدارة السرية. وهذا يجعل من الصعب اختبار المكونات بشكل فردي وعادة ما يتطلب استخدام SDK.

توصيات التصميم

• عندما يكون ذلك ممكنا، استخدم مصادقة Microsoft Entra للاتصال بالخدمات بدلا من استخدام سلاسل الاتصال أو المفاتيح. استخدم أسلوب المصادقة هذا مع الهويات المدارة من Azure حتى لا تحتاج إلى تخزين الأسرار على النظام الأساسي للتطبيق.

• استفد من إعداد انتهاء الصلاحية في Key Vault، وقم بتكوين التنبيه لانتهاء الصلاحية القادمة. قم بإجراء جميع تحديثات المفاتيح والبيانات السرية والشهادات باستخدام عملية الإصدار القياسية.

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

• لتجنب الحاجة إلى إدارة بيانات اعتماد كيان الخدمة أو مفاتيح واجهة برمجة التطبيقات، استخدم الهويات المدارة بدلا من كيانات الخدمة للوصول إلى Key Vault كلما أمكن ذلك.

• تنفيذ أنماط الترميز لضمان إعادة استرداد البيانات السرية عند حدوث فشل في التخويل في وقت التشغيل.

• تطبيق عملية تدوير المفاتيح التلقائية بالكامل التي تعمل بشكل دوري داخل الحل.

• استخدم إعلام المفتاح بالقرب من انتهاء الصلاحية في Azure Key Vault للحصول على تنبيهات حول انتهاء الصلاحية القادمة.

اعتبارات خاصة ب IaaS عند استخدام الأجهزة الظاهرية

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

اعتبارات التصميم

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

توصيات التصميم

• تجنب العمليات اليدوية على الأجهزة الظاهرية وتنفيذ العمليات المناسبة لنشر التغييرات ونشرها.

  • أتمتة توفير موارد Azure باستخدام حلول البنية الأساسية كتعلم برمجي مثل قوالب Azure Resource Manager (ARM) أو Bicep أو Terraform أو حلول أخرى.

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

• تأكد من وجود استراتيجيات للرجوع إلى آخر حالة صحية معروفة إذا لم يعمل الإصدار الأحدث بشكل صحيح.

• إنشاء نسخ احتياطية متكررة لأحمال العمل ذات الحالة، والتأكد من أن مهام النسخ الاحتياطي تعمل بشكل فعال، وتنفيذ التنبيهات لعمليات النسخ الاحتياطي الفاشلة.

• مراقبة الأجهزة الظاهرية واكتشاف حالات الفشل. يمكن أن تأتي البيانات الأولية للمراقبة من مجموعة متنوعة من المصادر. تحليل أسباب المشاكل.

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

• حدد أولويات استخدام مجموعات مقياس الجهاز الظاهري بدلا من الأجهزة الظاهرية لتمكين قدرات مثل المقياس والتحجيم التلقائي وتكرار المنطقة.

• تحديد أولويات استخدام الصور القياسية من Azure Marketplace بدلا من الصور المخصصة التي تحتاج إلى الحفاظ عليها.

• استخدم Azure VM Image Builder أو أدوات أخرى لأتمتة عمليات الإنشاء والصيانة للصور المخصصة حسب الحاجة.

بالإضافة إلى هذه التوصيات المحددة، طبق أفضل الممارسات للإجراءات التشغيلية لسيناريوهات التطبيقات الحرجة للمهام حسب الاقتضاء.

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

راجع نمط البنية لسيناريوهات التطبيق ذات المهام الحرجة:

نمط البنية