TEMPLE Cloud Temple SAS تبيع سعة مستضافة لا تزال تعتمد على الرفوف والنقل ونوافذ الإصلاح

ملخص

• تعيين TEMPLE Cloud Temple SAS إلى نشاط تجاري فرنسي سحابي سيادي: تصف صفحات Cloud Temple العامة بنية IaaS المؤهلة من SecNumCloud، و IaaS من VMware، و IaaS مفتوح المصدر، وتخزين الكائنات، والخوادم المخصصة، والشبكة الخاصة الافتراضية، والشبكة الخلفية الخاصة، وخدمات الاستضافة والدعم للقطاعات المنظمة.
• تقول صفحات الامتثال الرسمية أن نطاق IaaS Secure Temple يغطي VMware IaaS و OpenSource IaaS و S3 Object Storage و HSM-KMS encryption و Bare Metal، مع صلاحية SecNumCloud v3.2 حتى 30 مايو 2028؛ وتسرد نفس الصفحة PaaS OpenShift بشكل منفصل.
• التوجيه العام حقيقي وحالي: أظهر RIPEstat أن AS33930 قد تم الإعلان عنه في 12 يوليو 2026، مع ست بادئات IPv4 وبادئتي IPv6، ونتائج أصل صالحة لـ RPKI في العرض المفحوص، ورؤية RIS واسعة.
• الخطر ليس أن المزود يفتقر إلى أدلة تشغيلية عامة؛ الخطر هو أن الشهادة ورؤية AS وملصقات المنتجات لا تزال لا تخبر العميل بالضبط أي رف، أو منطقة توفر، أو مسار استرداد، أو مستوى دعم، أو عملية خروج تحمي عبء عمل معين.
• يجب على المشترين التعامل مع الأدلة العامة لـ Cloud Temple كنقطة انطلاق قوية للعناية الواجبة، ثم التحقق من وضع عبء العمل، وتصعيد الدعم، وتوافر الأجهزة، واختبارات الاستعادة، ومسؤولية دائرة العميل، وتأثيرات الفوترة، وحدود قابلية نقل البيانات قبل نقل الأنظمة الحرجة.

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

صفحة الشركة الخاصة "من نحن؟" تضع Cloud Temple حول القطاعات الحساسة، وتسمي الصناعة والمالية والرعاية الصحية والقطاع العام كالأسواق التي يجب أن يهمها وعدها. تسرد صفحةالمواقعمكاتب في باريس / لا ديفونس، ليون، تور، كان ونانت، مع عنوان باريس / لا ديفونس في Le Belvedere - SPACES، 1-7 Cours Valmy، 92800 Puteaux. هذا دليل هوية مفيد، لكن خريطة المكاتب ليست خريطة البنية التحتية. لا ينبغي للمشتري أن يخلط بين عنوان المكتب والموقع الذي يعمل فيه جهاز افتراضي أو خادم مخصص أو حاوية S3 أو بوابة VPC أو رف مادي.

الدليل العام الأقوى هو بصمة الامتثال والمنتجات. تقول صفحةإجراءات الامتثاللـ Cloud Temple أن الشركة لديها شهادة ISO 27001 للبنية التحتية منذ 2018 وللخدمات المدارة منذ 2022، وشهادة HDS لأنشطة البيانات الصحية، وشهادة SecNumCloud v3.2، وتقارير ISAE 3402 وإدخالات امتثال أوروبية أخرى. تعطي نفس الصفحة بيان النطاق الأكثر واقعية: "IaaS Secure Temple" مدرج تحت SecNumCloud v3.2 مع صلاحية حتى 30 مايو 2028، وتقول الحاشية أن هذا النطاق يشمل VMware IaaS و OpenSource IaaS و S3 Object Storage و HSM-KMS encryption و Bare Metal. هذا لا يجعل كل منتج متطابقًا، لكنه يضع منتجات البنية التحتية الرئيسية داخل محيط تأهيل عام.

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

