قياس استهلاك كل مستأجر

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

هناك شاغلان أساسيان يدفعان الحاجة إلى قياس استهلاك كل مستأجر:

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

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

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

لذلك، عند مواجهة هذه التحديات، من المهم النظر في كيفية قياس الاستهلاك.

إشعار

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

مقاييس الاستهلاك الإرشادية

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

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

إشعار

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

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

مقاييس المعاملات

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

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

مقاييس لكل طلب

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

إشعار

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

تحذير

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

تقدير الاستهلاك

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

قد تفكر في تقدير COGS للمستأجر، في الحالات التالية:

• لا تستخدم التسعير المستند إلى الاستهلاك.
• أنماط الاستخدام والتكلفة لكل مستأجر متشابهة، بغض النظر عن الحجم.
• يستهلك كل مستأجر نسبة مئوية منخفضة (على سبيل المثال، <2٪)، من الموارد الإجمالية في النشر.
• التكلفة لكل مستأجر منخفضة.

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

عند فرض التكاليف الخاصة بك

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

إشعار

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

يمكن استخدام Azure Cost Analysis لتحليل تكاليف موارد Azure لحلول المستأجر الفردي التي تستخدم العلامات أو مجموعات الموارد أو الاشتراكات لتكاليف السمات.

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

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

المساهمون

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

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

• دانيال سكوت راينسفورد | الاستراتيجي التكنولوجي الشريك

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

• جون داونز | مهندس البرامج الرئيسي
• تشاد كيتل | مهندس برامج رئيسي
• Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack for Azure

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

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

ضع في اعتبارك نموذج نشر التحديث الذي ستستخدمه.