CLOUD Asre Dadeha Asiatech: سعة مستضافة لا تزال تعتمد على الرفوف وخدمات الترانزيت ونوافذ الإصلاح

ملخص

• يمنح Cloud.ir لـ CLOUD Asre Dadeha Asiatech واجهة بيع بالتجزئة حقيقية: يقدم الموقع خوادم سحابية، خطط VPS، تخزين سحابي، CDN، تحويل سحابي، خدمات مركز بيانات سحابي، لوحة تحكم للعملاء، أسعار منشورة واتفاقية مستوى خدمة، ويشير تذييل الصفحة إلى أن الموقع مملوك لـ Asre Dadeha Asiatech.
• الارتباط المادي أضيق من لغة المنتج. يشير Cloud.ir إلى أن بنيته التحتية تستند إلى مراكز بيانات ASIATECH في إيران، وتذكر صفحة "حول" أن Cloud.ir يعمل منذ العام الإيراني 1399 مع أكثر من 20 منتجًا سحابيًا، لكن الصفحات العامة لا تحدد الرف الدقيق، أو التوزيع حسب المدينة، أو طوبولوجيا الطاقة، أو نتائج اختبار الاستعادة لكل حمل عمل عميل.
• أدلة الشبكة قوية على مستوى التحكم. يقوم RIPE RDAP بتسمية AS60077 باسم AT-CLOUD لـ Asre Dadeha Asiatech، وأظهر RIPEstat 18 بادئة IPv4 و14,080 عنوان IPv4 معلنًا عنها عبر AS60077 في 12 يوليو 2026، وتطابق DNS لـcloud.irمع بادئة AS60077. أظهرت نفس رؤية RIPE جارًا يسارًا ملاحظًا لـ AS60077: AS43754، شركة ASIATECH Asiatech Data Transmission.
• لذا فإن سؤال الشراء ليس ما إذا كان المنتج السحابي موجودًا، بل ما إذا كان بإمكان عميل معين التحقق من التنسيب والسعة المتاحة والمسارات المستقلة وموقع النسخ الاحتياطي وتصعيد الدعم واستثناءات الصيانة واستمرارية الفوترة وحقوق الخروج قبل أن يحول الرف أو المنبع أو مخزون الأجهزة أو حدث حسابي الخادم الافتراضي إلى تبعية مادية.

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

Cloud.ir ليست صفحة علامة تجارية خاملة. تعرضالصفحة الرئيسية لـ Cloud.irخوادم سحابية، خدمات مركز بيانات سحابي، تحويل سحابي، CDN، تخزين سحابي، إدارة نطاق سحابي، صفحة أسعار الخدمات، صفحات دعم، ومسار تسجيل دخول العملاء. تحمل الصفحة نفسها رقم هاتف، بريد إلكتروني، عنوان مكتب في طهران، وإعلان في التذييل يفيد بأن الحقوق المادية والفكرية للموقع تعود لـ Asre Dadeha Asiatech. بالنسبة لهذا الملف الشخصي، هذا مهم لأن هوية الشركة مرتبطة بسطح خدمة نشط، وليس فقط بسجل توجيه.

تضيفصفحة "حول"تاريخًا للخدمة. تشير إلى أن Cloud.ir بدأ عملياته في العام الإيراني 1399 وأصبح أحد مزودي الخدمات السحابية الرائدين في إيران مع أكثر من 20 منتجًا سحابيًا. تشمل مجموعات المنتجات المذكورة توزيع المحتوى، الحوسبة السحابية، الأمان السحابي، التخزين السحابي، الشبكة السحابية، وسوق سحابية. هذه الادعاءات هي تصريحات من الشركة، وليست مقاييس مستقلة للسعة، لكنها توضح الموقف التجاري الأساسي: تبيع CLOUD Asre Dadeha Asiatech سعة مستضافة للعملاء الذين لا يريدون شراء وتشغيل بنيتهم التحتية المادية الخاصة.

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

صفحةالأسعارلـ Cloud.ir تجعل المنتج أكثر قابلية للفحص. تدرج أسماء حزم VPS مثل AT-VPS-B2 وAT-VPS-G1 وAT-VPS-A2 مع الذاكرة ووحدة المعالجة المركزية والقرص وعنوان IP مجاني وحركة المرور الأساسية ودعم IP إضافي ودعم إعادة البناء وIPv6 معروضة على بطاقات الحزمة. تظهر أيضًا تسعيرًا بالساعة لموارد الخادم السحابي مثل الذاكرة ووحدة المعالجة المركزية والقرص وIP وحركة المرور المستلمة ومستويات النسخ الاحتياطي. صفحات الأسعار ليست مخططات هندسية، لكنها تكشف كيف يتم تعبئة الخدمة: يشتري العميل وحدات محدودة من الحوسبة والتخزين والعنوان وحركة المرور التي يجب أن تكون موجودة في مكان ما قبل أن تتمكن لوحة التحكم من تخصيصها.

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

