DC West CloudSigma وسجل عبء العمل السحابي السيادي

ملخص

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

قيمة ادعاء السيادة لا تظهر إلا بعد القبول

أصبح مصطلح "السحابة السيادية" سهل الشراء وصعب التحقق الآن. يمكن أن يعني مركز بيانات في بلد ما، أو شركة تشغيل محلية، أو عقدًا خاضعًا للقانون المحلي، أو فريق دعم يمكن التواصل معه باللغة المحلية، أو مستوى تحكم معزول، أو منطقة لدى مزود سحابي كبير مع التزامات بإقامة البيانات، أو حزمة خاصة تُشغَّل لعميل واحد، أو مجرد غلاف تسويقي حول أجهزة افتراضية. تنتمي DC West CloudSigma إلى هذا النقاش لأن واجهة CloudSigma مبنية حول تقديم السحابة داخل البلد، واستخدام مزودي الخدمات، والبنية التحتية المرنة، والفصل القانوني حسب موقع السحابة. لكن هذه الادعاءات لا تصبح مفيدة إلا عندما تصمد أمام العمل الروتيني لقبول عبء العمل.

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

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

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

إذا توقع العميل أن يحل الدعم مشاكل نظام التشغيل الضيف، فقد ينص العقد ونطاق الدعم على خلاف ذلك.

لذلك، يعتبر هذا التقييم DC West CloudSigma كواجهة تشغيلية بدلاً من ملف تعريف مزود عام. الأدلة العامة حول علامة DC West محدودة، بينما واجهة خدمة CloudSigma واسعة وموثقة جيدًا. وهذا يعني أن الموقف الصحيح هو الانضباط في الحدود: لا تخترع عميلًا محددًا لـ DC West، أو معيارًا، أو حادثة، أو بنية محلية؛ بدلاً من ذلك، اختبر سجل السحابة CloudSigma الذي يجب أن يتركه عبء العمل السيادي خلفه.

أدلة الموقع: المحلية سلسلة، وليست مجرد تسمية

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

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

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

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

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

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

حقيقة التزويد: البنية التحتية الحرة لا تزال بحاجة إلى إيصال

يعتمد وعد منتج CloudSigma بشكل كبير على التزويد الحر. تقول صفحة الخادم السحابي العامة لديها إنه يمكن شراء الموارد بشكل مستقل، دون فئات أجهزة جامدة، ويمكن للعملاء استخدام افتراضية KVM، وصور مخصصة، ووصول جذر، وأتمتة API و Terraform. تقدم مواد IaaS الأقدم نفس الحجة الأساسية بلغة أخرى: ينشئ العملاء مجموعة من CPU و RAM والتخزين وعرض النطاق الترددي التي يحتاجونها، بدلاً من الاختيار من حجم خادم قياسي. هذا جذاب تجاريًا لأنه يمكن أن يقلل من الهدر. وهو أيضًا متطلب تشغيليًا لأنه لا يوجد اسم جهاز واحد يشرح تلقائيًا النظام قيد التشغيل.

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

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

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

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

هنا تختلف الخدمة عن منصة مجردة بالكامل. تمنح CloudSigma المشتري تحكمًا دقيقًا؛ يجب على المشتري الرد بتحقق دقيق. السؤال المفيد ليس "هل أنشأت السحابة خادمًا؟" السؤال المفيد هو "هل تُظهر الحالة المقبولة الحوسبة المطلوبة، والذاكرة، وHypervisor، والأقراص، ونوع التخزين، وNICs، والموقع، والمالك، والأذونات، والاشتراك، والموارد القابلة للفوترة؟" عندما تتوافق هذه الحقول، يكون لادعاء السيادة جوهر تشغيلي. عندما لا تتوافق، يحمل العميل وعدًا بدلاً من نظام.

حالة التخزين: يمكن أن تفشل السيادة على طبقة الأقراص

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

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

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

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

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

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

حالة الشبكة: العامة والخاصة والمنبع أسئلة منفصلة