خط الإنتاج يوضح سبب أهمية هذه التفاصيل. يغطي عرض الحوسبة لـ Cloud Temple عدة أنماط استهلاك. يصف الموقع العامOpenSource IaaSللبنية التحتية الافتراضية على منصة سيادية، وVMware IaaSلعقارات VMware في بيئة سحابية مؤهلة، وBare Metalللخوادم المادية المخصصة، و VM Instances في المعاينة لمزيد من الأجهزة الافتراضية المشتركة على غرار السحابة. تصف الوثائق العامة لـ Cloud Temple لـ OpenSource IaaS حوسبة Cisco UCS، و IBM Spectrum Virtualize وتخزين الكتل IBM FlashSystem، وتخزين الكائنات Dell ECS، وشبكات Juniper، وشرائح حوسبة مخصصة وأحجام تخزين، وتسعير استهلاك شهري، ومفاهيم المنطقة ومنطقة التوفر، والنسخ الاحتياطي، وخيارات النسخ المتماثل، والتشغيل عبر API أو Terraform. هذه ليست كتالوج استضافة خفيف. إنها مجموعة تقنية مادية وتشغيلية.

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

تسرد مفاهيم OpenSource IaaS لـ Cloud Temple فئات الشرائح من ECO إلى PERFORMANCE 4، مع الذاكرة، وعدد النوى، واتصال 10 جيجابت/ثانية أو 25 جيجابت/ثانية، وبالنسبة للفئة الأعلى، وحدات معالجة رسومات NVIDIA L40S اعتبارًا من 1 مايو 2024. هذه تفاصيل مفيدة. كما تخبر المشتري أن السعة ليست مجردة: يتم تقديمها من قبل عائلات أجهزة معينة بمخزون محدود.

الخوادم المخصصة توضح النقطة. يصفتوثيق Bare Metalخوادم مادية مخصصة متصلة بتخزين كتل موزع، وشرائح Cisco UCS، وتخزين IBM Spectrum Virtualize، ووضع منطقة التوفر، والوصول إلى وحدة التحكم بنمط KVM، ورسم خرائط ISO، وعمليات الطاقة، ووضع علامات VLAN، وواجهتي شبكة تعتمد سرعتهما على فئة الشريحة. المنتج جذاب لأنه يمنح العملاء مزيدًا من التحكم في بيئة التشغيل. لكن هذا التحكم يدفع بعض المخاطر إلى العميل. إذا قام العميل بتثبيت برنامج المراقبة الافتراضية أو نظام التشغيل الخاص به، يمكن لـ Cloud Temple توفير الشريحة والتخزين والوصول إلى المنصة، لكن العميل لا يزال يمتلك الخيارات التي تحول الأجهزة إلى تطبيق مرن.

جانب VMware لديه توتر مماثل. تصف مواد VMware IaaS لـ Cloud Temple موارد شريحة وتخزين وشبكة مخصصة، وتوافق vSphere، وشبكات VLAN من الطبقة 2، والانتشار بين مناطق التوفر، ووقت استجابة داخل منطقة التوفر أقل من 3 مللي ثانية وبين مناطق التوفر أقل من 5 مللي ثانية في العرض الموثق، وتوفر عالٍ يعمل فقط إذا كان للعنقود تصميم المضيف المطلوب. تشير الوثائق العامة إلى أنه إذا كانت منطقة التوفر تحتوي على مراقب افتراضي واحد فقط، فإن إعادة التشغيل التلقائي على مراقب افتراضي آخر غير ممكن. هذا هو نوع الجملة الذي يحول وعد السحابة إلى واقع هندسي.

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

التخزين يحتاج أيضًا إلى دقة. تقول صفحةالتخزين الكائنيالعامة لـ Cloud Temple أن الخدمة مبنية على Dell Elastic Cloud Storage، وتقدم توافقًا عاليًا مع S3، وهي مؤهلة من SecNumCloud، ومعتمدة من HDS و ISO 27001، وتنسخ تلقائيًا عبر ثلاث مناطق توفر، وتستخدم تشفير محو EC 12+4، وتدعم TLS 1.2/1.3 بالإضافة إلى خيارات تشفير من جانب الخادم، وتدرج توفرًا بنسبة 99.99 في المائة ومتانة بنسبة 99.999999999 في المائة، وتعلن عن عدم وجود رسوم خروج. هذه ادعاءات جادة لمشتري التخزين الاحتياطي والأرشيف والتطبيقات. لا تزال بحاجة إلى أن تُرسم على واجب العميل في تعيين دورة الحياة، وعدم القابلية للتغيير، وسياسة المفاتيح والاستعادة. يساعد التخزين الكائني عبر ثلاث مناطق في متانة المنصة؛ لا يثبت بحد ذاته أن العميل يمكنه استعادة إصدار الكائن الصحيح بعد هجوم الفدية، أو الحذف الخاطئ، أو تصميم الاحتفاظ السيئ، أو اختراق مفتاح الوصول.

