Centre of server systems Ltd تبيع سعة مستضافة لا تزال تعتمد على الرفوف والنقل ونوافذ الإصلاح

ملخص

• تمتلك شركة Centre of server systems Ltd هوية إنترنت قابلة للتحقق: تسجل RIPE RDAP نظام AS201009 باسم SUPPORTIT-AS للشركة، ويظهر RIPEstat أن النظام أُعلن في 14 يوليو 2026، والمساحة المعلنة المرئية هي البادئة الروسية IPv4 109.248.237.0/24.
• تصف صفحات الدعم الخاصة بالشركة فيhttps://supportit.ru/وhttps://supportit.ru/%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3-%D0%B8-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2.htmlإدارة الخوادم والشبكات، وإدارة قواعد البيانات، والاستضافة، ووضع الخوادم، ورفوف خاصة في مركز بيانات من المستوى الثالث، وقنوات عالية السرعة ومراقبة على مدار الساعة، ولكن صفحة الاستضافة الثابتة آخر تعديل لها في 2015 ويجب التعامل معها كادعاء عام قديم وليس كتدقيق حالي للسعة.
• أدلة التوجيه العامة أقوى من الأدلة التجارية العامة. أبلغ RIPEstat عن بادئة IPv4 واحدة، وعدم وجود بادئات IPv6، ورؤية 325 من 326 من أقران RIS IPv4 للمسار، وجاران مرصودان، وحالة RPKI غير معروفة للبادئة 109.248.237.0/24، في حين لم يسجل PeeringDB أي سجلات تبادل أو مرافق للنظام.
• درجة الأدلة هي متوسطة لهوية الشبكة ورؤية المسار الحالية، لكنها ضعيفة لسعة الاستضافة، ومرونة المنشأة، والطاقة، والأجهزة الاحتياطية، ومحلية البيانات إلى ما هو أبعد من إشارات موسكو/روسيا، واستعادة العملاء. يجب على أي مشغل تابع التحقق من مكان وجود خدمته، وكيفية توجيهها، وكيفية نسخها احتياطيًا، وماذا يحدث عند فشل رف أو مزود تصاعدي أو مكتب دعم أو نافذة إصلاح.

الشركة مرئية، لكن السعة غير مرئية بنفس الطريقة

تظهر شركة Centre of server systems Ltd في سجلات البنية التحتية العامة كمنظمة وراء SUPPORTIT-AS. سجل RDAP الخاص بـ RIPE علىhttps://rdap.db.ripe.net/autnum/201009يسمي AS201009 باسم SUPPORTIT-AS، ويشير إلى أنه نشط، ويربطه بشركة Centre of server systems Ltd. سجل المنظمة علىhttps://rdap.db.ripe.net/الكيان/ORG-COSS2-RIPEيعطي نفس اسم الشركة وعنوانًا في موسكو. سجل شبكة IPv4 المعينة علىhttps://rdap.db.ripe.net/ip/109.248.237.0/24يحدد 109.248.237.0 إلى 109.248.237.255 باسم SUPPORTIT-NET، البلد RU، مع ملاحظة تذكر Centre of server systems Ltd.

تقوم هذه السجلات بعمل حقيقي. فهي تفصل الشركة عن الفئة الشائعة من علامات الاستضافة التي لا تكون أكثر من واجهات متاجر إعادة بيع. يعني وجود AS مسجل وبادئة /24 موجهة أن المشغل لديه على الأقل هوية توجيه مرئية، وكتلة عنوان عامة، وعلاقة مع شبكات تصاعدية أو وسطاء توجيه. أبلغ ملخص AS الخاص بـ RIPEstat علىhttps://stat.ripe.net/data/as-overview/data.json?resource=AS201009عن النظام كما تم الإعلان عنه في وقت الاستعلام في 14 يوليو 2026. أظهرت نقطة نهاية البادئات المُعلنة علىhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201009109.248.237.0/24 كبادئة مرئية خلال فترة الأسبوعين المنتهية في نفس الوقت.

