Hosting Consulting, Inc تبيع سعة استضافة لا تزال تعتمد على الرفوف والعبور ونوافذ الإصلاح

ملخص

• ترتبط Hosting Consulting, Inc بـ AS30502 في سجلات الشبكة العامة. السؤال المفيد ليس ما إذا كان الاسم يظهر في السجل، بل ما إذا كان هذا السجل يُترجم إلى خدمة عملاء حية وقابلة للاسترداد في الولايات المتحدة.
• لم يُظهر RIPEstat أي بادئة مُعلنة حالية في هذا الفحص، حيث كان آخر رصد لـ RIPEstat للبادئة 208.91.206.0/23 بتاريخ 2013-06-07T08:00:00. هذا يعني أن الأدلة التاريخية أو أدلة السجلات لا ينبغي اعتبارها دليلاً على أحمال عمل مستضافة حالية.
• تقول أدلة الترابط: لم يتم العثور على ملف تعريف شبكة PeeringDB للاستعلام عن ASN. وتقول أدلة الجيران: لا يوجد جيران مرئيون حاليًا في عرض جيران RIPEstat. تساعد هذه السجلات في تحديد سطح التشغيل، لكنها لا تثبت تنوع المسارات الفيزيائية أو استقلالية الترانزيت التجاري.
• المخاطر التي تواجه العميل هي الفجوة بين السعة المسجلة والسعة القابلة للاستخدام. يمكن أن يفشل ASN الحي عبر رف واحد، أو مزود ترانزيت واحد، أو طابور أيدي عن بعد واحد، أو قفل فاتورة واحد، أو فخ ترحيل واحد؛ ويمكن تسويق ASN خامل بما يتجاوز ما يمكن أن تدعمه الأدلة العامة.
• درجة الأدلة ضعيفة. AS30502 له اسم استضافة معروف، ولكن لم تظهر أي بادئة عامة حالية في فحوصات RIPEstat المستخدمة هنا. أي مطالبة بخدمة حالية ستحتاج إلى دليل تشغيلي جديد.

فاتورة السحابة تصل في النهاية إلى مكان فيزيائي

أسهل طريقة لسوء فهم Hosting Consulting, Inc هي التوقف عند كلمة "سحابة". حساب السحابة أو الاستضافة هو غلاف تجاري حول المعالجات والذاكرة والتخزين وأجهزة التوجيه وموارد العناوين والوصول إلى المرافق والأشخاص الذين يمكنهم التدخل عندما يتعطل شيء ما. يُظهر جدول التوجيه العام فقط حافة مستوى التحكم لذلك الترتيب. لا يُظهر حامل الكابلات أو الخزانة المقفلة أو تغذية الطاقة أو الوحدة البصرية الاحتياطية أو المهندس الذي يمكنه دخول الموقع بعد منتصف الليل.

بالنسبة لـ Hosting Consulting, Inc، فإن إشارة المسار الحالية محدودة. لم يعثر الفحص على أي بادئة مُعلنة حالية، حيث كان آخر رصد لـ RIPEstat للبادئة 208.91.206.0/23 بتاريخ 2013-06-07T08:00:00. يجب التعامل مع هذا الغياب كدليل، لأن ادعاء السعة المستضافة يعتمد على قابلية الوصول الحالية والدعم الحالي والالتزامات التشغيلية الحالية.

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

تبدأ الأدلة العامة بـRDAP، ونظرة عامة RIPEstat، وحالة التوجيه، والبادئات المعلنة، والجيران، وتاريخ التوجيه، وPeeringDB، وCloudflare Radar، وBGP.tools، وHurricane Electric، وIPinfo، والتحقق من RPKI. هذه السجلات ليست نصوصًا تسويقية. إنها ملاحظات آلية تساعد في فصل بصمة المسار الحي عن الادعاءات التي تحتاج إلى أدلة تعاقدية.

سجل الهوية مفيد، لكنه ليس الخدمة

يحدد AS30502 حدود الشبكة. إنه لا يحدد كل كيان قانوني أو موظف أو قاعة بيانات أو منتج يباع تحت اسم Hosting Consulting, Inc. هذا التمييز مهم لأن المسؤولية يمكن أن تكون مقسمة. قد يسمي كائن السجل حاملًا واحدًا، وقد يستخدم PeeringDB اسمًا تجاريًا، وقد يصف موقع الويب خدمة أوسع، وقد يتم توقيع عقد العميل من قبل شركة تابعة أخرى.

كان تصنيف الحامل في نظرة عامة RIPEstat هو PROHCI-MIA - Hosting Consulting, Inc. يساعد هذا التصنيف في ربط ASN بالموضوع، لكنه ليس وعدًا على مستوى الخدمة. إنه يشير إلى حيث تشير أدلة موارد الأرقام. لكنه لا يذكر ما إذا كان العميل يتلقى استضافة أجهزة عارية، أو أجهزة افتراضية، أو ترانزيت IP، أو خدمة شبكة مُدارة، أو وظيفة شبكة مؤسسية داخلية.

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

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

