ملخص
- يجب الحكم على InterCloud من خلال حالة اتصال السحابة المقبولة: النقطة التي يصف فيها نية العميل، والنقل الخاص، وسياسة التوجيه، وتسليم موفر السحابة، وضوابط الأمان، والمراقبة، وأدلة الدعم جميعها نفس الخدمة العاملة.
- يمنح استحواذ BSO سطح التشغيل القديم لـ InterCloud سياق شبكة وخدمة مكتب أكبر، ولكنه يجعل الانضباط الحدودي ضروريًا: يحتاج المشترون إلى معرفة أي وعد يأتي من تراث الاتصال السحابي لـ InterCloud، وأيها من شبكة BSO، وأيها لا يزال يعتمد على موفري السحابة، والناقلين، وفرق العملاء.
أصبحت الشركة مشكلة حدودية
من السهل إساءة فهم InterCloud إذا تم التعامل معها كشركة سحابية صغيرة بشكل مجرد. الرؤية الأكثر فائدة هي أضيق وأكثر تطلبًا. تقع في المسافة بين شبكات المؤسسات ومنصات السحابة العامة. كان وضعها العام القديم هو الاتصال السحابي المعرّف بالبرمجيات: طريقة مدارة لربط مواقع الشركات ومراكز البيانات والخدمات السحابية دون مطالبة كل فريق عميل بتجميع الدوائر والتوجيه وضوابط الأمان وإجراءات التشغيل من الصفر. سطحها العام الحالي مرتبط الآن بـ BSO، التي أعلنت في مارس 2025 أنها استحوذت على InterCloud بعد موافقة المحكمة التجارية في باريس كجزء من إجراءات إعادة التنظيم القضائي. المجال الخاص بـ InterCloud الآن يحل في الموقع العام لـ BSO. هذه ليست تفاصيل تجميلية.
إنها تغير كيفية قراءة الشركة.
المشتري لا يشتري ببساطة "السحابة". المشتري يشتري مسارًا مُدارًا إلى الخدمات السحابية. هذا المسار هو كائن مركب. يشمل الوصول المادي، وصول الشريك، التوصيلات المتقاطعة، الدوائر الافتراضية، سياسة التوجيه، قواعد الوصول، المراقبة، إجراءات مكتب الخدمة، ملكية الحوادث، والتوثيق. يمكن لمنصة هائلة الحجم أن تعرض منحدر دخول. يمكن للناقل بيع النقل. يمكن لمنصة مركز البيانات بيع التوصيل البيني. يمكن لفريق شبكة العميل تكوين BGP وسياسة الأمان. ادعاء InterCloud، الآن داخل محيط BSO، هو أنه يمكن تحويل هذه القطع إلى خدمة خاضعة للرقابة مع تجزئة تشغيلية أقل.
لهذا السبب فإن حالة اتصال السحابة المقبولة هي العدسة الصحيحة. تبدو العبارة إجرائية، لكن فيها يكمن الاقتصاد. لا يُقبل الاتصال لمجرد وجود منفذ. لا يُقبل لأن بوابة تقول إن الطلب اكتمل. لا يُقبل لأن مخطط المبيعات يظهر خطًا بين شبكة العميل وموفر السحابة. يُقبل عندما يمكن للعميل إثبات أن المسار هو المسار المقصود، وسياسة الوصول هي السياسة المقصودة، وجانب السحابة يعترف بالارتباط، وسطح المراقبة يكتشف أنماط الفشل الصحيحة، ومسار التصعيد واضح عندما يحدث انحراف.
هذا اختبار أكثر صرامة مما يمكن أن تحمله كتيبات المنتجات. إنه يفصل قدرة الشبكة عن طموح السحابة. كما يفصل قصة الأتمتة عن قصة الموثوقية. قد تقلل البوابة أو واجهة برمجة التطبيقات الوقت اللازم لطلب خدمة. قد تجعل التكرار المتكرر أسهل في التعبير. قد تقلل حركة تذاكر اليدوية. لكن الخدمة موثوقة فقط إذا وصل الإجراء الآلي مع أدلة كافية لمشغل بشري، ومالك أمان، ومالك عمل ليتمكنوا من الوثوق بالحالة الناتجة.
سياق BSO مهم لأن المواد العامة لـ BSO تصف شركة اتصال وبنية تحتية عالمية أوسع: اتصال سحابي خاص، وصلات سحابة إلى سحابة، خدمات مدارة، مكتب خدمة، مراقبة شبكة، وصول إلى مراكز البيانات، وبوابة للطلب ومعالجة التذاكر. تشير خريطة شبكتها إلى وجود بصمة عبر أكثر من 240 مركز بيانات في 33 دولة، وأكثر من 50 منحدر سحابي، وتكامل مع موفري السحابة الرئيسيين، ووصول إلى تبادل الإنترنت، واتصال بأسواق الأسهم. هذه ادعاءات من BSO وليست قياسات أداء مستقلة، لكنها تحدد حجم الإطار التشغيلي الحالي. يجب الآن فهم حل InterCloud القديم مقابل هذا الإطار.
الحدود القانونية والعلامة التجارية ليست حاشية. كان لدى InterCloud تاريخها العام ومنتجاتها وقوائم شركائها. تقدم BSO الآن الاستحواذ كخطوة استمرارية وتوسع. لا يجب على العميل قراءة كل ادعاء شبكة لـ BSO كادعاء منتج لـ InterCloud، ولا يجب قراءة كل عبارة منتج قديم لـ InterCloud كخدمة قائمة بذاتها حاليًا. القراءة الآمنة هي أن تراث الاتصال السحابي لـ InterCloud قد تم استيعابه في محفظة خدمات BSO الأكبر. السؤال التجاري هو ما إذا كان هذا المزيج يقلل التعقيد بما يكفي لتبرير رسوم الخدمات المدارة، وعمل الترحيل، والإشراف المستمر.
ما يتطلبه الاتصال المقبول فعليًا
يبدأ التسلسل التشغيلي الملموس قبل أن يصبح أي دائرة حية. يقرر العميل أن تطبيقًا، أو تدفق بيانات، أو مكتبًا، أو مركز بيانات، أو منطقة سحابية، أو مسار سحابة إلى سحابة يحتاج إلى اتصال خاص. قد يكون السبب زمن الوصول، الأمان، الامتثال، التوجيه المتوقع، انخفاض التعرض لتقلبات الإنترنت العامة، أو التحكم التشغيلي. ثم يجب على العميل ترجمة هذا السبب التجاري إلى طلب تقني: نقاط النهاية، عرض النطاق، التنوع، تفضيل المسار، متطلب الأمان، موفر السحابة، منطقة السحابة، ملكية الحساب، معلمات VLAN أو الدائرة الافتراضية، تفاصيل BGP، نافذة التغيير، توقع المراقبة، والمسار الاحتياطي.
في تنفيذ ضعيف، يصبح هذا الطلب سلسلة من التذاكر غير المتصلة. يفتح فريق المؤسسة طلب ناقل، ويطلب من مسؤول السحابة إنشاء مورد من جانب السحابة، ويطلب من فريق الأمان الموافقة على حركة المرور، ويطلب من فريق الشبكة تكوين التوجيه، وينتظر موفر مركز البيانات أو التوصيل المتقاطع. لكل مشارك حقيقة محلية. قد تعرض وحدة تحكم السحابة واجهة افتراضية. قد يظهر الناقل دائرة مكتملة. قد يكون لموجه المؤسسة جلسة. قد يكون لفريق الأمان قاعدة. قد يكون لفريق المراقبة جهاز. لا شيء من هذا بمفرده يثبت الحالة المقبولة.
في تنفيذ أقوى، يعمل الموفر كمنسق للحالة. يسجل المسار المقصود والتبعيات ونقاط الإثبات. يجب أن تتضمن الحالة المقبولة تفاصيل الوصول المادي أو الافتراضي، وتسليم موفر السحابة، والمجاورة التوجيهية، والمسارات المعلنة والمستقبلة، وضوابط السياسة، وضوابط الوصول، وفحوصات المراقبة، وتوجيه الإنذار، وجهة اتصال الدعم، وسجل التغييرات. إذا كان الاتصال يهدف إلى أن يكون مرنًا، يجب أن تظهر الحالة المقبولة التصميم المكرر بدلاً من مجرد تأكيد المرونة. إذا كان المسار يهدف إلى تحسين زمن الوصول، يجب أن تظهر الحالة المقبولة المسار الذي تم اختياره وما يبقى خارج سيطرة الموفر.
هنا تكون لغة Pathway و Autonomi القديمة لـ InterCloud ذات صلة. وصفت مواد الشريك العام InterCloud Pathway كنهج مدار للاتصال السحابي و Autonomi كمنصة وواجهة برمجة تطبيقات للخدمة الذاتية للاتصال بالشبكة من خلال موفري متكاملين. هذا التمييز مفيد لأنه يتوافق مع نموذجين تشغيليين. في النموذج المدار، يشتري العميل عبء تشغيلي أقل ويتوقع أن يتحمل الموفر المزيد من مسؤولية التصميم والنشر والدعم. في نموذج الخدمة الذاتية، يحتفظ العميل بمزيد من التحكم والمسؤولية، باستخدام منصة للتعبير عن تغييرات الاتصال السحابي وتكرارها.
لا يعتبر أي من النموذجين أفضل تلقائيًا. قد تقدر مؤسسة مالية مع فريق شبكات سحابية صغير التصميم المدار لأن تكلفة التوجيه الخاطئ لتدفق حرج أعلى من رسوم الخدمة. قد ترغب شركة منصة كبيرة مع مهندسي شبكات متطورين في واجهات برمجة التطبيقات، مشاريع قابلة للتكرار، وانضباط تشغيلي على غرار Terraform. قد تحتاج مؤسسة خاضعة للتنظيم إلى موفر للمساعدة في توثيق حدود السيادة والأمان. قد تحتاج شركة SaaS سريعة الحركة إلى توفير سريع ولكن لا تزال بحاجة إلى أدلة على أن التغيير لم يتجاوز عنصر تحكم. يجب أن تخدم الحالة المقبولة كل من هؤلاء المشترين دون التظاهر بأن لديهم نفس القدرة التشغيلية.
المخاطر التجارية الأولى هي أن المشترك يدفع مقابل التجريد ثم يكتشف أن العمل الصعب قد تم نقله فقط، وليس إزالته. يقلل الاتصال السحابي الخاص من بعض عدم اليقين، لكنه لا يلغي تصميم المسار، تصميم الوصول، الاستجابة للحوادث، أذونات جانب السحابة، أو تعيين تبعيات التطبيق. إذا كان فريق العميل لا يفهم تدفقات التطبيق التي تعتمد على الاتصال، فلا يمكن للموفر جعل التطبيق مرنًا بنفسه. إذا لم يتمكن العميل من الحفاظ على سجلات طوبولوجيا دقيقة، فقد يستعيد الموفر الدائرة ويظل التطبيق معطلاً. إذا غيّر مسؤول السحابة شبكة افتراضية، فقد يكون مسار الشبكة سليمًا بينما تفشل الخدمة.
لهذا السبب يجب قراءة النظام التقني كمستوى تحكم مشترك، وليس كأنبوب سحري. إنه يربط شبكة الموفر وأتمتته مع مخزون العميل، وحسابات السحابة، وقواعد الأمان، وعادات التشغيل. قد يقدم الموفر بوابة طلب، مراقبة، توجيه تذاكر المشاكل، وقدرة مكتب خدمة مدار. قد يقدم موفر السحابة Direct Connect، ExpressRoute، Partner Interconnect، FastConnect، أو بنيات وصول خاص مماثلة. قد يوفر الناقل أو منصة مركز البيانات المسار المادي. لا يزال العميل يمتلك النية. القبول هو محاذاة هذه المجالات.
حقيقة المسار هي المنتج
غالبًا ما يبيع موفرو الاتصال السحابي البساطة، لكن النظام الأساسي مبني من حقائق توجيه. أي بادئات يتم الإعلان عنها؟ أي مسارات مقبولة؟ أي مسار مفضل؟ أي مسار فشل يتولى المسؤولية؟ أي حركة مرور مستبعدة عمدًا؟ أي سياسة مسار تمنع التسرب؟ أي بنية من جانب السحابة تنهي الاتصال؟ أي جزء من شبكة العميل مسموح له باستخدامه؟ بدون هذه الإجابات، الخدمة مجرد رسم بياني.
سوق InterCloud حساس بشكل خاص لحقيقة المسار لأن لغة السحابة المتعددة يمكن أن تخفي تصاميم مختلفة جدًا. قد تستخدم الشركة سحابات منفصلة لتطبيقات منفصلة. قد تشغل عبء عمل واحد عبر أكثر من سحابة. قد تربط مركز بيانات خاص بسحابة عامة. قد تنقل البيانات بين موفري السحابة. قد تربط الفروع بالخدمات السحابية من خلال حافة معرّفة بالبرمجيات. هذه ليست نفس البنية. إنها تفرض ظروف توجيه وهوية وأمان وتكلفة وفشل مختلفة. الموفر الذي لا يستطيع تمييزها سيجلب وعودًا زائدة.
تؤكد مواد Cloud Connect العامة لـ BSO على مسارات خاصة مباشرة إلى موفري السحابة الرئيسيين، توجيه قابل للتخصيص، زمن وصول وعرض نطاق، وتوافر من خلال نقاط وجودها ومراكز بيانات الشركاء. تؤكد موادها من سحابة إلى سحابة على مسارات خاصة مباشرة بين موفري السحابة أو المناطق، مع القدرة على تحديد أولوية زمن الوصول أو التنوع أو القيمة. هذه الادعاءات ذات معنى تجاري فقط عند ترجمتها إلى تصميم على مستوى المسار. يجب على المشترك أن يسأل: أي مسار خاص، أي جزء يعتمد على الشريك، أي المسارات تسيطر عليها BSO، أيها يسيطر عليها موفر السحابة، وأين تبدأ سياسة شبكة العميل الخاصة.
تسربات المسار هي نمط الفشل الأكثر وضوحًا، لكن ليست الوحيد. خطأ مسار أقل دراماتيكية يمكن أن يكون بنفس الضرر. قد يُقبل مسار في البيئة الخاطئة. قد يأخذ مسار احتياطي حركة المرور عبر ولاية قضائية أراد العميل تجنبها. قد يمر مسار مخصص لزمن وصول منخفض عبر موقع يمكن تجنبه. قد يحجب مرشح مسار شبكة فرعية جديدة أثناء الترحيل. قد يشير جدول مسار من جانب السحابة بشكل صحيح بينما تسقط قاعدة جدار الحماية حركة المرور. قد يكون عرض العميل الملحوظ "السحابة بطيئة" أو "التطبيق معطل"، لكن السؤال التشغيلي هو ما إذا كانت حالة اتصال السحابة المقبولة لا تزال تطابق الحالة المقصودة.
يمكن لأتمتة الموفر المساعدة إذا سجلت النية وقارنتها بالواقع. يمكن أن تضر إذا تركت الإجراءات المتكررة تنحرف دون مراجعة. التوفير السريع مفيد عندما تكون المهمة متكررة ومحددة جيدًا: إضافة اتصال إلى موفر معروف، توسيع السعة، تعديل تفضيل المسار، إنشاء مسار سحابة إلى سحابة، أو توفير منطقة أخرى بموجب سياسة معروفة. إنه خطير عندما يتم التعامل مع كل إجراء جديد كروتيني على الرغم من تغير التطبيق أو تصنيف البيانات أو السياق التنظيمي أو تحمل الفشل.
لهذا السبب، لا ينبغي الخلط بين موثوقية المنتج وقدرة البرنامج. يمكن لواجهة معرّفة بالبرمجيات أن تعرض الطلب والمخزون والمراقبة. يمكن أن تجعل طلب التغيير أسهل في التكرار. يمكن أن تنتج مسار تدقيق أنظف من البريد الإلكتروني وجداول البيانات. لكن الاتصال السحابي الموثوق يتطلب إعدادات افتراضية محافظة، والتحقق من المسار، ومراجعة الوصول، وانضباط التراجع، ومراقبة ترى كلاً من الدائرة وتبعية الخدمة. يجب أن يرغب المشتري في الأتمتة، ولكن ليس أتمتة منفصلة عن هندسة الشبكات.
يمكن أن يجعل استحواذ BSO هذا أقوى إذا كانت وظائف الشبكة الأوسع ومكتب الخدمة لـ BSO توفر أدلة أكثر اكتمالاً حول الاتصال. يمكن أن يجعله أضعف إذا أصبحت حدود المنتج غير واضحة ولا يستطيع العملاء تحديد الفريق الذي يملك أي حالة. التكامل بعد الاستحواذ ليس مجرد تمرين على العلامة التجارية. إنه تمرين على حالة الدعم. يحتاج العميل إلى معرفة ما إذا كان الاتصال المنشأ من InterCloud مدعومًا من خلال مكتب خدمة BSO، وكيف يتم تعيين الشدة، وأين تعيش سجلات التصميم التاريخية، وأي بوابة تحتوي على مصدر الحقيقة، وكيف يتم الموافقة على التغيير.
سياسة الوصول هي نقطة الفشل الصامتة
الاختبار الثاني هو الوصول. غالبًا ما يتم بيع الاتصال الخاص كتحسين أمني لأنه يتجنب مسارات الإنترنت العامة العادية. هذا صحيح جزئيًا، لكنه غير كامل. يمكن للمسار الخاص أن يحمل حركة مرور خاطئة، أو يعرض البيئة الخاطئة، أو يتجاوز الضوابط التي يعتقد العميل أنها إلزامية. الاتصال نفسه ليس السياسة. إنه النقل الذي يجب فرض السياسة من خلاله.
عمليًا، مشكلة الوصول لها عدة طبقات. لدى العميل قواعد هوية وتفويض لحسابات السحابة وتغييرات الشبكة. لدى الموفر حسابات بوابة، وأذونات مكتب خدمة، وإجراءات تغيير. لدى موفر السحابة أذونات موارد خاصة به. لدى الشبكة مرشحات مسار، وفصل VLAN، وقواعد جدار حماية، وربما متطلبات تشفير. لدى فريق الأمان رؤية لتصنيف البيانات، والتسجيل، والاستجابة للحوادث. يخلق موفر الاتصال السحابي قيمة إذا ساعد في بقاء هذه الطبقات متماسكة.
لهذا السبب فإن أتمتة الأمان ضرورية وخطيرة في نفس الوقت. لا ينبغي أن تتطلب مهام الاتصال المتكررة جهدًا يدويًا بطوليًا. لا ينبغي للعميل الذي يفتح عشر دوائر سحابية مماثلة أن يعيد بناء عملية الموافقة من لا شيء في كل مرة. تقلل القوالب القياسية والبنى المعروفة والضوابط المتفق عليها مسبقًا من الاحتكاك. لكن يجب أن تحافظ الأتمتة على قرار الأمان، وليس فقط تسريع خطوة الشبكة. إذا كان اتصال جديد يحمل بيانات منظمة، أو يعبر حدودًا قضائية، أو يمنح عبء عمل سحابي وصولاً إلى نظام حساس في الموقع، فقد يكون القالب العام فضفاضًا جدًا.
الموقف القديم لـ InterCloud حول السيادة والأداء مهم هنا. أكدت الأوصاف العامة على منح الشركات التحكم في أمان وسيادة وأداء حركة البيانات الحرجة. هذا هو الوعد الصحيح لهذا السوق، لكن الإثبات محدد. أين تذهب حركة المرور؟ أي موفر يلمسها؟ أي منطقة سحابية تنهيها؟ أي موقع مركز بيانات معني؟ أي مسار يستخدم أثناء تجاوز الفشل؟ أي سجلات تظهر المسار؟ أي ضوابط تمنع بيئة غير مصرح بها من استخدام الاتصال؟ ادعاء السيادة بدون أدلة على المسار والسياسة هو تسويق.
أصبحت سيادة البيانات والمحلية أكثر تعقيدًا لأن بنية السحابة لم تعد مجرد خيار بين الموقع المحلي والسحابة العامة. قد يستخدم عبء العمل منطقة سحابة عامة، ومنطقة سحابة سيادية، وسحابة خاصة، وخدمة SaaS، ومسار شبكة مدار في نفس الوقت. على سبيل المثال، تسرد مواد شريك Oracle FastConnect العامة Intercloud بين الشركاء عبر عدة مواقع أوروبية وأمريكية، بما في ذلك مواقع أوروبية مرتبطة بالسيادة. هذا النوع من القوائم دليل على الوصول المحتمل، وليس دليلاً على أن بيانات أي عميل معين تبقى في ولاية قضائية مرغوبة. لا يزال العميل بحاجة إلى سجل تصميم.
يمكن أن يكون عدم تطابق سياسة الوصول أكثر تكلفة من انقطاع مرئي. الانقطاع يطلق الإنذارات. عدم التطابق قد يستمر. قد تعمل حركة المرور من خلال مسار غير مقصود. قد يمنح فريق وصولًا أوسع أثناء الترحيل وينسى تضييقه. قد يضيف مسؤول سحابة شبكة فرعية دون إبلاغ فريق الشبكة. قد يتم إعادة استخدام كائن جدار حماية للراحة. لذلك يجب أن تتضمن الحالة المقبولة رؤية أمنية: ليس فقط أن حركة المرور يمكن أن تمر، ولكن فقط حركة المرور المقصودة يمكن أن تمر.
تأثير العمل حقيقي. يغير الاتصال السحابي الخاص الجيد ما تفعله فرق الشبكة والأمان. يقضون وقتًا أقل في التفاوض على كل توصيل متقاطع من المبادئ الأولى ووقتًا أطول في الحفاظ على النية، ومراجعة الاستثناءات، والتعامل مع التصعيد، والتحقق من أن الأتمتة لم تطبيع نمطًا خطيرًا. قد يقلل ذلك من بعض الأعمال الشاقة، لكنه لا يزيل الحاجة إلى الإشراف الماهر. في العديد من المؤسسات، ينقل العمل النادر نحو البنية والأدلة.
المراقبة تقرر ما إذا كانت الخدمة قابلة للإدارة
الاختبار الثالث هو المراقبة. يصبح الاتصال الخاص مفيدًا تشغيليًا عندما يتمكن الموفر والعميل من رؤية الحالة الصحيحة في الوقت المناسب. قد تكون الدائرة نشطة بينما التطبيق غير قابل للاستخدام. قد يكون المسار موجودًا بينما زمن الوصول تجاوز الحد المسموح. قد يكون مورد جانب السحابة سليمًا بينما جدار حماية العميل يسقط المسار. قد يرى الموفر شبكته الأساسية بينما يرى العميل فقط معاملات فاشلة. يجب على المراقبة سد هذه الآراء الجزئية.
تعطي المواد العامة لـ BSO عدة أدلة حول وضع المراقبة الخاص بها. تصف صفحة بوابتها مراقبة الشبكة والتحليلات جنبًا إلى جنب مع الطلب الآلي وإدارة التذاكر والفواتير. تصف مواد خدمتها المدارة مراقبة البنية التحتية، والاستجابة للحوادث، ومكتب الخدمة، والمراقبة الاستباقية. وصفت مواد عامة أقدم شراكة مع Accedian لمراقبة أداء الشبكة متعدد الناقلين، بما في ذلك الرؤية في السعة والاستخدام وزمن الوصول وفقدان الحزم والمؤشرات ذات الصلة. لا شيء من هذا يثبت سلوك اتصال عميل InterCloud محدد اليوم، لكنه يظهر أن المراقبة جزء من السرد التشغيلي العام وليست فكرة لاحقة.
يجب أن تتضمن حالة اتصال السحابة المقبولة ما يتم مراقبته وما لا يتم. هل يراقب الموفر المنفذ، الدائرة الافتراضية، جلسة BGP، جدول المسار، فقدان الحزم، زمن الوصول، التذبذب، الاستخدام، توفر جانب السحابة، معدات موقع العميل، أم فقط مجموعة فرعية؟ هل التنبيهات مرتبطة بتذاكر العملاء؟ هل لدى العميل رؤية من خلال بوابة؟ هل هناك فرق بين تحذير وانقطاع رئيسي؟ هل يكتشف الموفر مسارًا متدهورًا قبل أن يلاحظ العميل عرضًا من أعراض التطبيق؟ هذه الأسئلة تهم أكثر من بيان توفر عام.
نقاط العمى في المراقبة شائعة بشكل خاص عند نقاط التسليم. قد يرى الناقل مقطع نقل نظيف. قد يرى موفر السحابة منحدرًا متاحًا. قد يرى الموفر المدار شبكته الأساسية. قد يرى العميل مهلة تطبيق. في نظام متعدد الأطراف، يمكن أن يكون كل طرف صحيحًا تقنيًا وغير مكتمل تشغيليًا. قيمة موفر الاتصال السحابي المدار هي جزئيًا القدرة على تقليل تلك الفجوة التشخيصية.
يجب أن يكون المشتري متشككًا في أي موفر يختزل المراقبة في جمالية لوحة القيادة. لوحة القيادة ليست نموذج تشغيل. السؤال الصعب هو ماذا يحدث عندما تختلف لوحة القيادة وتجربة المستخدم. من يتخذ الإجراء الأول؟ من يمكنه رؤية أدلة كافية لتجنب توجيه الاتهامات؟ من يتصل بموفر السحابة أو الناقل؟ من لديه سلطة إعادة التوجيه أو التراجع أو التصعيد؟ من يقرر أن الرابط المتدهور هو حادث عمل وليس مقياسًا خلفيًا؟
استرداد الحوادث هي اللحظة التي يتم فيها اختبار الحالة المقبولة تحت الضغط. يمكن أن يتسرب مسار، أو يفشل منحدر سحابي، أو يتدهور مقطع ناقل، أو تحجب قاعدة أمان بادئة جديدة، أو ينتج تغيير مخطط له مسار زمن وصول غير متوقع. لا يحتاج العميل فقط إلى إصلاح. يحتاج إلى معرفة ما إذا كان الموفر يمكنه إعادة بناء ما تغير، وما فشل، وما هو الحل البديل الذي تم تطبيقه، وما الحالة التي يجب اعتبارها مقبولة الآن. بدون هذا السجل، يمكن أن يتكرر نفس الحادث.
توجه مواد الاتصال العامة لـ BSO عملاء البوابة إلى فتح تذكرة مكتب خدمة بأولوية عالية أو عالية جدًا لحالات الطوارئ أو الانقطاعات الكبيرة. هذه إشارة مفيدة因为她 تكشف قناة التصعيد المتوقعة. لكن قناة التذكرة هي فقط الباب الأمامي. الجودة التشغيلية تعتمد على التصنيف والملكية وجمع الأدلة وإيقاع الاتصال وسلطة الاستعادة. يجب الحكم على موفر اتصال سحابي رئيسي ليس بقدرته على استقبال تذكرة، ولكن بقدرته على نقل حادث عبر المجالات نحو حالة موثقة.
ظروف النشر تحدد ما إذا كان الوعد قائماً
الاتصال السحابي ليس سهلاً بنفس القدر في كل مكان. ظروف النشر مهمة. عميل موجود بالفعل في نقطة وجود BSO، أو مركز بيانات شريك، أو موقع مع وصول مباشر للتوصيل المتقاطع هو في وضع مختلف عن عميل موقعه خارج الشبكة ويعتمد على ناقل محلي. عميل يتصل بمنطقة سحابية مدعومة جيدًا هو في وضع مختلف عن واحد يستهدف منطقة مع خيارات شريك أقل. عميل مع عناوين IP نظيفة وطوبولوجيا موثقة وحسابات سحابية منضبطة أسهل في الخدمة من واحد مع شبكات مجزأة واستثناءات غير مدارة.
تقول مواد Cloud Connect لـ BSO إن الوصول يمكن توفيره حيث تصل شبكتها أو من خلال مراكز بيانات الشركاء، وأن العملاء خارج الشبكة يحتاجون إلى مسارات مصممة إلى السحابة. هذه الجملة تحمل الكثير من الحقيقة التجارية. "متاح" ليس مثل "بسيط". إذا كان العميل خارج الشبكة، قد يحتاج الموفر إلى وصول محلي من طرف ثالث. إذا كان التنوع مطلوبًا، قد يحتاج التصميم إلى مسارات منفصلة ماديًا ومنطقيًا. إذا لم يكن منحدر موفر السحابة في السوق المفضل للعميل، قد يتضمن المسار حل وسط إقليمي. إذا كان زمن الوصول هو سبب شراء الخدمة، يجب على العميل الاهتمام بالمسار الفعلي بدلاً من اسم الموفر الاسمي.
ينطبق الشيء نفسه على الاتصال من سحابة إلى سحابة. نقل البيانات بين موفري السحابة من خلال مسارات خاصة يمكن أن يتجنب بعض عدم اليقين في الإنترنت العامة وقد يقلل بعض تكاليف حركة المرور، لكنه يخلق طبقة تبعية جديدة. يجب على العميل فهم سياسات الخروج من السحابة، ورسوم منافذ الموفر، ورسوم الاتصال المدار، والتزامات عرض النطاق، وتصميم المسار، والدعم التشغيلي. إذا لم يتم بناء التطبيق لتحمل زمن الوصول عبر السحابات أو دلالات الفشل، فإن المسار الخاص الأفضل لن يجعل البنية بسيطة.
لذلك يجب تحليل اقتصاديات الوحدة كحزمة. التكلفة الواضحة هي رسوم خدمة الاتصال المدار. التكاليف الأقل وضوحًا تشمل تخطيط الترحيل، ونوافذ التغيير، ورسوم موفر السحابة، ورسوم نقل البيانات، والتزامات الأجهزة أو المنافذ، ومراجعة الأمان، وتكامل المراقبة، وتدريب الموظفين، والإشراف المستمر. جانب الفائدة يشمل تقليل تعقيد الشبكة، وأداء أكثر توقعًا، وتوجيه خاص، وتوفير أسرع متكرر، ومشاريع ناقل أقل لمرة واحدة، وسطح حوادث أفضل. تكون الصفقة جذابة فقط عندما يكون التعقيد الذي تم تجنبه حقيقيًا.
هذا معيار مرتفع لمشتري السوق المتوسطة. شركة صغيرة تستخدم سحابة واحدة وتطبيقات موجهة للإنترنت في الغالب قد لا تحتاج إلى موفر اتصال سحابي خاص مدار. شركة مع مناطق متعددة، بيانات منظمة، عمليات حساسة لزمن الوصول، تطبيقات خاصة، شبكات فروع، أو عمل تغيير سحابي متكرر قد يكون لديها حالة أقوى. السؤال التجاري ليس ما إذا كان الاتصال السحابي الخاص جيدًا. إنه ما إذا كان عبء العمل للعميل ونموذجه التشغيلي معقدين بما يكفي لتكون الخدمة أرخص من التجزئة المستمرة.
عملاء InterCloud القدامى، إذا تم ترحيلهم أو دعمهم داخل BSO، يواجهون سؤال نشر خاص. يحتاجون إلى الاستمرارية، لكنهم يحتاجون أيضًا إلى الوضوح. أي أسماء المنتجات لا تزال سارية؟ أي مستويات خدمة تنطبق؟ أي بوابة يجب استخدامها؟ أي أرقام دعم أو فئات تذاكر تهم؟ أي قدرات BSO متاحة لهم الآن، وأيها تتطلب تغييرًا تجاريًا؟ أكد إعلان الاستحواذ على استمرارية الخدمة لعملاء InterCloud. النسخة التشغيلية من هذا الوعد هي التوثيق، وليس المشاعر.
طبقة التبعية الأولية أكبر من العلامة التجارية
لا يتحكم أي موفر اتصال سحابي بشكل كامل في الخدمة التي يبيعها. يتحكم في أجزاء من المسار، ويتعاقد على البعض الآخر، وينسق عبر الباقي. يعتمد InterCloud و BSO على موفري السحابة للمنحدرات والبنيات من جانب السحابة. يعتمدان على مراكز البيانات للاتصال المادي. يعتمدان على الناقلين للوصول خارج الشبكة وبعض المسارات الطويلة. يعتمدان على معدات التوجيه، أنظمة المراقبة، أدوات الدعم، أنظمة الهوية، وسجلات العملاء. يعتمد العميل على كل هذا، سواء أظهرت الفاتورة موفرًا واحدًا أو عدة.
طبقة التبعية هذه ليست ضعفًا بحد ذاتها. إنها طبيعة السوق. جميع AWS Direct Connect، Azure ExpressRoute، Google Partner Interconnect، و Oracle FastConnect تشكل نفس الفكرة الأساسية: اتصال خاص أو بوساطة شريك بين بيئات العميل وموارد السحابة. يوفر موفر السحابة الخدمة من جانب السحابة. يوسع الشركاء والناقلون الوصول. تقوم منصات الشبكة والموفري المدار بتجميع النتيجة. يختار المشترون مقدار هذا التكامل الذي يريدون القيام به بأنفسهم.
الخطر هو أن التجميع يحجب ملكية الفشل. قد تكون مشكلة المسار داخل موجه العميل. قد تكون مشكلة مادية في توصيل متقاطع. قد تكون مشكلة دائرة افتراضية مع موفر سحابة. قد تأتي مفاجأة زمن الوصول من اختيار مسار خارج السيطرة المباشرة للموفر المدار. قد يكون عدم تطابق جدار الحماية مملوكًا لفريق أمان العميل. قد يكون خطأ البوابة مملوكًا لموفر الخدمة. عندما يُباع كل شيء كاتصال سحابي واحد، يجب أن تحافظ عملية الحادث على هذه التمييزات.
لهذا السبب فإن انضباط الأدلة لدى الموفر مهم. يجب أن يكون الموفر الناضج قادرًا على القول: هذا الجزء لنا، هذا الجزء يتحكم فيه الشريك، هذا الجزء يتحكم فيه العميل، وهذا هو الدليل الحالي. لا ينبغي أن يتطلب من العميل أن يصبح منسقًا جنائيًا أثناء انقطاع الخدمة. ولا ينبغي أن يعني أن موفرًا واحدًا يمكنه ضمان كل طبقة من مسار متعدد الأطراف.
قد تقلل شبكة BSO الأكبر بعض مخاطر التبعية من خلال جلب المزيد من الوصول والقدرة التشغيلية إلى نفس المؤسسة. قد تخلق أيضًا مخاطر تركيز إذا نقل العميل عددًا كبيرًا من قرارات الاتصال إلى مورد واحد دون الاحتفاظ بمعرفة المسار. أفضل وضع للمشتري ليس الثقة العمياء أو الشك الدائم في العمل الذاتي. إنه إدارة التبعية المنظمة: اعرف ما تم الاستعانة بمصادر خارجية له، واعرف ما بقي مملوكًا، واطلب الأدلة عند كل نقطة قبول.
المنافسون والبدائل يحددون السقف التجاري
لا يتنافس InterCloud فقط مع الشركات التي تستخدم نفس المفردات. مجموعة البدائل واسعة. يمكن لمؤسسة كبيرة الشراء مباشرة من موفري السحابة والناقلين، باستخدام مهندسين داخليين لتجميع الخدمة. يمكنها استخدام Equinix Fabric أو منصة توصيل بيني لمركز البيانات. يمكنها استخدام Megaport أو Console Connect للتوفير على غرار الشبكة كخدمة. يمكنها استخدام موفر اتصال عالمي، أو بائع SD-WAN، أو موفر خدمات مدارة، أو متكامل أنظمة سحابية. يمكنها أيضًا أن تقرر أن الإنترنت العامة بالإضافة إلى التشفير ومرونة طبقة التطبيق كافية.
تلك المجموعة البديلة تحد من قوة التسعير وتشكل المنتج. يجب أن يكون InterCloud و BSO أفضل من التجميع الداخلي للعملاء الذين يفتقرون إلى الوقت أو الوصول الجغرافي أو المهارات المتخصصة. يجب أن يكونا أكثر إرشادًا من منصات الخدمة الذاتية البحتة للعملاء الذين يريدون مساءلة مدارة. يجب أن يكونا أكثر مرونة من مشاريع الناقل التقليدية للعملاء الذين لديهم أنماط تغيير سحابي متكررة. يجب أن يكونا أكثر واقعية من الاستشارات السحابية العامة للعملاء الذين يحتاجون إلى اتصال تشغيلي، وليس نصيحة.
أقوى حالة تجارية هي عميل بمهام متكررة. يمكن التعامل مع اتصال خاص لمرة واحدة بواسطة العديد من المزودين. ترتفع القيمة عندما يضيف العميل بشكل متكرر مناطق سحابية، ويضبط السعة، ويوصل مواقع جديدة، ويغير سياسة المسار، ويجري ترحيلات، ويدير تجاوز فشل الحوادث، أو يحتاج إلى أدلة متسقة عبر وحدات الأعمال. في هذا العالم، يمكن لمنصة وخدمة مدارة تحويل سلسلة من المشاريع المخصصة إلى نمط تشغيل خاضع للرقابة.
أضعف حالة هي عميل يريد من الموفر تعويض الملكية غير الواضحة من جانب العميل. إذا كانت فرق التطبيقات والسحابة والشبكة والأمان لا تستطيع الاتفاق على النية، لا يزال بإمكان موفر خارجي توفير الدوائر لكن لا يمكنه تحديد الصحة التجارية. قد يصبح الطرف المرئي الذي يتم إلقاء اللوم عليه بسبب فشل ناتج عن غموض تنظيمي. هذا يرفع تكلفة الإشراف ويضعف اقتصاديات الوحدة.
هنا يجب أن تؤخذ تأثيرات المؤسسة والعمل على محمل الجد. يمكن لنشر اتصال سحابي خاص مدار ناجح أن يقلص أعمال التنسيق منخفضة القيمة. يمكن أن يقلل عدد التفاعلات اليدوية مع الناقل. يمكن أن يوحد السجلات. يمكن أن يعطي فرق السحابة مسارًا أسرع إلى الاتصال المعتمد. يمكن أن يعطي فرق الأمان سطح مراجعة أوضح. لكنه يطالب أيضًا بمالك مسمى لنية الاتصال. شخص ما في مؤسسة العميل يجب أن يقرر ما تعنيه "مقبول".
إذا لم يمتلك أحد تلك الحالة، يصبح كل وعد للموفر عرضة للخطر. قد يحسن فريق الشبكة من أجل قابلية الوصول. قد يحسن فريق الأمان من أجل التقييد. قد يحسن فريق السحابة من أجل السرعة. قد يحسن الماليون من أجل الرسوم المتكررة المنخفضة. قد يحسن مالك التطبيق من أجل تجربة المستخدم. يجب على الموفر تلبية متطلبات مختلطة. كلما كانت حوكمة المشتري أفضل، كلما أصبحت أتمتة الموفر أكثر قيمة.
أدلة العملاء موجودة ولكنها غير كاملة
أدلة السوق العامة حول InterCloud و BSO مفيدة، لكن لها حدود. ينشر BSO مراجع للعملاء ومواد دراسة حالة في مجالات الشبكة المدارة والبنية التحتية السحابية والاتصال المجاورة. يعرض موقعه أسماء العملاء واقتباسات عبر صفحات الدعم والتكنولوجيا والسحابة إلى السحابة. تدرج Equinix InterCloud كشريك بائع وتصف منتجات الاتصال السحابي المدارة والخدمة الذاتية لـ InterCloud. تدرج Oracle Intercloud بين شركاء FastConnect حسب المنطقة. تحتفظ LinkedIn وقواعد بيانات السوق بالوصف التاريخي لـ InterCloud كموفر اتصال سحابي معرف بالبرمجيات. تسجل مصادر معلومات الشركات الفرنسية هوية الشركة InterCloud وتاريخ الإيداعات القانونية.
أبلغت وسائل الإعلام التكنولوجية الفرنسية عن استحواذ BSO وسياق إعادة التنظيم القضائي.
هذا كافٍ لتحديد الفئة والحدود التشغيلية. إنه ليس كافياً لتحديد أداء عميل معين. لا توجد حزمة أدلة عامة تظهر متوسط وقت الإصلاح الحالي لـ InterCloud، أو استقرار مسار العميل الفعلي، أو تاريخ الانقطاع، أو التغيير، أو الإيرادات، أو التسعير، أو تحقيق مستوى الخدمة، أو جودة التكامل بعد الاستحواذ. هذه الحقائق قد توجد بشكل خاص، لكن لا ينبغي استنتاجها من المواد العامة.
هذا مهم لأن أسواق الاتصال السحابي مليئة بالادعاءات التي تبدو معقولة من حيث الاتجاه ولكنها غير محددة تشغيليًا. "آمن" يمكن أن يعني نقل خاص، تشفير، ضوابط سياسة، مراقبة، أو كل ما سبق. "زمن وصول منخفض" يمكن أن يعني خيار مسار، نتيجة مقاسة، أو تحسن نسبي مقارنة بمسارات الإنترنت العامة. "عالمي" يمكن أن يعني شبكة مملوكة، وصول شريك، تغطية منحدر سحابي، أو توفر تجاري. "مدار" يمكن أن يعني مساعدة في التصميم، دعم على مدار الساعة، مراقبة نشطة، أو مجرد مسار تذكرة. المشتري الجاد يطلب تعريفات.
قدم إعلان استحواذ BSO InterCloud كلاعب رئيسي في خدمات الاتصال المباشر لبيئات السحابة العامة والخاصة وقال إن الصفقة ستضمن خدمة متواصلة لعملاء InterCloud مع دمج التقنيات في BSO. هذا البيان مهم تجاريًا، لكنه لا يزال سرد استحواذ عام. سؤال المتابعة للمشتري يجب أن يكون تشغيليًا: أظهروا كتالوج الخدمة الحالي، نموذج الدعم، سلوك البوابة، تدفق التصعيد، ومعايير القبول التقنية.
أقوى دليل غالبًا ما يكون عاديًا. هل يمكن للموفر إظهار سجل قبول مثال مع إزالة التفاصيل الحساسة؟ هل يمكنه إظهار كيف يتم طلب تغيير مسار، الموافقة عليه، تنفيذه، اختباره، وتراجعه؟ هل يمكنه إظهار كيف ترتبط المراقبة بشدة التذكرة؟ هل يمكنه إظهار ماذا يحدث عندما يواجه موفر السحابة مشكلة في منحدر الدخول؟ هل يمكنه إظهار كيف يتم الحفاظ على مخزون العميل محدثًا؟ هذه ليست أسئلة براقة. إنها الأسئلة التي تفصل خدمة الاتصال المدارة عن أنبوب باهظ الثمن.
أنماط الفشل متوقعة
أنماط الفشل المعروفة ليست غريبة. الأول هو تسرب مسار أو خطأ في سياسة المسار. هذا هو فشل الشبكة الكلاسيكي لأنه يمكن أن يعرض حركة المرور للمسار الخاطئ أو يزعزع قابلية الوصول. تشمل الضوابط الجيدة تصفية البادئات، مراجعة التغيير، النشر المرحلي، مراقبة المسار، وإجراءات التراجع.
الثاني هو عدم تطابق سياسة الوصول. يعمل الاتصال، لكن المصدر أو الوجهة أو الشبكة الفرعية الخاطئة مسموح بها. أو أن التدفق المقصود محظور لأنه لم يتم تحديث عنصر تحكم أمني. تشمل الضوابط الجيدة سجلات التغيير التي تربط عمل الاتصال بالموافقة الأمنية، بالإضافة إلى التحقق بعد التغيير من جانبي الشبكة والتطبيق.
الثالث هو مفاجأة زمن الوصول. توقع المشتري مسارًا أسرع أو أكثر توقعًا، لكن المسار المنفذ أو مسار تجاوز الفشل أو تبعية جانب السحابة تتصرف بشكل مختلف. تشمل الضوابط الجيدة توثيق المسار، قياس الأساس، لغة أداء واقعية، ووضوح حول الأجزاء الخارجة عن السيطرة المباشرة للموفر.
الرابع هو انقطاع أو تدهور منحدر السحابة. قد لا يزال المسار الخاص يعتمد على موقع موفر سحابة أو تسليم شريك. تشمل الضوابط الجيدة التصميم المكرر، الوعي بمنطقة السحابة، جهات اتصال التصعيد، وخيارات تجاوز الفشل الموثقة.
الخامس هو نقطة عمى في المراقبة. يرى الموفر دائرته سليمة بينما يعاني العميل من فشل التطبيق. تشمل الضوابط الجيدة مقاييس مشتركة، فحوصات اصطناعية حيثما كان ذلك مناسبًا، رؤية المسار والجلسة، وإجراءات الحوادث التي لا تتوقف عند حافة الموفر.
السادس هو فشل تسليم الناقل. يمكن للوصول خارج الشبكة ومسارات الشريك إدخال تأخيرات وغموض. تشمل الضوابط الجيدة تبعيات مسماة، سجلات تنوع مادي، إجراءات تصعيد الناقل، وملكية واضحة لمشكلة الميل الأخير.
السابع هو ارتباك حدود المنتج بعد الاستحواذ. قد لا يعرف العميل ما إذا كان يستخدم خدمة InterCloud القديمة، أو خدمة ذات علامة BSO، أو نموذج دعم هجين. تشمل الضوابط الجيدة تعيين الخدمة، وضوح العقد، إشعارات ترحيل الدعم، وتوثيق تشغيلي حالي.
الثامن هو تأخير تصعيد الحادث. قد لا يتلقى الفريق المناسب الأدلة الصحيحة بالسرعة الكافية. تشمل الضوابط الجيدة تعريفات الشدة، انضباط البوابة، مسارات الاتصال، وإجراءات الطوارئ المتفق عليها مسبقًا.
لا يبطل أي من هذه الإخفاقات عرض InterCloud أو BSO. إنها تحدد العمل. تنجح شركة في هذه الفئة عندما تجعل هذه الإخفاقات أقل احتمالاً وأكثر وضوحًا وأسرع في الحل. تفشل عندما تعاملها كحالات حافة.
اختبار المشتري العملي
يجب على المشتري العملي تقييم InterCloud من خلال BSO باستخدام قائمة مراجعة قبول قصيرة ومتطلبة. أولاً، حدد حدود الخدمة. أي كيان قانوني يتعاقد على الخدمة؟ أي منتج يُباع؟ أي أجزاء تأتي من تراث InterCloud وأيها من شبكة BSO أو خدماتها المدارة؟ ثانيًا، حدد المسار. أي مواقع ومراكز بيانات ومناطق سحابية ومنحدرات دخول متضمنة؟ أي أجزاء داخل الشبكة أو تعتمد على الشريك أو يتحكم فيها العميل؟ ثالثًا، حدد السياسة. أي مسارات وبادئات وقواعد وصول وضوابط أمان تحدد الخدمة؟
رابعًا، حدد سطح التشغيل. أي بوابة تستخدم للطلبات والمراقبة والتذاكر؟ أي الأحداث تولد تنبيهات؟ أي مستويات شدة تنطبق؟ أي فريق دعم يملك الاستجابة الأولى؟ خامسًا، حدد الأدلة. ما الدليل الذي يتم إنشاؤه عندما يتم قبول الاتصال؟ ما الدليل الذي يتم إنشاؤه بعد التغيير؟ ما الدليل المتاح أثناء الحادث؟ سادسًا، حدد الاقتصاد. ما هي رسوم الخدمة المتكررة، ورسوم موفر السحابة، وافتراضات نقل البيانات، وتكاليف الترحيل، وتكاليف الإشراف على الموظفين؟ سابعًا، حدد خطة الخروج. إذا كانت الخدمة مخيبة للآمال، ما مدى قابلية نقل التصميم إلى موفر آخر أو إلى اتصال سحابي مباشر؟
قد تبدو قائمة المراجعة هذه ثقيلة، لكنها أرخص من اكتشاف الغموض أثناء الانقطاع. كما أنها تحترم الفئة. الاتصال السحابي المدار قيم على وجه التحديد لأن النظام الأساسي صعب. معاملته كبسيط يهزم سبب شرائه.
بالنسبة لـ InterCloud، الفرصة لا تزال حقيقية. المؤسسات لا تصبح أقل توزيعًا. مناطق السحابة، عروض السحابة السيادية، التطبيقات الخاصة، تبعيات SaaS، وأعباء العمل كثيفة البيانات تستمر في التكاثر. الإنترنت العامة ليست دائمًا الركيزة المناسبة لحركة المرور الحرجة. الفرق الداخلية غالبًا ما تكون مثقلة. يمكن للموفر الذي يجمع بين الوصول الخاص، وتسليمات موفر السحابة، والأدلة التشغيلية، وانضباط مكتب الخدمة أن يخلق قيمة.
الخطر حقيقي بنفس القدر. أصبحت لغة السحابة المتعددة مضخمة. تعلم العملاء أن تجريد السحابة غالبًا ما يخفي التكاليف بدلاً من إزالتها. خدمات موفر السحابة المباشرة تتحسن. منصات التوصيل البيني ناضجة. منافسو الشبكة كخدمة مرئيون. يمكن للمشترين تجميع بدائل موثوقة. لذلك يجب على InterCloud داخل BSO أن تفوز بالتنفيذ، وليس بالمفردات.
السؤال الحاسم بسيط: بعد تغيير أو حادث، هل يمكن للموفر إثبات الحالة المقبولة؟ إذا كان بإمكانه، فالخدمة ليست مجرد اتصال. إنها تحكم تشغيلي على حدود صعبة بين شبكات المؤسسات ومنصات السحابة. إذا لم يستطع، فالمشتري يترك مع طبقة أخرى من الإدارة فوق نفس عدم اليقين القديم.
هذا هو المعيار المناسب لـ InterCloud الآن. ليس ما إذا كانت الشركة تستطيع قول "اتصال سحابي". ليس ما إذا كانت BSO لديها شبكة واسعة. ليس ما إذا كانت البوابة يمكنها تقديم طلب. المعيار هو ما إذا كان اتصال السحابة المقصود للعميل يصبح حالة موثقة ومراقبة وقابلة للدعم وقابلة للدفاع اقتصاديًا، بشكل متكرر، تحت ضغط التغيير العادي وتحت ضغط الانقطاع. كل شيء آخر هو فقط نسخة الكتيب من المسار.