تقسيم المسؤولية ليس مخفيًا. صفحةالمسؤولية المشتركةلـ Cloud Temple توجّه القراء إلى مصفوفات RACI لـ IaaS و VM Instances والتخزين الكائني والشبكة والخدمات الأخرى. تقولمصفوفة مسؤولية IaaSأن Cloud Temple مسؤولة ومحاسبة عن تنفيذ مراكز البيانات المادية، والبنية التحتية للحوسبة، والبنية التحتية للتخزين، والاتصال الخلفي، وتراخيص برامج المنصة الأساسية، والتكوين الأساسي للمستأجر، وإعداد النسخ الاحتياطي الأولي. وتقول أيضًا أن العميل مسؤول ومحاسب عن تحديد البنية العامة، وعدد المستأجرين، وعدد مناطق التوفر، واستراتيجية الاستمرارية والاسترداد، وتحديد حجم الحوسبة والتخزين والشبكة والنسخ الاحتياطي، وإنشاء وصيانة الأجهزة الافتراضية، وربط كل جهاز افتراضي بخطط احتياطية واسترداد متماسكة، وإجراء اختبارات احتياطية واسترداد دورية.

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

السؤال هو "أي جزء من نظام العميل هذا يقع داخل محيط مسؤولية Cloud Temple، وأي جزء لا يزال تصميم العميل الخاص؟"

يظهر نفس التقسيم في الشبكات. يقولتوثيق الشبكة الخلفية الخاصةلـ Cloud Temple أن المنتج يوفر شبكات خاصة L2 VPLS عبر مناطق التوفر، ومكونات وصول خاص إلى الإنترنت، وعنونة IP، وحماية أصلية ضد هجمات DDoS، ومنافذ للاتصال الخارجي، ودوائر 1G/10G وروابط خاصة على مسارين بصريين متنوعين لمنتجات الدوائر المخصصة. تقول صفحةمفاهيم الإنترنتأن Cloud Temple تشغل AS الخاصة بها، وتقدم مسارين للعبور ونقطتي تبادل في باريس، وتدعم BGP4، وتوفر IPv4 عام بوحدة وبادئات IPv6، وتحتفظ بعرض نطاق الإنترنت بزيادات 100 ميجابت/ثانية، وتفرض رسومًا على أساس المئوي 95 بدلاً من حجم الخروج. هذه حقائق مادية لتصميم الشبكة، وليست ادعاءات تزيينية.

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

تدعم أدلة التوجيه العامة فكرة أن الشركة تدير شبكة حقيقية. RIPE RDAP لـAS33930يسمي CLOUD-TEMPLE ويسرد Cloud Temple SAS ككيان مسجل، مع عنوان المؤسسة في Le Belvedere, 1 Cours Valmy, 92800 Puteaux. نظرة عامة على AS من RIPEstatAS overviewحددت الحامل كـ CLOUD-TEMPLE Cloud Temple SAS وأظهرت AS كمنشور في وقت الاستعلام في 12 يوليو 2026. عرض البادئات المُعلن عنها من RIPEstatannounced-prefixes viewأظهر ثمانية إعلانات نشطة في النافذة المنتهية في 12 يوليو 2026: 91.223.207.0/24، 45.15.212.0/22، 185.56.204.0/22، 194.6.240.0/24، 93.187.40.0/21، 80.75.152.0/21، 2a02:668::/36 و 2a02:668:9000::/36.

سجل التوجيه هذا أقوى من بصمة تسويقية فقط. عرض حالة التوجيه من RIPEstatrouting-status viewأظهر ست بادئات IPv4، بادئتي IPv6، 6,656 عنوان IPv4 معلن، 8,192 IPv6 /48s، 54 جارًا ملاحظًا، ورؤية RIS شبه كاملة في اللقطة المفحوصة. عرض تناسق التوجيه من RIPEstat أظهر بادئات AS33930 المعلنة موجودة في كل من BGP ومصادر سياسة مسار RIPE، مع عدم وجود قائمة بادئات غير متناسقة في المخرجات المفحوصة. عاد التحقق من RPKI بـ "صالح" لأزواج الأصل البادئة AS33930 الثمانية المفحوصة. هذه الحقائق لا تخبر العميل بمدى تكرار خدمة معينة، لكنها تظهر أن طبقة الشبكة مرئية ومصانة وليست مجرد بقايا قديمة.