لا ينبغي المبالغة في قراءة تاريخ التوجيه

الأدلة التاريخية للتوجيه مفيدة، لكن لا ينبغي بيعها على أنها سعة حالية. أدرج RIPEstat أول مسار مرصود 208.78.94.0/23 في 2008-01-17T16:00:00 وآخر مسار مرصود 208.91.206.0/23 في 2013-06-07T08:00:00.

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

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

بالنسبة للمشتريات، القاعدة بسيطة: لا تشترِ المرونة الحالية بـ BGP الماضي. يمكن أن تدعم الإعلانات التاريخية الهوية والتشغيل السابق. لكنها لا تستطيع إثبات السعة الحالية أو مسارات النسخ الاحتياطي أو الاستجابة للحوادث.

يساعد RPKI في مخاطر الأصل، وليس في كل حالات الفشل

يطرح التحقق من أصل المسار سؤالاً محددًا: هل AS30502 مخول للإعلان عن بادئة معينة؟ بالنسبة لـ Hosting Consulting, Inc، أرجعت لقطة التحقق أنه لم تكن هناك بادئة حالية متاحة للتحقق من أصل المسار في هذا الالتقاط. أول رابط تحقق تم استخدامه هنا كانالتحقق من RPKI لـ RIPEstat.

بيانات الأصل الصالحة مفيدة لأنها تقلل من فرصة رفض المسار من قبل الشبكات التي تفرض التحقق من أصل المسار (Route Origin Validation). كما تشير إلى أن شخصًا لديه حق الوصول إلى ضوابط موارد الأرقام قد اتخذ خطوة إدارية لنشر التخويل. هذا أفضل من حالة أصل غير معروفة أو غير صالحة لنفس البادئة النشطة.

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

الطريقة الأوسع موصوفة فيRFC 6811والمواد التشغيلية فيAPNICوARIN. تشرح هذه الوثائق لماذا ينتمي التحقق من الأصل إلى محادثة المرونة مع توضيح أنها إحدى الضوابط من بين العديد.

أدلة التوصيل والمرافق ليست تدقيقًا للسعة

استعلام PeeringDB API فيPeeringDBلم يُرجع ملف تعريف شبكة PeeringDB لاستعلام ASN.

PeeringDB قيّم لأنه غالبًا ما يكشف عن المفردات العملية للترابط: السياسة، وعدد التبادلات، وعدد المرافق، وأعداد البادئات التقريبية، وأحيانًا زجاج النظر (looking glass). بالنسبة لـ Hosting Consulting, Inc، تساعد هذه الحقول في تحديد ما إذا كانت البصمة العامة تبدو ككتلة توجيه وحيدة، أو شبكة متصلة بالتبادل، أو مشارك ترابط أوسع.

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

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

يجب إثبات تنوع الترانزيت مرتين

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

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

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

هذا هو المكان الذي يكون فيهMANRSوRFC 7454سياقًا مفيدًا. فهي تحدد سلوك التوجيه الجيد والنظافة التشغيلية. لكنها لا تشهد بأن Hosting Consulting, Inc قد اشترت أو اختبرت كل مسار متنوع قد يحتاجه العميل.

السعة المثبتة ليست السعة التي يمكن للعميل استخدامها

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

بالنسبة لـ Hosting Consulting, Inc، يمكن للأدلة العامة وصف مساحة العناوين وبعض أدلة الترابط. لكنها لا تستطيع إخبارنا بعدد برمجيات مراقبة الأجهزة الافتراضية (hypervisors) قيد التشغيل، أو كيفية نسخ التخزين، أو ما إذا كانت البصريات والخوادم الاحتياطية موجودة في الموقع، أو عدد أحمال عمل العملاء التي يمكن نقلها دفعة واحدة. يمكن أن تظل الشبكة التي لديها مسار صحيح وملف عام تعاني من نقص في السعة القابلة للاسترداد إذا كان موقع الاسترداد صغير الحجم أو كان طابور الدعم مثقلًا.

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

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

الطاقة والقطع الاحتياطية والأيدي هي التي تحدد ساعة الإصلاح

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

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

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

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

موقع البيانات هو مسألة وضع، وليس رمز دولة

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

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

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

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

شروط الدعم جزء من البنية التحتية

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

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

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

بالنسبة لـ Hosting Consulting, Inc، فإن أدلة الشبكة العامة كافية لتبرير أسئلة الدعم هذه ولكنها ليست كافية للإجابة عليها. هذه هي الحدود الصحيحة للبحث العام: لا ينبغي له اختراع مستويات الخدمة، ولا ينبغي أن يسمح لنقص التفاصيل العامة بإخفاء المخاطر التشغيلية.