يوفر موقع الشركة العام القصة التجارية. تقدم الصفحة الرئيسية علىhttps://supportit.ru/Support IT كمزود لإدارة الأنظمة والشبكات، وإدارة قواعد البيانات، والاستضافة ووضع الخوادم، والدعم الفني. تصف الخوادم والشبكات كمنطقة مسؤولية لخدمة الإدارة الخاصة بها، وتذكر صيانة الأجهزة والبرامج، وتشخيص الأعطال، واختيار وشراء المعدات المتسامحة مع الأعطال، وأعمال الأمن والتدقيق. يذكر قسم قواعد البيانات Oracle وMS-SQL وMySQL وPostgreSQL. يقول قسم الدعم أن الدعم يعمل 24 ساعة يوميًا وأن الحوادث تتم معالجتها من خلال سجل حالة مستمر. ترتبط الصفحة بمدخل العملاء علىhttps://supportit.ru/otrs/customer.pl؛ أعادت رؤوس HTTP الخاصة بها صفحة تسجيل دخول عملاء OTRS أثناء هذه المراجعة.

ادعاء الاستضافة أكثر تحديدًا ولكنه أيضًا أقدم. يقول قسم الهبوط المكون من صفحة واحدة أن الشركة لديها رفوف خاصة في مركز بيانات من المستوى الثالث، وقنوات عالية السرعة، ومراقبة على مدار الساعة، ونهج فردي في التنسيب والخدمة، ورقما ترخيص اتصالات من عام 2015، وسعر شهري منخفض لخادم افتراضي وسعر شهري منخفض لخادم فعلي. صفحة ثابتة منفصلة علىhttps://supportit.ru/%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3-%D0%B8-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2.htmlتكرر الموضوع في هيكل موقع تقليدي: وضع الخوادم في رفوف خاصة في مركز بيانات من المستوى الثالث، وقنوات عالية السرعة، ومؤسسة استضافة مرنة، ومراقبة على مدار الساعة، ورقما ترخيص مؤرخين في 5 فبراير 2015. أظهرت رؤوس HTTP الخاصة بها طابعًا زمنيًا لآخر تعديل في 13 فبراير 2015.

يغير هذا الطابع الزمني القراءة. صفحة الاستضافة القديمة هي دليل مفيد على كيفية رغبة الشركة في وضع بنيتها التحتية عند بناء الموقع. إنها ليست دليلاً حاليًا على وجود نفس الرفوف، أو درجة المنشأة، أو تغطية المراقبة، أو حالة الترخيص، أو التسعير، أو الأجهزة الاحتياطية، أو مخزون العملاء في يوليو 2026. صفحة الفهرس الأحدث علىhttps://supportit.ru/index.htmlآخر تعديل لها في مارس 2019 وما زالت تعرض نفس قائمة الخدمات، لكنها تترك القارئ أيضًا بدون مخزون منتجات حالي، أو صفحة حالة عامة، أو سجل حوادث مؤرخ، أو اسم مركز بيانات، أو عنوان منشأة، أو مخطط شبكة، أو سياسة نسخ احتياطي، أو مقاييس تغطية الدعم.

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

الأصل صغير وملموس ومركزه موسكو

الأصل الأكثر واقعية في السجل العام هو بادئة IPv4 /24 واحدة. ملخص البادئة من RIPEstat علىhttps://stat.ripe.net/data/prefix-overview/data.json?resource=109.248.237.0/24أبلغ عن 109.248.237.0/24 كما أعلنتها AS201009، الحامل SUPPORTIT-AS Centre of server systems Ltd. نقطة نهاية حالة التوجيه من RIPEstat علىhttps://stat.ripe.net/data/routing-status/data.json?resource=AS201009أبلغت عن بادئة IPv4 واحدة، 256 عنوان IPv4، صفر بادئات IPv6، صفر مساحة IPv6، جاران مرصودان، ورؤية من 325 من 326 من أقران RIS IPv4 في وقت الاستعلام في 14 يوليو 2026. هذه إشارة رؤية مسار صحية لبادئة واحدة. وهي أيضًا بصمة ضيقة.

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

