ملخص

  • Cloud Provider USA, LLC. لديها علامة شبكة عامة حقيقية:ARIN يسرد AS46518كنشط، وRIPEstat يراه معلنًا، ووجهات التوجيه الحالية تظهر خمس بادئات IPv4 منشؤها الشركة.
  • قصة الخدمة أقل اكتمالاً من قصة التوجيه. تصف الصفحة الرئيسية HTTP الخاصة بالشركة استضافة سحابية، IaaS، DaaS، DRaaS وBaaS، بينما يصل مسار HTTPS الحالي إلى Itrica، التي تقول صفحاتها العامة إن Cloud Provider USA تم دمجها في منصة خدمة Itrica في أواخر عام 2013.
  • أقوى ادعاء تشغيلي ليس "سحابة" بل "اعتماد مادي مستضاف": سعة مركز بيانات مستأجرة أو مسيطر عليها، تنوع النقل، مخزون الخوادم والتخزين، استجابة الدعم، استمرارية الفوترة وخيارات خروج العميل.
  • يجب على المشترين التعامل مع لغة التكرار والمحلية والتعافي من الكوارث كفرضيات حتى تتمكن Cloud Provider USA أو المنصة المشغلة من إظهار تعيينات المنشأة الحالية، وأدلة اختبار الاستعادة، وتغطية RPKI، وعقود النقل، ومسارات التصعيد، والوصول الاحتياطي القابل للنقل.

مزود سحابي بشبكة صغيرة لكن مرئية

Cloud Provider USA, LLC. هي نوع شركات البنية التحتية التي يمكن أن تبدو أكبر في مفردات الخدمة مما هي عليه في الأدلة العامة. اسمها يعد بمزود سحابي وطني. موقعه القديم العمومي يقول إن الشركة تقدم خدمات بيانات وتكنولوجيا حيوية تتراوح من البيانات الضخمة إلى الاستضافة السحابية، ويسرد IaaS وDaaS وDRaaS وBaaS ضمن المنتجات التي كانت تتوقع تقديمها. لكن أدلة سجله أضيق بكثير وأكثر فائدة: نظام مستقل واحد، كتلة IPv4 مخصصة مباشرة واحدة، خمس بادئات معلنة مرئية، لا إدخال PeeringDB عام، وسجل خدمة يجب الآن قراءته جنبًا إلى جنب مع الحضور الشبكي الحالي لـ Itrica.

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

أدلة الشبكة أكثر حداثة.سجل RDAP الخاص بـ ARIN لـ AS46518يحدد النظام المستقل باسم CLOUDPROVIDERUSA وCloud Provider USA, LLC. كمسجل. يظهر AS كنشط، مع عنوان المسجل في كوينسي، ماساتشوستس.سجل ARIN الشبكي لـ 100.42.112.0 حتى 100.42.127.255يسرد تخصيصًا مباشرًا لـ IPv4 باسم CPU-1.نظرة AS العامة لـ RIPEstatتقول إن AS تم إعلانه في وقت الاستعلام، وحالة التوجيه لـ RIPEstatلاحظت الشبكة من جميع أقران IPv4 RIS البالغ عددهم 326 في مجموعة نتائجه، مع إعلان 1,536 عنوان IPv4 عبر خمس بادئات وعدم إعلان فضاء IPv6.

يمنح ذلك Cloud Provider USA أثرًا أكثر جوهرية من موقع ويب متوقف أو قائمة إعادة بيع. إنها شبكة منشأ، وليس مجرد اسم في دليل. في الوقت نفسه، الأثر محدود. البادئات الخمس هي 100.42.112.0/24 و100.42.113.0/24 و100.42.114.0/24 و100.42.124.0/23 و100.42.126.0/24، وفقًالبيانات البادئات المعلنة لـ RIPEstat. عدد العناوين كافٍ لمنصة استضافة مُدارة مدمجة وخدمات العملاء وأنظمة التحكم وبنية تحتية للمزود. لكنه ليس بحد ذاته دليلاً على سعة احتياطية كبيرة. كما يقول القليل عن عدد العناوين المستخدمة فعليًا، أو مقدار الحوسبة المشغلة، أو ما إذا كانت الأجهزة الاحتياطية مخزنة، أو كيف سيتم نقل العملاء إذا فقدت منشأة واحدة الطاقة أو فشل مزود النقل.

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