أدلة العبور والربط مفيدة أيضًا، وإن كان يجب قراءتها بعناية. تذكر ملاحظات RIPE RDAP لـ AS33930 طلبات الربط، وتفاصيل تبادل France-IX و Equinix Paris. صفحة شبكة Cloud Temple على PeeringDBCloud Temple network pageتسمي الشبكة كـ Cloud Temple، مع الاسم القديم لـ Cloud Temple aka Intrinsec، وسياسة ربط عامة مفتوحة، وتاريخ تحديث في أبريل 2025. يظهر عرض التبادل العام لـ PeeringDB إدخالات France-IX Paris و Equinix Paris IX بسعة 10 جيجابت/ثانية، بينما يظهر عرض المرافق Telehouse Paris 2 و Telehouse Paris 3 و Equinix PA6 و Digital Realty Paris PAR7 و DATA4 Paris Marcoussis - PAR1 كمرافق مرتبطة بملف الشبكة. هذا يؤكد الربط في سوق باريس، لكنه لا يزال ملف ربط عام، وليس خريطة ملزمة لوضع عبء عمل العميل.

صفحة الحالة العامة تضيف زاوية أخرى. صفحة الحالة لـ Cloud Templestatus pageتكشف عن مكونات تحت FR1، بما في ذلك تسميات AZ مثل PA6 و PAR7 و TH3 و PAR7S و TH3S و AZ07، بالإضافة إلى فئات لـ OpenIaaS و Object Storage و PaaS OpenShift و Bare Metal و VPC وخدمات الحافة والواجهات العامة. صفحة الحالة قيّمة لأنها تعطي العملاء مكانًا عامًا لملاحظة الحوادث والصيانة. لكنها لا تجيب على السؤال الأعمق بمفردها: أي من مناطق التوفر والخدمات والمكونات هذه يستخدمها العميل بالفعل، وهل ينجو تطبيق العميل الخاص إذا تدهورت إحداها؟

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

يعني أن عقد السحابة يحتاج إلى أن يُقرأ كبنية تحتية، وليس كتجريد سحري.

شروط الدعم جزء من تلك البنية التحتية. تسرد صفحةمستويات الدعملـ Cloud Temple الدعم Standard و Premium و Company بمعدلات شهرية تبلغ 5 و 7 و 10 في المائة من فاتورة الخدمة، ومستويات فاتورة شهرية دنيا، ووصول مختلف لمدير الحساب الفني، وأهداف استجابة P1 تبلغ ساعتين و 30 دقيقة و 15 دقيقة، ومراقبة وتدخل على مدار الساعة طوال أيام الأسبوع لحوادث السحابة. وتقول أيضًا أن المهندسين متاحون على مدار الساعة طوال أيام الأسبوع لحوادث السحابة، بينما طلبات الدعم لها قنوات ساعات العمل، مع دعم في فرنسا بالفرنسية والإنجليزية. الفرق مهم. حادث إنتاج تكون Cloud Temple مسؤولة عنه ليس هو نفسه طلب مساعدة عامة، أو تغيير تكوين من جانب العميل، أو سؤال تخطيط ترحيل، أو طلب لمهمة غير مدرجة في الكتالوج.

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

وثائق SLA المنشورة توضح نفس النقطة بالأرقام. يُعرّفSLA VM Instancesالتزامًا شهريًا بتوفر بنسبة 99.95 في المائة لكل VM Instance نشط ومفوتر، أي ما يعادل 21.9 دقيقة من عدم التوفر الشهري المسموح به. لكنه يقيس عدم التوفر على طبقة البنية التحتية الأساسية لـ Cloud Temple، ويستثني نظام تشغيل الضيف، وبرامج العميل، وتكوين شبكة العميل، وأعطال التطبيق، والصيانة المجدولة، ومكونات الإدارة المفقودة، والسلوك المسيء، والقوة القاهرة، ويتطلب تذكرة دعم في غضون 30 يومًا تقويميًا للمطالبة برصيد الخدمة. هذا هيكل سحابي عادي. إنه أيضًا تحذير: SLA ليس ضمانًا لوقت تشغيل التطبيق.

SLA VPCمحدد بالمثل. يعطي توفرًا شهريًا بنسبة 99.99 في المائة لمستوى بيانات VPC و 99.9 في المائة لمستوى التحكم، مع خمس دقائق كحد أدنى لعدم التوفر المُحتسب. يغطي مكونات VPC المُدارة من Cloud Temple مثل الموجه والشبكات الخاصة والبوابة الخارجية و NAT و DNAT و IPs العائمة. يستثني قواعد تصفية العميل والعنونة السيئة وأعطال الحوسبة المتصلة والاتصال الخارجي بالإنترنت خارج نقطة فصل Cloud Temple والصيانة المجدولة والسلوك المسيء والقوة القاهرة. هذه الاستثناءات ليست فشلًا في الوثيقة؛ إنها كيف يتم رسم حدود التشغيل الحقيقية.

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