أدلة DNS تجعل البصمة أكثر واقعية. نقطة نهاية سلسلة DNS من RIPEstat لـhttps://stat.ripe.net/data/dns-chain/data.json?resource=supportit.ruأظهرت supportit.ru يحل إلى 109.248.237.96، مع خوادم أسماء موثوقة cns1.supportit.ru و cns2.supportit.ru و cns3.supportit.ru. استعلام cns1 علىhttps://stat.ripe.net/data/dns-chain/data.json?resource=cns1.supportit.ruأظهر cns1.supportit.ru يحل إلى 109.248.237.69. استعلام مضيف دعم OTRS علىhttps://stat.ripe.net/data/dns-chain/data.json?resource=otrs.supportit.ruأظهر otrs.supportit.ru يحل إلى 109.248.237.87. أعادت فحوصات DNS المحلية أيضًا سجل A لـ supportit.ru بقيمة 109.248.237.96، وعدم وجود سجل AAAA، وخوادم أسماء Support IT داخل نفس النطاق، ومبادلات بريد Google للبريد الإلكتروني.

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

تشير إشارة الموقع الجغرافي أيضًا إلى روسيا، وتحديدًا موسكو، لكنها ليست تدقيقًا للمنشأة. نقطة نهاية الموقع الجغرافي من RIPEstat علىhttps://stat.ripe.net/data/geoloc/data.json?resource=109.248.237.0/24وعرض MaxMind علىhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=109.248.237.0/24كلاهما حددا البادئة في موسكو، روسيا. صفحة IPinfo غير الموثقة لـhttps://ipinfo.io/109.248.237.96حددت أيضًا AS201009 Centre of server systems Ltd وموسكو. هذه إشارات محلية مفيدة لمكان ظهور حركة المرور والبنية التحتية المسجلة. إنها لا تثبت الطابق الفعلي، أو القفص، أو الخزانة، أو مصدر الطاقة، أو موقع النسخ الاحتياطي لأي عبء عمل عميل.

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

وعد الاستضافة من الطرف الأول قديم بما يكفي لتتطلب تخفيض الدرجة

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

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

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

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

صفحات شعارات العملاء تتطلب مزيدًا من الحذر. الصفحة الرئيسية وصفحة 'من نحن' علىhttps://supportit.ru/%D0%BE-%D0%BD%D0%B0%D1%81.htmlتعرضان معارض شعارات العملاء وتذكران أن هدف الشركة هو السماح للشركاء بالتركيز على الأعمال الأساسية بينما يتعامل الموظفون المحترفون مع خدمة البنية التحتية لتكنولوجيا المعلومات. هذا تحديد عام قيم. إنها ليست قائمة عملاء حاليين، ولا تأييد خدمة، ولا دليل على استضافة حية، ولا دليل على أن أي منظمة مسماة لا تزال تستخدم بنية Support IT التحتية. الاستنتاج الآمن الوحيد هو أن Support IT قد سوقت نفسها علنًا كشريك استضافة وتكنولوجيا معلومات خارجي للعملاء التجاريين.

صفحة الاتصال علىhttps://supportit.ru/%D0%BA%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D1%8B.htmlتقول أن الاتصال متاح 24 ساعة في اليوم، سبعة أيام في الأسبوع من خلال عدة طرق. أعادت نقطة نهاية OTRS رؤوس تسجيل دخول حية. هذا المزيج يدعم ادعاء سطح الدعم الحالي بقوة أكبر من نص الاستضافة لعام 2015. لكنه لا يثبت مستويات التوظيف، أو أوقات الاستجابة، أو سلطة التصعيد، أو مخزون استبدال الأجهزة، أو اتصالات الانقطاع، أو ما إذا كان نفس مكتب الدعم يغطي الخوادم المستضافة، أو تكنولوجيا المعلومات المكتبية، أو إدارة قواعد البيانات، أو حوادث الشبكة.

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