ما تقول الشركة إنها تبيعه

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

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

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

يضيف السلوك الشبكي الحالي طبقة أخرى. لا يزال موقع HTTP يعرض مواد Cloud Provider USA، لكن طلبات HTTPS لنفس النطاق تهبط علىItrica. تقولصفحة حول Itricaالخاصة بها إن Cloud Provider USA تأسست في عام 2011 لبناء حلول تكنولوجية تقلل التكلفة والوقت اللازمين لإدارة البنية التحتية، وأن الشركتين تم دمجهما في أواخر عام 2013 عند توحيد خدماتهما. نفس الصفحة تقول إن المنصة المدمجة تدير أعباء عمل حرجة وعالية الأداء مع تنقل البيانات وحمايتها، وأن المنصة الأساسية حصلت على شهادات موجهة للامتثال بمرور الوقت. هذا ادعاء عام مهم، لكن يجب قراءته كإشارة سياق تشغيلي حالي، وليس بديلاً عن أدلة المنشأة والشبكة والدعم الخاصة بـ Cloud Provider USA.

تصف صفحات خدمة Itrica الحالية عرضًا أكثر ثراءً من صفحة Cloud Provider USA القديمة. تناقشالصفحة الرئيسية لـ Itricaالحوسبة والتخزين عاليي الأداء، وخدمات السحابة المُدارة، والنسخ الاحتياطي، والتعافي من الكوارث، والأمان المدمج، والبنية التحتية ذات التكلفة الثابتة، ودعم Kubernetes والذكاء الاصطناعي والشبكات الطرفية وتكامل التطبيقات. تدّعيصفحة مراكز بيانات IaaS لـ Itricaوجود منشآت في بوسطن ولاس فيغاس وطوكيو وزيورخ ودوسلدورف، مع أنظمة مُدارة ووثائق امتثال وتدابير أمنية وطاقة وتبريد مزدوجين ومراقبة على مدار الساعة طوال أيام الأسبوع والتعافي من الكوارث والتوفر العالي حسب الحاجة. تسرد صفحة حول المنشآت في لاس فيغاس وسومرفيل وزيورخ ودوسلدورف وطوكيو، وتقول إن المنصة تستخدم شبكة BGP الخاصة بها بسرعة 10 جيجابت في الثانية التي تربط مراكز البيانات للنسخ الاحتياطي وبيئات التعافي من الكوارث.

هذه البيانات ذات صلة لأن جهات اتصال الشبكة والسلوك الشبكي الحالي لـ Cloud Provider USA تشير إلى سطح تشغيل Itrica. لا تزال غير كافية للإعلان عن سلامة عبء عمل معين. "السحابة" هي نموذج توصيل؛ لا تلغي الحاجة إلى معرفة أي مبنى، أي قفص، أي غرفة اجتماع ناقل، أي مسار طاقة، أي رف أقراص، أي وظيفة نسخ احتياطي وأي شخص على المكالمة سيتحمل العميل في أسبوع سيء.تعريف NIST للسحابةمفيد هنا لأنه يفصل خصائص الخدمة مثل تجميع الموارد والخدمة المقاسة عن الأصول الأساسية التي تجعلها ممكنة. قد يشتري العميل تجريدًا، لكن المزود لا يزال يشغل الأجهزة.

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

البصمة المادية وراء التجريد

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

