مركز بيانات Cloud 9 Ltd. يجب أن يثبت ما إذا كانت سعة مركز البيانات المسوقة يمكنها الصمود في ظل قيود الطاقة والناقل

ملخص

• الكائن الدقيق للشبكة العامة خلف اسم الدليل ليس حافة طريقًا مباشرًا حاليًا.نظرة عامة على AS203301 من RIPEstatتحدد الحامل كمركز بيانات Cloud 9 Ltd.، لكنها تشير إلى أن ASN غير معلن في 12 يوليو 2026، وحالة التوجيه من RIPEstatتظهر مساحة IPv4 أو IPv6 معلنة صفرية.
• نفس منظمة Cloud 9 Ltd. لديها إشارة تشغيل مباشرة أقوى بكثير من خلال AS57814.حالة التوجيه من RIPEstat لـ AS57814تظهر ASN معلنًا مع 27 بادئة IPv4 و3 بادئات IPv6 و12 جارًا مرصودًا، بينمانص سجل RIPEيربط AS57814 بـ ORG-CL434-RIPE، منظمة Cloud 9 Ltd.
• الموقع العام لـ Cloud9 يسوق مركز بيانات محايدًا للناقل في تبليسي، واستضافة مشتركة، وخوادم افتراضية خاصة (VPS)، وخوادم افتراضية مخصصة (VDS)، وخوادم مخصصة، ونطاقات، واستضافة مشتركة.صفحة مركز البيانات الخاصة بهاتذكر أن معظم الخدمات تُقدم من منشأتها في تبليسي وتدرج ادعاءات حول الطاقة والتبريد والإطفاء والأمان والاتصال البيني.
• ادعاءات المرونة المادية محددة بشكل غير عادي لكنها لا تزال ادعاءات موجهة للمشتري. تقول Cloud9 إن المنشأة تستخدم ثلاث محطات فرعية مستقلة للطاقة، ومولد ديزل بقدرة 630 كيلو فولت أمبير، وتغذية طاقة N+N لمنطقة الاستضافة المشتركة، وتبريد DX، ونظام إطفاء Novec 1230، ووصول مجدول للمنشأة، وتغطية هندسية على مدار الساعة؛ لا يزال العملاء بحاجة إلى دليل على سجل الصيانة، ووقت تشغيل المولد، وتجاوز التبريد، واستعادة الخدمة.
• درجة الأدلة متوسطة. هناك أدلة حقيقية على منشأة Cloud 9 Ltd. وتوجيه AS57814، بالإضافة إلى إدخالات PeeringDB لـ Cloud9 Dinamo Arena وIXP.ge، لكن كائن AS203301 الدقيق هادئ والمواد العامة لا تثبت سعة مدققة، أو تشغيل مزدوج نشط للمرفق، أو تنوع مسار الناقل، أو هامش طاقة احتياطي، أو نتائج تجاوز العملاء.

الشركة مرئية، لكن ASN المخصص لمركز البيانات هادئ

الاختبار الأول لمركز بيانات Cloud 9 Ltd. ليس ما إذا كانت العلامة التجارية لديها موقع إلكتروني. بل ما إذا كانت هوية الشبكة العامة الدقيقة المرتبطة بموضوع الدليل تقوم بعمل اليوم. على هذا السؤال، الإجابة هي تخفيض.نظرة عامة على AS203301 من RIPEstatتسمي الحامل كمركز بيانات Cloud 9 Ltd. وتظهر ASN كمخصص، لكنها تبلغ أيضًا أن ASN غير معلن.حالة التوجيه من RIPEstat لـ AS203301لا تظهر بادئات IPv4 معلنة، ولا بادئات IPv6 معلنة، ولا جيران مرصودين في عرض 12 يوليو 2026.

هذه ليست حاشية صغيرة. إذا كانت بطاقة دليل، أو جدول توجيه، أو مذكرة شراء، أو ملاحظة عميل تعامل AS203301 كالحافة العامة الحالية لخدمة مركز بيانات، فإن الأدلة الحالية لا تدعم ذلك.البادئات المعلنة من RIPEstat لـ AS203301تعيد قائمة حالية فارغة.تاريخ التوجيه من RIPEstatيظهر أن AS203301 أنشأ سابقًا 185.139.56.0/22 من 2016 حتى أكتوبر 2023، لذا لم يكن ASN خاملًا دائمًا. لكن الطريق التاريخي ليس سعة عميل قابلة للاستخدام في 2026. إنه دليل على تشغيل سابق، وليس خدمة حالية.