رؤية المسار قوية بما يكفي لإثبات قابلية الوصول، وليس المرونة

رؤية المسار الحالية لـ AS201009 أفضل من العديد من أسماء الاستضافة ذات البصمة الضعيفة. يظهر RIPEstat أنه مُعلن. تظهر نقطة نهاية البادئات المُعلنة 109.248.237.0/24 خلال فترة الأسبوعين الحالية. تظهر نقطة نهاية حالة التوجيه رؤية شبه كاملة لأقران RIS IPv4 في وقت الاستعلام. صفحة شبكة BGP Toolkit من Hurricane Electric علىhttps://bgp.he.net/net/109.248.237.0/24تسمي AS201009 كأصل وCentre of server systems Ltd كمسجل، وتدرج العديد من سجلات DNS داخل النطاق. يحدد BGP.tools علىhttps://bgp.tools/as/201009الشبكة على أنها نشطة، مع بادئة IPv4 واحدة، وعدم وجود بادئات IPv6، ومزودين تصاعديين وثلاثة أقران في منظوره.

هذه تأكيدات مفيدة. تظهر أن الشبكة ليست مسجلة فقط؛ بل يتم رؤيتها في بيانات التوجيه العامة. يظهر أقوى مسار حالي في RIPEstat أن البادئة /24 مرئية من جميع أقران RIS IPv4 تقريبًا. يظهر تاريخ المسار علىhttps://stat.ripe.net/data/routing-history/data.json?resource=AS201009109.248.237.0/24 كمسار أصلي طويل الأمد من 2015 حتى يوليو 2026، مع تاريخ قصير للمزيد من التحديدات في السنوات السابقة وخط زمني واحد غير ذي صلة لـ 46.8.152.0/24 في 2020. تاريخ المسار الطويل ليس مثل جودة الخدمة، لكنه يجعل الشبكة أقل زوالًا من نظام تم إنشاؤه حديثًا أو مرئي بشكل متقطع.

الحدود مهمة بنفس القدر. أبلغت نقطة نهاية جيران AS من RIPEstat علىhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201009عن جارين مرصودين في أحدث ملاحظة متاحة في 14 يوليو 2026: AS12695 و AS9002. أظهر عرض whois لـ RIPE علىhttps://stat.ripe.net/data/whois/data.json?resource=AS201009إدخالات استيراد وتصدير لـ AS12695 و AS57304، بينما وجدت نقطة نهاية تناسق التوجيه علىhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201009AS12695 في كل من BGP و whois، و AS57304 في whois ولكن ليس في BGP، و AS9002 في BGP ولكن ليس في whois. هذا التباين ليس خطيرًا بالضرورة، لكنه يخبر القارئ ألا يستنتج تصميم عبور موثق بالكامل من مصدر بيانات واحد.

RPKI هي نقطة مراقبة أخرى. أعادت نقطة نهاية التحقق من RPKI من RIPEstat علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201009&prefix=109.248.237.0/24حالة غير معروفة، مع عدم وجود ROAs مصادقة. غير معروف ليس غير صالح. يعني أن المسار لم يكن محميًا بواسطة ROA مصادقة في هذا المنظور. بالنسبة لشبكة استضافة صغيرة، تزيد حالة RPKI غير المعروفة من أهمية انضباط تصفية المسار، وكائنات IRR، وتكوين التصاعدي. إذا كان العميل يعتمد على استقرار قابلية الوصول إلى العنوان، فيجب أن يسأل عما إذا كان المزود يخطط لنشر ROAs وكيف يقوم المزودون التصاعديون بتصفية البادئة.