يسجل Cloud Provider USA اسم ماساتشوستس مرارًا. يدرج ARIN عنوان الشركة في كوينسي. يستخدم سجل جهة اتصال ARIN عنوان شارع في بوسطن وعناوين بريد إلكتروني للدعم في كل من cloudproviderusa.com وitrica.com. تعطي صفحات Itrica عنوان مقر رئيسي في بوسطن وتصف منشآت أو مراكز بيانات افتراضية في ماساتشوستس ومواقع أخرى. وجد بحث DNS العام من بيئة العمل أن cloudproviderusa.com وwww.cloudproviderusa.comيحلان إلى 100.42.124.32، التي تقع داخل التخصيص المباشر لـ Cloud Provider USA، بينما حل portal.cloudproviderusa.com إلى 100.42.120.30. وهذا يعني أن جزءًا على الأقل من العقارات الشبكية المواجهة للعملاء موجه إلى فضاء العناوين الخاص بالمزود. لم يستجب النطاق الفرعي للبوابة لـ HTTP أو HTTPS خلال نافذة اختبار مدتها 20 ثانية من بيئة البحث هذه، لذا يجب التعامل معه كإشارة توفر، وليس دليلاً على التقاعد.

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

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

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

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

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

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

سطح التوجيه: خمس بادئات، عدة جيران، ولا رؤية لـ IPv6

AS46518 هو أوضح دليل على أن Cloud Provider USA لا تزال مرئية في نظام التوجيه العالمي. يصفBGP.toolsAS باسم Cloud Provider USA, LLC. ويظهر الموقع الإلكتروني كـ cloudproviderusa.com. يسرد نفس البادئات الخمس المرئية في RIPEstat ويبلغ عن أربعة ناقلين علويين وستة أقران عند تحميل الصفحة. الناقلون العلويون الموضحون في الصفحة المسترجعة يشملون TowardEX Technologies International وArelion وLumen وIPTP. رأتبيانات جيران ASN لـ RIPEstatخمسة أرقام ASN مجاورة فريدة في أحدث وقت متاح في الاستعلام: AS1299 وAS140951 وAS27552 وAS3356 وAS41095.

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

نتيجة حالة التوجيه الحالية لـ RIPEstat إيجابية بشأن رؤية IPv4. رأت AS46518 من جميع أقران IPv4 RIS في مجموعة البيانات وأحصت خمس بادئات IPv4 تغطي 1,536 عنوانًا. كما أبلغت عن صفر إعلانات IPv6. هذا لا يثبت أن Cloud Provider USA لا يمكنها خدمة IPv6 في ترتيبات خاصة، لكنه يعني أن قابلية الوصول العامة لـ IPv6 غير مرئية من خلال تلك النظرة. بالنسبة للعملاء ذوي متطلبات الامتثال الحديثة أو المشتريات أو المنتجات، فإن عدم وجود أدلة IPv6 عامة هو قيد يجب السؤال عنه مباشرة. لا يزال بإمكان بعض أعباء عمل المؤسسات العمل على بنية تحتية لـ IPv4 فقط.

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

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

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

التحقق من صحة أصل المسار هو نقطة ضعف أخرى في الأدلة العامة. أعادتاستجابة التحقق من صحة RPKI لـ RIPEstat لـ 100.42.112.0/24، والاستجابات المكافئة للبادئات الأخرى المرئية، "غير معروف" بدون ROAs مصادقة في وقت الاستعلام. في مصطلحات RPKI، غير معروف ليس غير صالح. هذا يعني أن المسار لم يكن مغطى بتفويض أصل مسار مرئي للمصادق. تشرحهندسة RPKI لـ IETFنموذج شهادة الموارد لأمن أصل المسار. بالنسبة لمزود بنية تحتية مُدار، غياب ROAs مرئية ليس انقطاعًا للعميل بحد ذاته، لكنه يترك طبقة حماية من اختطاف المسار والتصفية غير مستخدمة. يجب على العملاء الذين يعتمدون على AS لنقاط نهاية عامة أن يسألوا ما إذا كانت Cloud Provider USA أو المنصة المشغلة تخطط لنشر ROAs والحفاظ على كائنات المسار باستمرار.

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

BGP نفسه هو مجرد بروتوكول قابلية وصول. يصفRFC 4271كيف يتبادل BGP معلومات قابلية الوصول إلى الشبكة بين الأنظمة المستقلة. لا يفحص ما إذا كان الخادم خلف عنوان سليمًا، أو ما إذا كان النسخ الاحتياطي قد اكتمل، أو ما إذا كانت مجموعة الأقراص تعيد البناء، أو ما إذا تم الإبلاغ عن نافذة صيانة، أو ما إذا كان يمكن للعميل الحصول على استعادة في الساعة 3 صباحًا. لذلك فإن سطح التوجيه لـ Cloud Provider USA هو أرضية، وليس سقفًا. إنه يثبت ما يكفي لإبقاء الشركة في محادثة البنية التحتية. لا يثبت ما يكفي للاعتماد على المنصة دون أدلة خدمة حالية.