النقطة الأكثر إثارة للاهتمام هي أن AS203301 الهادئ لا يجعل Cloud 9 Ltd. تختفي. إنه يفرض فصلًا بين ASN مخصص لمركز بيانات وشبكة المشغل الحالية الأوسع.نظرة عامة على AS57814 من RIPEstatتحدد AS57814 كـ Cloud9 Cloud 9 Ltd. وتشير إليه كمعلن.حالة التوجيه من RIPEstat لـ AS57814تبلغ عن 27 بادئة IPv4 و3 بادئات IPv6 ورؤية كاملة لمجمّعي الطرق في العرض المفحوص.البيانات المشتقة من سجل RIPE لـ AS57814تربط ASN بـ ORG-CL434-RIPE، نفس مقبض منظمة Cloud 9 Ltd. الظاهر فيسجل منظمة RIPE.

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

المنشأة المسوقة هي نقطة ارتكاز واحدة في تبليسي

موقف Cloud9 العام مباشر:صفحة مركز البياناتتقدم الشركة كمشغل مركز بيانات محايد للناقل في جورجيا وتقول إن معظم خدمات Cloud9 تُقدم من مركز بياناتها في تبليسي. التذييل وصفحة الاتصاليعطيان موقع التشغيل كـ 2 شارع أكاكي تسيريتيلي، ملعب دينامو، بوابة 5، تبليسي، جورجيا 0112.سجل منشأة PeeringDB لـ Cloud9 Dinamo Arenaيضع أيضًا منشأة باسم Cloud9 Dinamo Arena في A. Tsereteli Ave 2 في تبليسي، مع Cloud9 LTD كمنظمة وجهات اتصال دعم عبر البريد الإلكتروني.

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

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

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

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

ادعاءات الطاقة محددة، لكن وقت التشغيل لا يزال الاختبار

ادعاءات الطاقة العامة لـ Cloud9 محددة بشكل غير عادي لمزود استضافة إقليمي.صفحة مركز البياناتتذكر أن المنشأة مدعومة بثلاث محطات فرعية مستقلة للطاقة ولديها مولد ديزل بقدرة 630 كيلو فولت أمبير. نفس الصفحة تقول إن منطقة الاستضافة المشتركة تستخدم تغذية طاقة احتياطية N+N مع دعم UPS.صفحة الاستضافة المشتركةتكرر الوعد بعبارات موجهة للعميل: حزم الرفوف تدرج طاقة مزدوجة A/B لخوادم 1U و2U، بينما خدمة الخادم البرجي مدرجة بطاقة مفردة.

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

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

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

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

التبريد والحماية من الحرائق والأمان يضيقان مسارات الفشل المحتملة

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

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

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

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

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

الحياد تجاه الناقل يجب أن يعني أكثر من مجرد قائمة ناقل

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

أدلة التوجيه تدعم جزئيًا قصة الاتصال البيني.جيران ASN من RIPEstat لـ AS57814يظهر 12 جارًا مرصودًا في العرض المفحوص، بما في ذلك شبكات جورجية مثل Magticom وCaucasus Online وSystem Net وSilknet وSkytel، بالإضافة إلى شبكات مجاورة أخرى وIXP.ge.ملف شبكة AS57814 على PeeringDBيدرج Cloud9 كشبكة خدمات شبكات إقليمية مع دعم IPv6 وسياسة نظير مفتوحة ومنشأة واحدة وحضور تبادل واحد.إدخال netixlan لـ Cloud9 على PeeringDBيظهر اتصال 10 جيجابت في الثانية في IXP.ge.

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

سياسة الطريق العامة لـ AS57814 فيالبيانات المشتقة من سجل RIPEتسمي عدة ASN منبع أو مجاورة في بيانات الاستيراد والتصدير. سجل AS203301 الدقيق أضيق:البيانات المشتقة من سجل RIPE لـ AS203301تدرج بيانات سياسة تتضمن AS34797 وAS35076، بينما تظهر حالة الطريق الحالية عدم وجود إعلانات حية. هذا الاختلاف هو سبب آخر لطرح أي خطة طريق تنطبق على خدمة عميل معينة.

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

AS57814 يظهر اتساعًا لا يظهره AS203301

أقوى دليل شبكة حالي هو AS57814، وليس AS203301. في عرض RIPEstat في 12 يوليو 2026، لدى AS57814 بصمة واسعة لمشغل استضافة إقليمي ومركز بيانات جورجي: 27 بادئة IPv4 و3 بادئات IPv6 ورؤية كاملة من أقراص RIPE RIS في كل من عائلتي العناوين.البادئات المعلنة من RIPEstat لـ AS57814تتضمن طرق IPv4 مثل 188.93.94.0/24 و185.139.56.0/24 و185.139.57.0/24 و185.139.58.0/24 و45.138.44.0/22 وعدة /24 أخرى، بالإضافة إلى مساحة IPv6 بما في ذلك 2a0d:8a00::/32.

