الصيانة الروتينية (المخطط لها) لخدمة تطبيقات Azure

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

هام

لا يعد التغيير العاجل أو إهمال الوظائف جزءا من الصيانة الروتينية. لمزيد من المعلومات، راجع نهج دورة الحياة الحديثة.

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

ما المتوقع

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

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

تظهر لقطة الشاشة التالية مثالا لحدث صيانة.

Screenshot of a maintenance event in the Azure portal.

بالترتيب من أعلى إلى أسفل، يوضح المثال:

  • عنوان وصفي لحدث الصيانة.
  • المناطق والاشتراكات المتأثرة.
  • نافذة الصيانة المتوقعة.

الأسئلة الشائعة

لماذا تستغرق الصيانة وقتا طويلا؟

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

لماذا أتلقى الكثير من الإعلامات؟

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

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

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

لا نتوقع أن تتحمل المواقع أي انتهاكات لاتفاقية مستوى الخدمة (SLA) أثناء نوافذ الصيانة.

كيف تضمن الترقية التشغيل السلس لتطبيقاتي؟

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

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

هل تنعكس ساعات العمل؟

تم تحسين عمليات الصيانة لتبدأ خارج ساعات العمل القياسية من 9 صباحا إلى 5 مساء. إحصائيا، هذا هو أفضل وقت لأي انقطاع وإعادة تشغيل أحمال العمل لأن هناك ضغطا أقل على النظام (في تطبيقات العملاء وبشكل عابر على النظام الأساسي نفسه). بالنسبة لخطط App Service وApp Service Environment v2، يمكن أن تستمر الصيانة في ساعات العمل أثناء أحداث الصيانة الأطول.

ما هي خياراتي للتحكم في الصيانة الروتينية؟

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

هل يمكنني إعداد تطبيقاتي بشكل أفضل لإعادة التشغيل؟

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

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

لقد كانت تطبيقاتي متصلة بالإنترنت، ولكن الأمور أسوأ منذ بدء ظهور هذه الإعلامات. ما التغير الذي حدث؟

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

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

احصل على مزيد من المعلومات حول إشعارات الصيانة من خلال قراءة منشور المدونة إشعارات الصيانة المخطط لها الروتينية لخدمة تطبيقات Azure.