ادعاءات التكرار تحتاج إلى أدلة استعادة

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

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

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

السؤال الثاني هو كيف يتم تخصيص أولوية الاستعادة. في انقطاع واسع، يريد كل عميل التعافي أولاً. إذا كان لدى المزود حوسبة احتياطية مخصصة لمجموعة فرعية من العملاء، فإن "DRaaS" يعتمد على سياسة الحجز. سعة التعافي المخصصة باهظة الثمن لأنها تظل خاملة جزئيًا. سعة التعافي المشتركة أرخص لكنها قد تكون مفرطة في الاشتراك. لا تكشف المواد العامة لـ Cloud Provider USA عن نسب الحجز. يجب على المشتري أن يسأل ما إذا كانت حوسبة التعافي وIOPS التخزين وتعيينات IP العامة وسعة VPN وعمالة الدعم مخصصة أو مجمعة أو بأفضل جهد.

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

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

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

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

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

العقد يكشف عدة مسارات فشل

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

يجب على العميل التأكد من أن جهات اتصال الفوترة وإجراءات النزاع وعلاجات الدفع الطارئة تُعامل كضوابط توفر.

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

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

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

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

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

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

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

محلية البيانات هي ميزة فقط عندما تكون محددة

يتم تصنيف Cloud Provider USA هنا كشركة خدمات سحابية أمريكية، وسجلات ARIN تدعم شبكة أمريكية وبصمة مؤسسية. قصة الخدمة، مع ذلك، ليست محلية بحتة. تصف صفحات Itrica العامة مراكز بيانات في الولايات المتحدة وأوروبا واليابان، وتقدم التغطية العالمية كفائدة لشركات SaaS. هذا مفيد لزمن الوصول والمرونة. يعني أيضًا أن سيادة البيانات لا يمكن افتراضها من اسم الشركة.

تقول سياسة خصوصية Cloud Provider USA إن الموقع مستضاف ويُشغل في الولايات المتحدة وأن المعلومات المقدمة للموقع سيتم نقلها وتخزينها في الولايات المتحدة للمعالجة. هذا البيان مفيد لسياق الموقع والخدمة الموصوفين في سياسة عام 2014. لا يجيب على كل سؤال عبء عمل حديث. قد يستخدم التطبيق المستضاف مواقع نسخ احتياطي منفصلة ونسخ تعافي من الكوارث وأنظمة تسجيل وأدوات مراقبة وأنظمة تذاكر ووصول دعم ومنتجات طرف ثالث وخدمات بريد إلكتروني. أظهرت نتائج DNS العامة أيضًا مبادلات بريد Google لـ cloudproviderusa.com، بينما تسرد صفحات Itrica عناوين اتصال في itrica.com. لا شيء من ذلك إشكالي بطبيعته.

يعني ببساطة أن المحلية تحتاج إلى التحديد حسب نوع البيانات والنظام، وليس استنتاجها من جغرافية العلامة التجارية.

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

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

المواد العامة الحالية لا تحسم هذه الأسئلة. تقول Itrica إن منشآتها تلبي المعايير الصناعية بما في ذلك HIPAA وPCI وSOC2 في صفحة مراكز بيانات IaaS. تقول صفحة حول إن المنصة كانت موجهة للامتثال منذ العمل في التجارب السريرية ولاحقًا SOC 2 Type II. قد تكون هذه الادعاءات قيمة، لكن ادعاءات الامتثال تحتاج إلى نطاق. تقرير SOC 2، على سبيل المثال، ينطبق على أنظمة وضوابط وفترة محددة. دعم HIPAA يعتمد على شروط الشريك التجاري والضمانات الفعلية. أهمية PCI تعتمد على ما إذا كانت بيانات حامل البطاقة ضمن النطاق. يجب على العملاء طلب التقارير الحالية والرسائل الجسرية وأوصاف النطاق وقوائم المواقع بدلاً من الاعتماد على اختصار صفحة الويب.

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