هذا الاتساع يغير استنتاج المقال. إذا كان فقط AS203301 موجودًا، لكانت درجة الأدلة ضعيفة أو سلبية للتوجيه الحالي. AS57814 يمنع ذلك. إنه يظهر شبكة Cloud 9 Ltd. حية مع IPv4 وIPv6، وجيران متعددون، ودعم حالي لأمان التوجيه.التحقق من صحة RPKI من RIPEstat لـ 188.93.94.0/24 تحت AS57814يعيد صالحًا، ونفس الشيء صحيح للبادئات /24 المفحوصة من Cloud9 المنحوتة من مساحة 185.139.56.0/22 القديمة.

التباين مع AS203301 حاد.نظرة عامة على البادئة من RIPEstat لـ 185.139.56.0/22يظهر التجميع نفسه غير معلن، مع /24 ذات الصلة مرئية الآن.اتساق توجيه البادئة من RIPEstat لـ 185.139.56.0/22يظهر 185.139.56.0/24 و185.139.57.0/24 و185.139.58.0/24 في BGP حي تحت AS57814، بينما كائن الطريق /22 غير حي.التحقق من صحة RPKI من RIPEstat لـ AS203301 و185.139.56.0/22يعيد نتيجة asn غير صالح لأن تفويض الطريق في العرض المفحوص يشير إلى AS57814، وليس AS203301.

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

IXP.ge يحسن القصة المحلية لكنه لا يزيل المخاطر الدولية

ادعاء الاتصال البيني لـ Cloud9 مدعوم بأدلة IXP.ge.سجل IXP.ge على PeeringDBيحدد IXP.ge، المعروف أيضًا باسم Geo-IX، في تبليسي ويشير إلى أن التبادل متاح في تبليسي وكوتايسي.صفحة عن IXP.geتصف غرض جمعية التبادل كالتبادل المباشر لحركة الإنترنت بين الشبكات الجورجية دون استخدام شبكات طرف ثالث.صفحة أعضاء IXP.geتدرج Cloud9 بين الأعضاء الكاملين.

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

لا ينبغي الخلط بين المشاركة في IXP والازدواجية الكاملة. يمكن للنظير في التبادل أن يقلل الحمل على العبور المنبع ويحسن المسارات المحلية، لكنه لا يحمي العميل تلقائيًا من فشل طاقة المنشأة، أو فشل المحول، أو مشكلة خادم الطريق، أو كسر الألياف، أو الازدحام الدولي، أو انقطاع طبقة التطبيق وDNS. يدرج PeeringDB منفذ Cloud9 في IXP.ge عند 10 جيجابت في الثانية في السجل المفحوص؛ صفحة مركز بيانات Cloud9 نفسها تعلن بشكل منفصل 250 جيجابت في الثانية من سعة الاتصال البيني الإجمالية. يمكن أن يكون كلا الرقمين صحيحين إذا كان الأخير يشمل التوصيلات المتقاطعة الخاصة والمنبعين وسعة محلية أخرى. السجلات العامة لا توفق بين التركيبة.

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

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

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

قائمة الاستضافة المشتركة لـ Cloud9 شفافة بشكل غير عادي بشأن الحزمة الأساسية.صفحة الاستضافة المشتركةتدرج حزم رفوف 1U و2U مع طاقة مزدوجة A/B، ورابط 1 جيجابت في الثانية ورابط إدارة منفصل. كما تدرج خيار خادم برجي مع طاقة مفردة. الصفحة تذكر أن كل عميل يتلقى اتصال 1 جيجابت في الثانية غير محدود لمزودي ISP الجورجيين و30 ميجابت في الثانية للاتصال العالمي، وتصف خيارات نصف الرف والرف الكامل والقلص كترتيبات مخصصة أو مؤسسية.

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

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

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

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

الخوادم الافتراضية والمخصصة تحول ادعاءات المنشأة إلى التزامات عميل

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

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

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

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

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

الشروط تكشف حدود الصيانة والوصول

شروط خدمة Cloud9مهمة لأنها تكشف أجزاء من الحدود التشغيلية التي لا تفعلها صفحات التسويق. الشروط تسمي Cloud 9 LLC، وتعطي معرف الشركة 405063755، وتذكر عنوانًا قانونيًا جورجيًا، وتدرج فئات المنتجات المقدمة من خلال موقع Cloud9 والبوابة. تعرف خدمات مركز البيانات لتشمل تأجير رفوف الاتصالات، والتوصيلات المتقاطعة، ووحدات توزيع الطاقة، والاتصال البيني لمزودي الإنترنت ومشغلي الهاتف المحمول، وتأجير عناوين IP.

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

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

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

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

