مشاركة عبر

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

  • مقالة

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

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

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

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

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

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

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

متطلباتك

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

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

إشعار

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

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

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

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

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

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

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

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

تحذير

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

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

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

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

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

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

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

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

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

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

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

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

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

نمط الخوادم المخصصة للتوزيع

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

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

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

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

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

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

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

حلقات التوزيع

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

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

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

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

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

المساهمون

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

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

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

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

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

ضع في اعتبارك متى يمكنك تعيين الطلبات إلى المستأجرين، في حل متعدد المستأجرين.