هذا هو الإطار المفيد لبقية المقال. CLOUD Asre Dadeha Asiatech ليست قشرة غامضة، لكن سطح الخدمة المرئي لا يلغي الحاجة لاختبار الطبقات السفلية. لا يمكن توفير خادم سحابي في ثوانٍ إلا إذا كان المزود يمتلك بالفعل سعة المضيف المناسبة والتخزين والعناوين العامة والاتصال بالشبكة وتفويض الفوترة. لا يمكن لـ CDN توجيه طلب إلى حافة أقرب إلا إذا كانت تلك الحافة موجودة ولديها محتوى محدث وسعة كافية من ذاكرة التخزين المؤقت والعبور، ولا يزال بإمكانها الوصول إلى الأصل عندما يفشل خادم العميل الخاص. النسخ الاحتياطي له قيمة فقط إذا كان يمكن استعادته خارج نطاق الفشل الذي ألحق الضرر بحمل العمل الأساسي.

تظهر الصفحات العامة العرض؛ لا تثبت بذاتها كل ادعاء بالمرونة يحتاجه مشتري الإنتاج.

الارتباط المادي هو سعة مراكز بيانات ASIATECH في إيران

أقوى تصريح مادي من Cloud.ir صريح: بنيته التحتية السحابية تستند إلى مراكز بيانات ASIATECH. تشيرصفحة الخادم السحابيإلى أن البنية التحتية لخدمات Cloud.ir السحابية منتشرة على مراكز بيانات ASIATECH، التي تصفها بأنها أكبر شبكة مراكز بيانات في إيران. تعدد استخدام التقنيات الحديثة، وشهادات ISO27001 وTIA-942 Tier 2 وTier 3، وأنظمة الأمان، والاتصال المستقر بالشبكة، واستهلاك النطاق الترددي العالي في إيران، ودعم الطاقة AC وDC. تكررصفحة مركز البيانات السحابينفس إطار مركز بيانات ASIATECH وتذكر أن مراكز بيانات Cloud.ir في جميع أنحاء إيران توفر البنية التحتية للعملاء الذين يبدأون الترحيل السحابي.

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

خارج صفحات الشركة، توفر السجلات العامة سياقًا أقدم لكنه مفيد لهذه المجموعة. أبلغت مراكز البيانات Dynamics في يوليو 2017 أن AsiaTech افتتحت مركز بيانات بمساحة 700 متر مربع في برج ميلاد غرب طهران. وصف التقرير AsiaTech بأنها شركة خاصة تأسست عام 2003، وأشار إلى أنها حصلت على ترخيص في 2013 للاستضافة والخوادم المخصصة والمشتركة والاستضافة المشاركة، وذكر أنها تدير خمسة مراكز بيانات وتربط أكثر من 430 مدينة في جميع أنحاء إيران. يدرج DataCenterMap حاليًا مركز بيانات Asiatech Milad Tower ومركز بيانات Asiatech Azadegan في طهران، بينما تشير صفحة مواصفات Milad Tower إلى أن Asiatech لم تقدم أي بيانات عن السعة أو الطاقة أو الامتثال أو الأمان أو المبنى.

يجب التعامل مع هذه المراجع الخارجية بحذر. إنها تؤكد أن ASIATECH كانت مرتبطة بمنشآت مسماة في طهران ونشاط أوسع لمراكز البيانات. لا تثبت أي منشأة تخدم جهازًا افتراضيًا معينًا لـ Cloud.ir، أو حافة CDN، أو حاوية تخزين، أو نسخة احتياطية في يوليو 2026. كما لا تثبت أن حالة المنشأة لعام 2017، أو عدد الرفوف، أو التصميم الكهربائي، أو عدد العملاء لا يزال دون تغيير. تاريخ المنشآت دليل مفيد على وجود شركة بنية تحتية حقيقية؛ إنها ليست خريطة تنسيب حالية.

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

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

AS60077 مرئي، والشبكة الأم هي التبعية الواضحة

يمنح سجل الشبكة CLOUD Asre Dadeha Asiatech ربطًا ماديًا ثانيًا. يحدد RIPE RDAPAS60077كـ AT-CLOUD ويربطه بـ Asre Dadeha Asiatech عبر ORG-ADA42-RIPE. يتضمن نفس رد RDAP جهات اتصال إدارية وفنية من NOC Asiatech في عنوان شارع Miremad في طهران، بالإضافة إلى دور إساءة الاستخدام لـ Asiatech. هذا دليل سجل على نظام مستقل حقيقي وسلسلة اتصال تشغيلية. لا يصف الخوادم الفردية أو العملاء أو التوفر، لكنه يؤكد أن الخدمة السحابية لها معرف شبكة خاص بها.