PeeringDB أيضًا قيد. يحتوي API الشبكة علىhttps://www.peeringdb.com/api/net?asn=201009على كائن شبكة Centre of server systems لـ AS201009، تم إنشاؤه في 2021 وتحديثه في 2022، لكنه يبلغ عن عدم وجود مستوى حركة مرور، ولا نطاق مفصح عنه، وعدد صفر من نقاط التبادل، وعدد صفر من المرافق، ولا موقع ويب، ولا زجاج مكبر، ولا خادم توجيه. أعادت نقطة نهاية netixlan علىhttps://www.peeringdb.com/api/netixlan?asn=201009مصفوفة بيانات فارغة. أعادت نقطة نهاية netfac علىhttps://www.peeringdb.com/api/netfac?net_id=26979أيضًا مصفوفة فارغة. هذا لا يعني أن الشركة لا تحتوي على منشأة أو لا يوجد ترابط؛ العديد من المشغلين لا يحتفظون بملفات تعريف PeeringDB كاملة. هذا يعني أن أدلة الترابط/المنشأة العامة ضعيفة.

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

بالنسبة للمشغل التابع، يجب أن تكون أسئلة المسار محددة. أي المزودين التصاعديين يحملون بادئة العميل اليوم؟ هل AS12695 و AS9002 كلاهما مستخدمان بنشاط لحركة مرور العميل، أم يظهر أحدهما فقط في بعض المسارات الملاحظة؟ هل AS57304 لا يزال مسارًا متعاقدًا عليه، أو إدخال whois تاريخي، أو علاقة غير مباشرة؟ هل يوجد كائن مسار لكل بادئة معلنة؟ هل سينشر المزود ROAs الخاصة بـ RPKI؟ هل يمكن الوصول إلى خدمات DNS والدعم والعملاء إذا فشلت المنشأة الرئيسية أو أحد المزودين التصاعديين؟ هذه ليست أسئلة أكاديمية. إنها تحدد ما إذا كانت البادئة /24 الموجهة هي منصة مرنة أو ببساطة كتلة عنوان صغيرة مع قابلية وصول عامة.

ادعاءات المنشأة والطاقة تقع وراء أضعف الأدلة العامة

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

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

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

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

يمكن أن تكون خطة الخادم المادي أو VPS الرخيصة مناسبة تمامًا للعديد من أعباء العمل؛ الخطر هو افتراض سعة احتياطية للمؤسسات من كتيب لا يظهرها.

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

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

محلية البيانات أوضح من قابلية نقل البيانات

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

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

سجلات MX من Google لـ supportit.ru لا تعني أن بيانات العميل مخزنة في Google، لكنها تظهر أن مسار بريد النطاق الخاص بالمزود على الأقل يستخدم مبادلات بريد مستضافة من Google. مدخل عملاء OTRS يقع على نطاق العناوين الخاص بالمزود. خوادم أسماء DNS تحت supportit.ru وتحل إلى نفس البادئة /24. هذا الخليط عادي، لكنه يظهر لماذا محلية البيانات ليست كائنًا واحدًا. يمكن أن يكون للبريد الإلكتروني، والتذاكر، والنسخ الاحتياطي، وDNS، والمراقبة، والخوادم المستضافة كل منها موقع مختلف وتعرض قانوني.

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

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

النقطة الأوسع هي أن الاعتماد على الخدمات السحابية ليس فقط اعتمادًا على الحوسبة. إنه الهوية، DNS، البريد، التذاكر، النسخ الاحتياطي، بيانات الاعتماد، الفواتير، التراخيص والدعم. تكشف Centre of server systems Ltd ما يكفي من البنية التحتية العامة لجعل تلك التبعيات مرئية. لا تكشف ما يكفي من السياسات العامة لجعلها آمنة بشكل افتراضي.

اقتصاديات الاستضافة تشرح كلاً من الجاذبية والمخاطر

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

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

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