الترحيل هو المكان الذي تكشف فيه السعة المستضافة غالبًا عن تكلفتها الحقيقية. منتجات Cloud Temple متوافقة صراحة مع الأنظمة البيئية المألوفة: عقارات VMware، ووصول S3، و OpenSource IaaS بنمط OpenStack، والتشغيل عبر API، والتزويد عبر Terraform، و BGP لبادئات العميل. هذه إشارات قابلية التشغيل البيني. تقلل من الاحتكار مقارنة بمجموعة تقنية مغلقة ومملوكة. لكن الخروج من المنصة لا يزال مشروعًا: صور الخادم، وأحجام التخزين، وحاويات الكائنات، وقواعد جدار الحماية، وحقوق الوصول، والتوجيه، والمفاتيح، و DNS، والمراقبة، واتفاقيات الدعم، ونوافذ التراجع، كلها يجب أن تتناسق.

يقول RACI لـ IaaS أن العميل مسؤول عن تخطيط قابلية العكس، واختيار البنية التحتية المستهدفة، وتنفيذ عمليات الانتقال، وإدارة تأثيرات جودة الخدمة أثناء النقل، بينما تتولى Cloud Temple تفكيك التكوينات والمحو الآمن بعد انتهاء العقد.

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

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

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

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

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

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

هناك أيضًا تبعية هادئة في الحافة العامة للمزود نفسه. أظهر بحث DNS في نقطة زمنية cloud-temple.com على مساحة عنوان Cloud Temple، وخوادم أسماء Gandi، وحماية بريد Microsoft، ووحدة التحكم على عنوان Cloud Temple آخر، واسم مضيف الحالة عبر Atlassian Statuspage و CloudFront. هذه خيارات عادية، ولا تضعف أدلة المنصة الأساسية. لكنها تظهر أن اتصال العميل قد يعتمد على طبقات تتجاوز AS33930. في حادث خطير، يمكن أن يفشل موقع المزود الإلكتروني ووحدة التحكم وصفحة الحالة ومسار البريد ودعم الهاتف ومستأجر العميل أو ينجو في مجموعات مختلفة. يجب على العملاء الاحتفاظ بأكثر من قناة تصعيد وألا ينتظروا حتى انقطاع التيار لاختبارها.

الفئة العالمية المخصصة لهذه المقالة تحتاج أيضًا إلى دقة. يمكن شراء الخدمات السحابية والوصول إليها عالميًا، و AS33930 لديه رؤية توجيه عالمية. لكن قصة السيادة العامة لـ Cloud Temple هي فرنسية وأوروبية بشكل أساسي، مع لغة منتج FR1، ومكاتب فرنسية، وفرق دعم فرنسية، وشهادة ANSSI، وملاءمة HDS، وربط باريس، وإشارات سوق المنشآت الفرنسية. بالنسبة لعميل خارج فرنسا، قد لا يزال الاعتماد جذابًا إذا كان الهدف هو موقع البيانات الفرنسي أو الأوروبي. يعني أيضًا أن زمن الوصول ودوائر وصول العميل والتوقعات القانونية وساعات الدعم التشغيلية يجب تقييمها مقابل قاعدة المستخدمين الحقيقية.

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

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

أنظف سؤال شراء هو إذن جدول نقاط فصل، وليس سؤال ثقة بنعم أو لا. لكل عبء عمل، يجب على العميل كتابة خدمة الحوسبة، وخدمة التخزين، وخدمة الشبكة، ومناطق التوفر، وهدف النسخ الاحتياطي، ومالك الاستعادة، ومستوى الدعم، ودائرة العميل، والبادئة العامة، ومسؤول الهوية، ومالك المفتاح، ومالك الفوترة، وجهة اتصال الصيانة، ووجهة الخروج. ثم يجب أن يطلب من TEMPLE Cloud Temple SAS تأكيد أي العناصر يديرها المزود، وأيها يديرها العميل، وأيها ضمن نطاق SecNumCloud، وأيها ذو صلة بـ HDS، وأيها خارج المناطق المؤهلة، وأيها في المعاينة، وأيها يحتاج إلى مساعدة مهنية منفصلة. هذا التمرين عادي، لكنه المكان الذي تصبح فيه مرونة السحابة مرئية.

