مشاركة عبر

اعتبارات لتحديث حل متعدد المستأجرين

  • مقالة

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

عند التخطيط لاستراتيجية لتحديث الحل الخاص بك، تحتاج إلى:

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

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

متطلبات عملائك

يؤخذ بعين الاعتبار الأسئلة التالية:

  • التوقعات والمتطلبات: هل لدى عملائك توقعات أو متطلبات حول متى يمكن تحديثهم؟ قد يتم إبلاغك بها رسمياً في العقود أو اتفاقيات مستوى الخدمة، أو قد تكون غير رسمية.
  • نوافذ الصيانة: هل يتوقع عملاؤك نوافذ صيانة معرفة من قبل الخدمة أو حتى نوافذ صيانة معرفة ذاتيا؟ قد يحتاجون إلى التواصل مع عملائهم بشأن أي انقطاعات محتملة.
  • الانظمه: هل لدى عملائك أي مخاوف تنظيمية تتطلب موافقة إضافية قبل تطبيق التحديثات؟ على سبيل المثال، إذا قدمت حلاً صحياً يتضمن مكونات إنترنت الأشياء، فقد تحتاج إلى الحصول على موافقة من United States Food and Drug Administration (FDA) قبل تطبيق التحديث.
  • حساسيه: هل أي من عملائك حساس بشكل خاص أو مقاوم لتطبيق التحديثات؟ حاول أن تفهم السبب. على سبيل المثال، إذا قاموا بتشغيل متجر فعلي أو موقع ويب للبيع بالتجزئة، فقد يرغبون في تجنب التحديثات حول الجمعة السوداء، لأن المخاطر أعلى من الفوائد المحتملة.
  • التاريخ: ما هو سجلك الحافل بإكمال التحديثات بنجاح دون أي تأثير على عملائك؟ يجب عليك اتباع ممارسات DevOps والاختبار والتوزيع والمراقبة الجيدة لتقليل احتمالية الانقطاعات، وللتأكد من تحديدك سريعاً لأي مشكلات تحدثها التحديثات. إذا علم عملاؤك أنك قادر على تحديث بيئاتهم بسلاسة، فمن غير المرجح أن يعترضوا.
  • العوده: هل سيرغب العملاء في التراجع عن التحديثات إذا كان هناك تغيير فاصل؟

متطلباتك

تحتاج أيضاً إلى التفكير في الأسئلة التالية من منظورك:

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

ملاحظة

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

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

لمزيد من المعلومات حول تحقيق عمليات توزيع بدون وقت تعطل، راجع التخلص من وقت التعطل من خلال تحديثات الخدمة التي تم إصدارها.

البحث عن توازن

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

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

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

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

تحذير

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

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

تواصل مع عملائك

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

يؤخذ بعين الاعتبار الأسئلة التالية:

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

تواصل مع فريق دعم العملاء الخاص بك

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

  • هل تم تطبيق التحديثات مؤخراً على البنية أساسية للمستأجر؟
  • ما هي طبيعة تلك التحديثات؟
  • ما هو الإصدار السابق؟
  • كم مرة يتم تطبيق التحديثات على هذا المستأجر؟

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

إستراتيجيات التوزيع لدعم التحديثات

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

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

نمط طوابع التوزيع

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

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

علامات الميزة

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

ضع في اعتبارك استخدام علامات الميزات إذا كان أي من هذه الحالات ينطبق عليك:

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

يمكنك تضمين دعم علامة الميزة في تطبيقك عن طريق كتابة التعليمة البرمجية بنفسك، أو باستخدام خدمة مثل Azure App Configuration.

حلقات الانتشار

تمكّنكحلقات التوزيع من طرح التحديثات تدريجياً عبر مجموعة من المستأجرين أو خوادم مخصصة التوزيع. يمكنك تعيين مجموعة فرعية من المستأجرين لكل حلقة.

يمكنك تحديد عدد الحلقات التي يجب إنشاؤها وما تعنيه كل حلقة للحل الخاص بك. عادة ما تستخدم المؤسسات الحلقات التالية:

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

إصدار واجهة برمجة التطبيقات

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

المساهمون

هذه المقالة تحتفظ بها Microsoft. تمت كتابتها في الأصل من قِبل المساهمين التاليين.

الكاتب الرئيسي:

مساهمون آخرون:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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