عقار التوجيه العام يناسب هذا النموذج أيضًا. بادئة /24 واحدة كافية لمزود مركز يستضيف عملاء مختارين، وDNS، ومرحلات بريد، وبوابات، وأنظمة PBX، ومواقع ويب، ومضيفات إدارة. أظهرت علامة تبويب DNS من Hurricane Electric لـhttps://bgp.he.net/net/109.248.237.0/24العديد من ارتباطات PTR وسجل A عبر النطاق، بما في ذلك أسماء مضيفات المزود ونطاقات تشبه جهات خارجية. تشير سجلات DNS هذه إلى مساحة عنوان مأهولة، وليس تخصيصًا فارغًا. لا تثبت أي المضيفات هم عملاء حاليون، وأيها سجلات قديمة، وأيها خدمات داخلية، أو أيها لا يزال يحمل حركة مرور. DNS إشارة، وليس قائمة عملاء.

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

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

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

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

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

بالنسبة لـ Centre of server systems Ltd، يجعل السجل العام عدة اختبارات محددة معقولة. يجب على العميل تتبع IP المعين وتأكيد AS الأصلي الحالي. يجب أن يختبر ما إذا كانت cns1 وcns2 وcns3 تظل قابلة للوصول أثناء تغييرات DNS المحاكاة. يجب أن يسأل عما إذا كان عبء عمله على مضيف افتراضي أو خادم مادي، وما إذا كان مسار الاستبدال مختلفًا. يجب أن يطلب اسم مركز البيانات الحالي على الأقل بموجب NDA إذا كان الإفصاح العام غير ممكن. يجب أن يسأل عن كيفية توظيف الدعم خارج ساعات العمل وكيف يتم إبلاغ الحوادث إذا كان مضيف OTRS غير قابل للوصول.

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

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

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

ستتحسن الدرجة إذا نشرت الشركة صفحة بنية تحتية مؤرخة تشرح الخدمات الحالية، ومنطقة مركز البيانات، وما إذا كان ادعاء الرف من المستوى الثالث لا يزال ساريًا، والمزودين التصاعديين الحاليين، وساعات الدعم، ورؤية حالة الخدمة، وخيارات النسخ الاحتياطي، وخيارات تصدير العملاء، واتصالات الحوادث. ستتحسن إذا كان لدى AS201009 ROAs حاليين لـ RPKI لـ 109.248.237.0/24. ستتحسن إذا أظهر PeeringDB أو سجل ترابط عام آخر مشاركة حالية في المنشأة والتبادل. ستتحسن إذا نشرت الشركة صفحة حالة مواجهة للعملاء خارج نفس مجال الفشل مثل الخدمات المستضافة.

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

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

الخلاصة للمشغلين التابعين

يجب قراءة Centre of server systems Ltd كشركة بنية تحتية حقيقية وصغيرة مع مسار عام نشط متمركز حول موسكو وسطح خدمة Support IT الذي ظل متصلاً. أدلتها أقوى من دليل اختصار وأضعف من منصة استضافة موثقة بالكامل. الشركة لديها AS قابل للملاحظة، و /24 مرئي، ونقاط نهاية ويب ودعم تابعة لها تعمل، وادعاءات قديمة لكن محددة حول الرفوف والاستضافة والمراقبة. ليس لديها دليل عام على السعة الحالية، أو عدد الرفوف، أو تصميم الطاقة، أو تنوع المسار، أو حماية RPKI، أو سياسة النسخ الاحتياطي، أو مخزون العملاء الحي، أو الاسترداد المختبر.

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

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

الدرس أوسع من شركة واحدة. تعود السعة المستضافة دائمًا إلى الأنظمة المادية: الرفوف، الطاقة، الكابلات، أجهزة التوجيه، العناوين، DNS، موظفو الدعم، قطع الغيار ونوافذ الإصلاح. تظهر Centre of server systems Ltd تلك الطبقات بشكل مصغر. المسار حقيقي. ادعاء الاستضافة القديم محدد. الجزء المفقود هو الدليل الحالي على أن الطبقات المادية والتشغيلية وراء الادعاء لا تزال بحجم كافٍ وموظفة ومكررة بما يكفي للاعتماد الذي يريد العميل وضعه عليها.