أفادنظرة AS العامة لـ AS60077من RIPEstat بأن الحامل هو "AT-CLOUD Asre Dadeha Asiatech" وأظهر أنه تم الإعلان عنه في وقت طلب 12 يوليو 2026. أظهرترؤية حالة التوجيه18 بادئة IPv4 و14,080 عنوان IPv4 مرئيًا من AS60077، مع أول ملاحظة بادئة في 2014 وآخر ملاحظة في وقت الطلب. أظهرت نفس رؤية RIPE رؤية عالية لمجمع IPv4 وعدم وجود مساحة IPv6 مرئية في رد الحالة هذا.

الخدمة النشطة تشير أيضًا إلى AS60077. أعادترؤية سلسلة DNS لـcloud.irمن RIPEstat193.151.157.174للاسم العلوي، ورؤية معلومات الشبكةلهذا العنوان خريطته إلى193.151.157.0/24وAS60077. هذا لا يثبت أن كل حمل عمل عميل يعمل داخل نفس البادئة؛ إنه يظهر أن الحضور العام للشركة على الويب يتم تقديمه من ASN السحابي.

التبعية تكمن في بيانات الجوار. أظهرترؤية جار ASN لـ AS60077من RIPEstat جارًا يسارًا ملاحظًا: AS43754. تسمينظرة AS العامة لـ AS43754من RIPEstat هذه الشبكة "ASIATECH Asiatech Data Transmission company." أظهرترؤية حالة التوجيهبصمة شبكة أوسع بكثير في نفس وقت الطلب: 316 بادئة IPv4، 209,920 عنوان IPv4، و86 جارًا ملاحظًا. الصورة مباشرة: ASN السحابي مرئي، لكن حدوده العليا العامة يبدو أنها شبكة ASIATECH الأكبر.

عينات من مرآة التوجيه تجعل العلاقة مرئية في المسارات الفعلية. تضمنتبيانات مرآة التوجيه لـ193.151.128.0/22، إحدى البادئات المعلنة لـ AS60077، مسارات تنتهي بـ AS43754 AS60077. أظهرت بعض العينات العالمية أيضًا مرتفعات أعلى قبل AS43754، لكن التبعية القريبة من المصدر بقيت AS43754. هذا ليس مفاجئًا لنشاط سحابي مرتبط بنفس مجموعة البنية التحتية للشركة، لكنه مهم لأن فشلًا على هذه الحدود يمكن أن يؤثر على العديد من الخدمات في وقت واحد.

هذا لا يعني أن AS60077 هش. علاقة منبع واحدة مرئية قد تكون معقولة تمامًا عندما يكون للشبكة الأم نطاق ناقل وانضباط تشغيلي وتكرار كافٍ في الخلفية. كما لا يعني أن AS43754 لديه مسار خارجي واحد فقط؛ أظهر RIPEstat العديد من الجيران لـ AS43754. النقطة المهمة أضيق: أدلة BGP العامة لا تثبت أن AS60077 نفسه لديه عدة مرتفعات مستقلة، أو مداخل مادية منفصلة، أو أجهزة توجيه حدودية منفصلة، أو تجاوز فشل مستقل خارج AS43754. يجب على العملاء التعامل مع AS43754 باعتبارها الحدود العليا التشغيلية المرئية ما لم تقدم Cloud.ir أدلة خاصة بالمنتج على فصل إضافي.

RPKI يجيب على سؤال مختلف. أعادالتحقق من صحة RPKI لـ193.151.128.0/22المنشأ من AS60077حالة صالحة مع أذونات أصل التوجيه التي تغطي AS60077. هذا نظافة توجيه إيجابية: إنه يدعم شرعية أصل التوجيه. لا يثبت سعة حركة المرور، أو تنوع المسار، أو استمرارية الطاقة، أو جودة عزل العميل، أو استعادة النسخ الاحتياطي، أو استجابة الدعم. يمكن سحب مسار صالح بـ RPKI عن طريق الخطأ، أو تصفيته من قبل منبع، أو عزله بسبب فشل تقاطع، أو جعله عديم الفائدة بسبب فشل من جانب الخادم.

السعة المركبة ليست نفس السعة السحابية القابلة للاستخدام

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

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