المراقبة تحول المسار إلى إشارة تشغيلية

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

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

الأدوات العامة المستخدمة هنا مفيدة لأنها خارج قصة المزود الخاصة. كل من RIPEstat و PeeringDB و Cloudflare Radar ومجمعات BGP العامة ترى أجزاء مختلفة من الحافة. الاتفاق فيما بينها يزيد الثقة. الاختلاف ليس خطأ تلقائيًا، لكنه يخبر العميل أين يطرح السؤال التالي.

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

التحكم في التغيير هو اعتمادية خفية

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

بالنسبة لـ Hosting Consulting, Inc، لا ينشر أي سجل عام تمت مراجعته هنا سياسة تغيير. هذا طبيعي، لكنه يجعل اللغة التعاقدية مهمة. يجب أن يعرف العميل كيف تتم الموافقة على التغييرات الطارئة، وما إذا كان يتم الإعلان عن الصيانة التي تؤثر على العميل، وما إذا كان يتم اختبار التغييرات على مجموعة أصغر أولاً، وكيف يقوم المزود بإبلاغ التراجع.

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

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

الترحيل هو اختبار المرونة النهائي

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

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

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

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

كيف يجب على المشتري اختبار الادعاء

يجب أن يبدأ المشتري بدليل على الخدمة الحية. اسأل أي خدمات تواجه العملاء تستخدم AS30502، وأي بادئات يتم تخصيصها للمنتج، وما إذا كانت عناوين معينة من المزود أو عناوين مزود سحابي متورطة أيضًا. قارن الإجابة بـالبادئات المعلنة لـ RIPEstatوالملاحظات المستقلة مثلBGP.toolsأوHurricane Electric.

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

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

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

درجة الأدلة

تحصل Hosting Consulting, Inc على درجة أدلة ضعيفة في هذا المقال. الدرجة ليست حكمًا على جودة الشركة. إنها حكم على ما يمكن أن تدعمه الأدلة العامة. هنا، الحقائق العامة المفيدة هي AS30502، ولا توجد بادئة معلنة حالية في هذا الفحص، مع تاريخ RIPEstat آخر رؤية لـ 208.91.206.0/23 في 2013-06-07T08:00:00، ولم تكن هناك بادئة حالية متاحة للتحقق من أصل المسار في هذا الالتقاط، ولم يتم إرجاع ملف تعريف شبكة PeeringDB لاستعلام ASN، وأدلة الجيران عن عدم وجود جيران مرئيين حاليًا في عرض جيران RIPEstat.

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

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

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

من يشعر بالفشل

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

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

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

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

كيف يمكن للأدلة العامة أن تضلل

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

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

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

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

حدود المورد تحدد الاسترداد

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

السجل العام حول Hosting Consulting, Inc لا يكشف عن حدود الموردين هذه. لهذا السبب يجب على المشترين طلب خريطة مسؤولية بدلاً من وعد عام بوقت التشغيل. يجب أن تسمي الخريطة من يتحكم في المنشأة، ومن يتحكم في جهاز التوجيه، ومن يتحكم في التخزين، ومن يتحكم في النسخ الاحتياطية، ومن يتحكم في DNS، ومن يتحكم في الهوية، ومن يمكنه الموافقة على التغييرات الطارئة.

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

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

يجب التمرن على الاسترداد

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

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

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

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

الاستنتاج الضيق أكثر فائدة

الاستنتاج الضيق لـ Hosting Consulting, Inc أقوى من الاستنتاج العريض لأنه يمكن اختباره. تحدد الأدلة العامة AS30502، وتعطي خط أساس للمسار والسجل، وتظهر ما هو مرئي أو غير مرئي من بيانات الترابط، وتضع الأسئلة التي يجب الإجابة عليها قبل أن يعامل العميل الخدمة كسعة استضافة مرنة.

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

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

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

ما الذي يجب مراقبته بعد ذلك

التغييرات العامة التالية التي يجب مراقبتها لـ Hosting Consulting, Inc ملموسة: بادئات جديدة أو مسحوبة، تسمية حامل مختلفة لـ AS30502، تحديث PeeringDB، تغيير في التحقق من أصل المسار، جار مرئي جديد، أو موقع ويب وصفحة خدمة تسمي مواقع الإنتاج وواجبات الدعم. كل منها سيغير القراءة العملية للبصمة.

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

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

العناية الواجبة التشغيلية بعبارات واضحة

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

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

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

بالنسبة لـ Hosting Consulting, Inc، تعطي أدلة الشبكة العامة خريطة بداية. الخريطة مفيدة لأنها تحدد الحافة العامة والفجوات حولها. لكنها ليست مفيدة إذا عوملت ككامل المنطقة. يجب أن يبدأ السجل العام محادثة عملية حول رؤية المسار، ووضع الموقع، والطاقة، والترانزيت، والدعم، والخروج. لا ينبغي أن ينهي تلك المحادثة.