صورة أمان الطريق أفضل على الحافة النشطة

أمان الطريق هو مجال واحد تبدو فيه حافة Cloud9 النشطة أفضل من ASN الخامل.التحقق من صحة RPKI من RIPEstat لـ 188.93.94.0/24 المنشأ بواسطة AS57814يعيد صالحًا. البادئات المفحوصة من Cloud9 185.139.56.0/24 و185.139.57.0/24 و185.139.58.0/24 و45.138.44.0/22 و2a0d:8a00::/32 تعيد أيضًا صالحة عند اختبارها ضد AS57814. هذه إشارة نظافة إيجابية للطرق التي من المرجح أن يراها العملاء اليوم.

صورة AS203301 الدقيقة هي العكس. التجمع القديم 185.139.56.0/22 ليس حيًا كتجمع فينظرة عامة على البادئةالمفحوصة، وفحص صحة أصل AS203301 لذلك التجمع يعيد asn غير صالح لأن التفويض المرئي هو لـ AS57814. لا ينبغي تضخيم ذلك. إنه يعزز ببساطة أن AS203301 ليس حافة الطريق الحالية لكتلة العناوين القديمة.

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

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

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

السعة المثبتة ليست نفس السعة الجاهزة

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

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

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

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

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

من يتأثر عندما تفشل نقطة ارتكاز تبليسي

قاعدة العملاء المرئية غير معلنة بالكامل، لكنصفحة عن Cloud9تعلن عن أكثر من 1,200 عميل نشط، وأكثر من 3,500 خدمة نشطة، وأكثر من 5,000 نطاق مسجل، ووقت تشغيل نظام 99.9 في المئة. هذه الأرقام منشورة من المشغل ويجب التعامل معها كأرقام تسويقية ما لم تكن موثقة تعاقديًا، لكنها تظهر نوع الاعتماد على المحك. هذا ليس مجرد ASN فارغ بدون وعد عميل مرفق. إنه عمل استضافة ومركز بيانات يقدم نفسه كمزود بنية تحتية محلية.

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

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

أدلة الطريق تشير إلى أن Cloud9 لديها شبكة حقيقية تتجاوز stub صغير. عدد البادئات الحالي لـ AS57814، والجيران، ودعم IPv6 ذات معنى. سجل منشأة Cloud9 Dinamo Arena على PeeringDB يضيف طبقة اتصال مادي. عضوية IXP.ge تضيف صلة تبادل محلي. لكن السجل العام لا يظهر نتائج تجاوز العميل. إنه لا يظهر عدد العملاء الذين يديرون خدمات موقع واحد، أو عدد الذين يستخدمون نسخًا احتياطية خارج المنشأة، أو عدد الذين لديهم خدمة ناقل مزدوج، أو عدد الذين يعرفون الفرق بين حدود النطاق الترددي المحلي والعالمي.

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

ما الذي سيرفع درجة الأدلة

يمكن لـ Cloud9 رفع الثقة دون كشف تفاصيل منشأة حساسة. صفحة شبكة عامة يمكن أن تذكر الدور الحالي لـ AS203301، والدور النشط لـ AS57814، ومجموعة AS الرئيسية، وخيارات BGP للعميل، وسياسة أمان الطريق، وممارسة تفويض الطريق. صفحة منشأة يمكن أن تحافظ على الأمان مع إعطاء نطاقات لعدد الخزائن الحية، وكثافة الرف المتاحة، وكثافات الطاقة المدعومة، ووقت تشغيل المولد، وتكرار UPS، وتكرار التبريد، ومعايير إشعار الصيانة. صفحة حالة يمكن أن تفصل خدمات المنشأة والشبكة والاستضافة وDNS والبوابة والبريد الإلكتروني.

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

الأدلة الحالية تدعم درجة متوسطة. AS203301 وحده ليس حيًا ويجب تخفيضه. العملية الأوسع لـ Cloud9 مرئية من خلال صفحات المنشأة الرسمية، والشروط القانونية، وتوجيه AS57814، وإدخالات المنشأة والتبادل على PeeringDB، وعضوية IXP.ge، وفحوصات أصل الطريق الصالحة على البادئات النشطة. الفجوات المتبقية هي تلك التي تهم عادة أثناء الانقطاع: الاستقلال الفعلي لمسار الطاقة، وتحمل المولد، وتجاوز التبريد، والتنوع المادي للناقل، وتأثير الصيانة، والأجهزة الاحتياطية، واستعادة النسخ الاحتياطي، ودليل ترحيل العميل.

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