توفر أرقام الشبكة حدًا خارجيًا، وليس عدد خوادم. أظهرتقائمة البادئات المعلنة لـ AS6007718 بادئة IPv4 في فترة الطلب الأخيرة، بما في ذلك عدة نطاقات/22و/23و/24. عناوين IPv4 الـ 14,080 التي شوهدت في رؤية حالة التوجيه هي سعة عناوين عامة حقيقية، لكن العناوين لا تساوي الأجهزة الافتراضية. بعض العناوين تخدم أجهزة التوجيه وموازنات التحميل وجدران الحماية وخوادم الأسماء ومثيلات العملاء ووظائف الإدارة أو مجمعات الاحتياط. يمكن لخادم واحد استخدام عدة عناوين؛ يمكن للعديد من الخدمات أن تكون خلف عنوان واحد؛ يمكن أن تتعايش العناوين غير المستخدمة مع مجموع حوسبة كاملة.

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

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

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

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

اتفاقية مستوى الخدمة تضيق الوعد تحديدًا إلى النقاط التي سيختبرها الفشل

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

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

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

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

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

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

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

CDN والتخزين والتحويل السحابي يوسع نطاق التأثير بالإضافة إلى مجموعة الميزات

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

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

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

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

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

المحلية هي سمة منتج، وليست شعارًا

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

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

يمكن أن يكون الخط الإقليمي الخاص بـ Cloud.ir لملف شخصي موجه للمشتري عالميًا لأن إمكانية الوصول إلى IP عالمية ويمكن لعملاء السحابة أن يكونوا في أي مكان بحساب عامل ومسار شبكة. هذا يختلف عن القول بأن الشركة تدير مناطق عالمية. تشير أدلة المنتج العامة التي تم فحصها هنا بقوة إلى البنية التحتية الإيرانية وأسطول مراكز البيانات المحلية لـ ASIATECH. إذا كان العميل يحتاج خدمة إيرانية فقط، يجب أن يطلب بيانًا مكتوبًا عن محلية الحوسبة والتخزين والنسخ الاحتياطي والسجلات والوصول إلى الدعم. إذا كان العميل يحتاج استمرارية متعددة البلدان، يجب أن يسأل عما إذا كانت Cloud.ir نفسها توفر ذلك أم يجب على العميل بناؤها مع مزود آخر.

المحلية تغير أيضًا استجابة الحوادث. قد يفضل موقع محتوى إيراني محلي سلوك CDN المحلي لـ Cloud.ir ومنشآت ASIATECH لأن معظم المستخدمين قريبون من تلك المسارات. قد يقلق مزود SaaS دولي من الوصول إلى المدفوعات، والتعرض للعقوبات، وزمن انتقال المستخدمين الأجانب، وتصفية المسارات، وحل النزاعات، والقدرة على تصدير البيانات تحت الضغط. قد يقدر مستخدم قطاع عام أو منظم السيطرة المحلية على المنشآت لكنه يحتاج بيانًا أكثر صرامة حول من يمكنه الوصول إلى البيانات، وأين توجد اللقطات، وكيف يتم التعامل مع أوامر السلطات. يمكن أن تكون البنية التحتية نفسها مناسبة تمامًا لعميل وغير مناسبة لآخر.

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

مسارات الفشل الرئيسية تمر عبر الرف والمسار ومخزون الأجهزة وحالة الحساب والترحيل

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

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

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

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

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

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

ما يجب على المشتري التحقق منه قبل الاعتماد على Cloud.ir

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

المهمة الثانية هي تنوع الشبكة. AS60077 مرئي وشرعي، وAS43754 شبكة أم كبيرة. هذه نقطة بداية جيدة. هذا ليس نفس إثبات أن حركة مرور العميل يمكنها النجاة من حدث على حافة AS43754. اسأل عن المسار الطبيعي، والمسار الاحتياطي، وتصميم جهاز التوجيه الحدودي، وحد معالجة DDoS، وممارسات RPKI وتصفية المسار، وما إذا كانت Cloud.ir يمكنها الإعلان مؤقتًا عن بادئة عميل أو نقل عنوان عام أثناء حادث. لمعظم عملاء VPS، ستكون الإجابة لا، لكن السؤال يوضح التبعية.

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

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

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

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

الأطروحة التشغيلية: خدمة حقيقية، رؤية شبكة قوية، دليل مادي غير مكتمل

CLOUD Asre Dadeha Asiatech تستحق مستوى ثقة أعلى من شركة لديها فقط إدخال توجيه قديم. Cloud.ir نشط، كتالوج الخدمات محدد، صفحة الأسعار تكشف حزم موارد ملموسة، اتفاقية مستوى الخدمة عامة، وسجلات RIPE تضع AS60077 في جدول التوجيه العام كـ AT-CLOUD Asre Dadeha Asiatech. DNS لموقع الشركة يشير إلى AS60077. AS60077 لديه أسطول عناوين مرئي، وتبعته للشبكة الأم AS43754 قابلة للملاحظة بدلاً من أن تكون مخفية.

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

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

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