الاستضافة المادية هي التذكير الأكثر واقعية بأن السحابة لها حواف. يصفتوثيق Housingلـ Cloud Temple الاستضافة المادية بوحدة رف في أرفف مشتركة أو برف مخصص 42U، وسلسلتين كهربائيتين للأرفف المشتركة، وحدود طاقة لكل وحدة، ووحدات 2U موجهة للخوادم مع طاقة C19، وأرفف مخصصة بقدرة 3 كيلوواط عبر سلسلتين كهربائيتين 16A، وزيادات إضافية بقدرة 2 كيلوواط، وكتلة أجهزة قصوى تبلغ 1000 كجم، ووحدات PDU مراقبة، ومنافذ شبكة نحاسية أو ألياف بصرية، واتصال غرفة لقاء الاجتماع، وخدمات الأيدي والعيون. ويقول أيضًا أن الأرفف المخصصة موجودة في مساحة استضافة مشتركة خارج منطقة SecNumCloud. هذا التمييز الأخير مهم: "استضافة Cloud Temple" و "IaaS Secure Temple المؤهلة" ليسا عبارتين قابلتين للتبادل.

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

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

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

يجب على العميل أن يسأل أين تقع كل نسخة من البيانات، والنسخ الاحتياطي، وتدفق السجلات، وأداة الدعم، وتدخل الدعم.

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

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

السؤال هو "هل يتطابق تصميم الخدمة المختار مع الضرر التشغيلي إذا توقف هذا التطبيق؟"

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

يجب على العميل تحويل الأدلة العامة إلى مراجعة تصميم خاصة بعبء العمل.

مسار الفشل الأكثر استحقاقًا للاختبار هو المسار المركب: حادث يعبر البنية التحتية للمزود، وتكوين العميل، وعملية الدعم. تخيل عميلًا يدير VMware IaaS عبر منطقتي توفر مع زوج جدار حماية، ونسخ احتياطية S3، وبادئة مملوكة للعميل، ومسار ألياف في الموقع، ومستوى دعم Premium. إذا تدهورت إحدى المناطق، قد يعتمد التطبيق على تكوين التوفر العالي، ونسخ التخزين، وحالة جدار الحماية، وسلوك DNS، وتقارب المسار، وتوفر S3، وتذكرة مصنفة بشكل صحيح. إذا كانت دائرة الناقل الخاصة بالعميل تواجه مشكلة أيضًا، قد لا تكون الشبكة الخلفية لـ Cloud Temple هي عنق الزجاجة.

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

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

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

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

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

يجب أن تكون درجة الأدلة لـ TEMPLE Cloud Temple SAS إذن أفضل من تحذير البصمة الرقيقة للتكليف، لكن لا تزال غير مطلقة. السجل العام واسع وحالي ومحدد: الصفحات الرسمية تحدد موقع القطاع المنظم، والمكاتب الفرنسية، ونطاق SecNumCloud و HDS، وعائلات المنتجات، ومستويات الدعم، وهندسة التخزين الكائني، وتصميم الشبكة الخلفية الخاصة، وشروط SLA لـ VPC و VM، والحدود المادية للاستضافة، وتوجيه AS33930، وصلاحية RPKI، ونقاط التبادل، ومكونات الحالة العامة. هذه بصمة كبيرة.

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

بالنسبة للمشترين، الاستنتاج العملي هو التعامل مع TEMPLE Cloud Temple SAS كاعتماد سحابي سيادي موثوق لا يزال يحتاج إلى دليل على مستوى عبء العمل. اطلب رسمًا بيانيًا يسمي المنطقة، ومناطق التوفر، ومضيفات الحوسبة أو فئاتها، وفئات التخزين، وحاويات S3، وسياسات النسخ الاحتياطي، وبوابات VPC، ومخارج الإنترنت، ودوائر العميل، وجهات اتصال الدعم، ومسارات التصعيد. اسأل أي الالتزامات مغطاة بنطاق SecNumCloud، وأيها HDS، وأيها استضافة عادية، وأيها في المعاينة، وأيها مملوك للعميل. اسأل كيف يتم المطالبة بأرصدة الخدمة وما لا تغطيه. اسأل كيف يغادر عبء العمل، وكيف يتم مسح البيانات، وكيف يتم التعامل مع المفاتيح، وكيف يتصرف الدعم خارج ساعات العمل.

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