قبول الشبكة هو المكان الآخر الذي يمكن أن تصبح فيه لغة السيادة واسعة جدًا. قد يكون عبء العمل في البلد الصحيح لكنه لا يزال غير قابل للوصول، أو مكشوفًا بشكل مفرط، أو معتمدًا على مشغل منبع قيد الصيانة، أو متصلًا بالشبكة الخاصة الخاطئة. وثائق CloudSigma مفيدة لأنها تفصل هذه المخاوف. يمكن أن تكون واجهات شبكة الخادم خاصة من خلال VLANs أو عامة من خلال تكوينات IPv4 و IPv6. يمكن أن يكون العنونة العامة ديناميكية، أو ثابتة، أو يدوية، وتشرح الوثائق أن تغيير تكوين NIC يتطلب عناية لأن عناوين MAC تحدد NICs الموجودة وترتيب NICs يُقدم إلى VM.

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

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

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

يمكن أن يستمر عبء العمل في العمل بينما يكون مستوى التحكم مقيدًا مؤقتًا، أو يمكن أن يكون قابلاً للوصول بينما تكون قدرة العميل على تغييره معطلة.

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

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

تحكم العميل حقيقي، وعبء العميل حقيقي أيضًا

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

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

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

لذلك يجب أن يتضمن سجل عبء العمل المقبول من يملك الخادم، والأقراص، وVLANs، وIPs؛ وأي ACLs تمنح أي حقوق؛ وأي مستخدمين يمكنهم بدء، أو إيقاف، أو استنساخ، أو إرفاق الموارد؛ وأي مفاتيح عامة متصلة؛ وأي بيانات وصفية موجودة؛ وما إذا كانت سجلات التدقيق تُظهر تاريخ الفاعل المتوقع. تتعقب واجهة برمجة تطبيقات سجل التدقيق (audit-log API) الخاصة بـ CloudSigma التغييرات التي أُجريت على الموارد من قبل العميل أو أطراف أخرى مثل موظفي CloudSigma أو الأشخاص ذوي الأذونات. هذه ميزة مساءلة كبيرة، لكن فقط إذا تم استخدامها. المشتري الذي لا يفحص السجلات أبدًا لن يستفيد من وجودها.

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

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

استمرارية الدعم هي سير عمل، وليست مجرد وعد

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

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

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

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

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

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

اقتصاديات الوحدة: المرونة تتنافس مع الحجم

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

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

لذلك تدور اقتصاديات الوحدة حول الاستبدال. البديل ليس دائمًا AWS أو Azure أو Google Cloud. يمكن أن يكون مجموعة افتراضية داخلية، أو مزود موقع مشترك محلي، أو مزود خدمة مُدارة، أو سحابة خاصة قائمة على VMware، أو سحابة إقليمية بمجموعة منتجات أضيق، أو منطقة مزود سحابي كبير مع التزامات تعاقدية بإقامة البيانات. ينقل كل بديل التكلفة بين رأس المال، والعمليات، والترحيل، والدعم، والارتباط. يمكن أن تقلل تفصيلية موارد CloudSigma من الإفراط في التزويد لبعض أعباء العمل، بينما يمكن أن يزيد نظامها البيئي الأصغر من جهد التكامل للآخرين.

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

إعلان شراكة OCRE و GEANT مهم أيضًا كسياق. قالت CloudSigma علنًا إنه تم اختيارها كشريك سحابي رسمي لمشروع Open Clouds for Research Environments، الذي يهدف إلى تبني السحابة البحثية الأوروبية. هذا لا يصادق على كل عبء عمل سيادي، لكنه يُظهر أن CloudSigma سعت إلى أسواق حيث يهتم المشترون المؤسسيون باختيار السحابة، وأعباء العمل البحثية، والتسليم الأوروبي. إنها مصدر إشارة سوقية، وليس دليلاً شاملاً على الملاءمة.

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

أنماط الفشل محددة تشغيليًا

أنماط الفشل المعروفة لـ DC West CloudSigma ليست غريبة. إنها الإخفاقات العادية التي تصبح أكثر تكلفة عندما يتوقع المشتري أن تبسطها السيادة.