بالنسبة لـ Cloud Provider USA، الاستنتاج الدقيق هو هذا: الشركة لديها تسجيل أمريكي وأدلة توجيه، وصفحات الخدمة الحالية المرتبطة بها تصف بنية تحتية عالمية. يمكن أن يكون هذا المزيج قوة. يمكن أن يخلق أيضًا غموضًا. سيادة البيانات هي حقيقة تعاقدية ومعمارية، وليست سمة علامة تجارية.

من يتأثر عندما يفشل النظام

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

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

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

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

فشل مخزون الأجهزة أكثر دقة. إذا فشل قرص وكان لدى المزود قطع غيار، فإن الحادث روتيني. إذا فشلت عدة أقراص أثناء إعادة البناء، إذا كانت وحدة تحكم التخزين في نهاية العمر الافتراضي، إذا كان يجب طلب جزء خادم متوافق، أو إذا كان البائع لم يعد يدعم منصة، يمكن أن يطول وقت التوقف. لا تكشف الصفحات العامة لـ Cloud Provider USA عن عمر الأجهزة أو مخزون القطع الغيار. يشير موقع Itrica الحالي إلى حوسبة عالية الأداء وسعة خادم وتخزين مهندسة وخبرة Ceph ومتخصصي VMware وKVM وتخزين محدد بالبرمجيات. هذه إشارات قدرة مفيدة، لكن يجب على العملاء مع ذلك طلب إدارة دورة حياة المنصة ومخزون الاستبدال ذي الصلة بخدمتهم.

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

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

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

درجة الأدلة التشغيلية

يدعم السجل العام رؤية ثقة متوسطة في شبكة Cloud Provider USA، وليس رؤية ثقة عالية في قدرتها الخدمية الحالية. أقوى دليل هو دليل السجل والتوجيه. AS46518 نشط في ARIN. التخصيص المباشر نشط. RIPEstat يرى AS معلنًا. BGP.tools وRIPEstat يظهران مجموعة توجيه IPv4 مدمجة ولكن مرئية وشبكات مجاورة متعددة. هذا يكفي لقول إن الشركة لديها بصمة شبكة حقيقية.

الدليل الأضعف يتعلق بالعمليات التجارية الحالية. موقع Cloud Provider USA HTTP ضئيل وقديم في الأسلوب. مسار HTTPS يهبط على Itrica. النطاق الفرعي لبوابة العميل يحل لكنه لم يستجب في الاختبار الموقوت. PeeringDB ليس لديه إدخال ASN عام. الصفحات العامة لا تكشف عن صفحة حالة حالية أو منشآت مسماة أو تجمع سعة أو عدد العملاء أو قائمة الدعم أو تاريخ التشغيل أو تاريخ الحوادث أو تغطية RPKI أو وضع IPv6 مفصلاً. توفر صفحات Itrica الحالية قصة خدمة أكثر ثراءً، لكنها تمزج العروض الحالية مع التاريخ ولغة القدرة الواسعة. إنها سياق مفيد، وليس تدقيق تشغيلي كامل.

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

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

ما يجب طرحه قبل الاعتماد على Cloud Provider USA

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

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

يجب أن تربط أسئلة الشبكة BGP بالخدمة. ما هي البادئات التي سيستخدمها العميل؟ هل الخدمة أحادية الربط داخل منشأة واحدة حتى لو كان لدى AS46518 ناقلون علويون متعددون؟ هل يتم استخدام Arelion أو Lumen أو TowardEX أو IPTP أو ناقلين آخرين لموقع العميل الفعلي؟ هل المسارات محمية بواسطة ROAs لـ RPKI أم فقط بسياسة توجيه تقليدية؟ هل حماية DDoS مضمنة؟ هل يمكن للعميل إحضار عناوين IP الخاصة به؟ هل سجلات DNS يتحكم فيها العميل أم المزود أم كليهما؟ ما هو إجراء الفشل إذا فشل ناقل علوي أو جهاز توجيه أو توصيل بيني؟

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

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

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

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