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 company.
• سؤال الشراء إذن ليس ما إذا كان المنتج السحابي موجودًا. بل هو ما إذا كان بإمكان عميل معين التحقق من التنسيب، والمساحة الرأسية، والمسارات المستقلة، ومحلية النسخ الاحتياطي، وتصعيد الدعم، واستثناءات الصيانة، واستمرارية الفوترة، وحقوق الخروج قبل أن يحول حدث رف أو موفر أو مخزون أجهزة أو حساب خادمًا افتراضيًا إلى تبعية مادية.

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

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 المستوى 2 والمستوى 3 وأنظمة الأمان واتصال شبكة مستقر واستهلاك نطاق ترددي عالٍ في إيران ودعم طاقة التيار المتردد والتيار المستمر. تكررصفحة مركز البيانات السحابينفس إطار مراكز بيانات ASIATECH وتقول إن مراكز بيانات Cloud.ir عبر إيران توفر البنية التحتية للعملاء الذين يبدؤون الهجرة السحابية.

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

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

يجب التعامل مع تلك المراجع الخارجية بحذر. تؤكد أن ASIATECH كانت مرتبطة بمرافق مسماة في طهران وأعمال أوسع لمراكز البيانات. لا تثبت أي مرفق يخدم جهاز VM معين من 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 جهات اتصال إدارية وتقنية لـ Asiatech NOC في عنوان شارع ميرعماد في طهران، بالإضافة إلى دور إساءة استخدام 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 الأكبر.

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

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

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

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

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

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

توفر الأرقام الشبكية حدًا خارجيًا، وليس عدد خوادم. أظهرقائمة البادئات المعلنة لـ AS60077من RIPEstat 18 بادئة 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 الأكثر احتمالاً الذي يجب أن يخطط له العميل ليس انقطاعًا كاملاً دراماتيكيًا. إنه فشل جزئي يقع بين الطبقات التعاقدية. قد يكون VM بخير بينما يكون مسار المنبع متدهورًا. قد يكون المسار بخير بينما ينهار أداء التخزين. قد يكون النسخ الاحتياطي موجودًا بينما يكون إنتاجية الاستعادة بطيئة جدًا. قد تجيب CDN على المحتوى الثابت بينما تفشل الوظائف الديناميكية. قد تكون لوحة تحكم العميل قابلة للوصول بينما يمنع الدفع إعادة البناء. هذه الحالات الوسطى هي حيث يتعلم العملاء ما إذا كانت الخدمة تحتوي على تفاصيل تشغيلية كافية خلفها.

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

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

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

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

مسار الترحيل هو شبكة الأمان النهائية. يمكن للعميل تحمل أدلة أضعف إذا كان يمكنهم المغادرة بسرعة. هذا يتطلب نسخ احتياطية حالية، أو صور أو ملفات قابلة للتصدير، أو إجراءات موثقة لتغيير IP وDNS، أو TTLs معروفة، أو وصول إلى الحساب يظل متاحًا أثناء نزاعات الفوترة، وسعة كافية لنقل البيانات. يتطلب أيضًا تجنب القفل الخفي: عناوين شبكة خاصة لا يمكن إعادة إنتاجها، أو ميزات تخزين بدون مسار تصدير، أو قواعد 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 والاستضافة المحلية ذات قيمة، لكن يجب على المشغل اختبار فشل الأصل وسلوك ذاكرة التخزين المؤقت وتصعيد الدعم قبل الإطلاق. بالنسبة للبيانات المنظمة أو عبر الحدود، الأسئلة الرئيسية هي المحلية، والتعرض للسلطة، والوصول إلى الدعم، وحقوق التصدير. بالنسبة لأي عميل إنتاج، الانضباط النهائي هو نفسه: اشتر الخدمة السحابية، لكن تدقق في الرف والمسار والإصلاح وقصة الترحيل خلفها.