عدم تطابق التزويد هو الأول. يمكن إنشاء خادم مع CPU خاطئ، أو ذاكرة، أو Hypervisor، أو قرص، أو NIC، أو منطقة، أو مالك. تجعل API الخاصة بـ CloudSigma هذه الحقول مرئية، وهي ميزة، لكن الرؤية تساعد فقط إذا فحصها العميل. يقارن سجل القبول الجيد البناء المقصود بالبناء المُعاد قبل انتقال حركة المرور.

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

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

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

سوء تكوين IAM و ACL هو الخامس. يمكن لـ ACLs أن تجعل التعاون ممكنًا، لكنها يمكن أن تأذن أيضًا بتغييرات لم يقصدها مالك عبء العمل. العميل الذي يمنح حقوق البدء، أو الإيقاف، أو الاستنساخ، أو الإرفاق، أو التحرير يحتاج إلى سجل تدقيق ومراجعة دورية. وصول الجذر داخل VM لا يحمي عبء العمل من إذن سيء لمورد سحابي خارج VM.

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

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

مفاجأة الفوترة هي الثامنة. استهلاك الموارد الحر، والاشتراكات، وحركة المرور، وIPs، وVLANs، والتخزين، والتراخيص مفيدة عندما تُتتبع ومكلفة عندما تُهمل. تعرض CloudSigma رصيدًا، وتسعيرًا، واستخدامًا، وواجهات برمجة تطبيقات (APIs) للاستخدام الحالي. يجب على المشتري التوفيق بينها وبين قبول عبء العمل وسجلات التغيير المستمرة.

فشل التراجع عن الترحيل هو التاسع. لا يكتمل الانتقال إلى السحابة السيادية عندما يبدأ VM. يكتمل عندما يتم اختبار البيانات، والمسارات، والهوية، والنسخ الاحتياطي، والمراقبة، والتكلفة، والدعم، والتراجع بما يكفي لمخاطر العمل. تمنح منصة CloudSigma العملاء العديد من عناصر التحكم المباشرة؛ وهي لا تجعل التراجع تلقائيًا.

ما يجب أن يقبله العميل الجاد

القيمة العملية لـ DC West CloudSigma تكون أوضح إذا كتب العميل ما يعنيه القبول قبل الترحيل. يجب أن يبدأ السجل بالهوية: حساب CloudSigma، والموقع المختار، ونقطة النهاية، والشروط القانونية، وشروط معالجة البيانات حيثما انطبق، واتفاقية مستوى الخدمة، وجهات اتصال الدعم. ثم ينتقل إلى الحوسبة: أسماء الخوادم، وUUIDs، وHypervisor، وCPU، والذاكرة، والأقراص المتصلة، والمفاتيح العامة، والبيانات الوصفية، والحالة، والمالك. ثم التخزين: UUIDs الأقراص، والأحجام، وأنواع التخزين، وسياسة اللقطات والنسخ الاحتياطي، ومهام الاستنساخ، وتجميع التوفر، وأي نسخة بعيدة.

ثم الشبكة: IPs العامة، وVLANs الخاصة، وترتيب NIC، ووضع العنونة الثابت أو الديناميكي، وتوقع جدار الحماية، وصفحة حالة الموقع. ثم التحكم: المستخدمون، وACLs، وسجلات التدقيق، ورصيد الفوترة، والاشتراكات، وافتراضات التسعير، ومراجعة الاستخدام. ثم التشغيل: المراقبة، وقنوات الصيانة، والتصعيد، والتراجع، والملكية.

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

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

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

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

الحكم: مفيد حيث يوجد انضباط في الأدلة

يجب الحكم على سجل عبء العمل السحابي السيادي المقبول لـ DC West CloudSigma بالأدلة، وليس بالصفات. يوفر سجل CloudSigma العام لبنات بناء مفيدة: مواقع مسماة، ولغة فصل قانوني، وهوية شركة سويسرية، وشروط معالجة البيانات ومستوى الخدمة، وموارد API صريحة، وحالة الخادم والقرص، وقواعد واجهات الشبكة، وتجميع التوفر، وACLs، وسجلات التدقيق، ونقاط نهاية الفوترة والاستخدام، وصفحات حالة الموقع، وموقف تجاري موجه للشركاء. لبنات البناء هذه أقوى من كتيب سحابة إقليمية عام.

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

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