ملخص

  • إن أقوى مرتكز هوية عامة لـ Cloud APAC هوAPNIC RDAP لـ AS132399، الذي يسمي ASNATICLOUD-AP، ويصفه بأنه SITA Cloud APAC، ويعطي الدولة كـ SG ويسجل المسجل باسم المنظمة الدولية لاتصالات الطيران (SITA).
  • يُبلغنظرة عامة على ASمن RIPEstat حالياً أن الحامل هوATICLOUD-AP - SITA Cloud APACويحدد ASN على أنه مُعلَن، وهو دليل أقوى من كائن سجل خامل.
  • التوجيه العام الحالي لا يزال ضيقًا. يُظهرحالة التوجيهمن RIPEstat أربع بادئات IPv4، ولا بادئات IPv6 مرئية، وجار واحد مُلاحَظ؛ ويُحددجيران ASNمن RIPEstat الجار المرئي باسم AS15830.
  • البادئات المُعلَنة مرئية وفحوصات مصادقة أصل التوجيه إيجابية. يُدرجالبادئات المُعلَنةمن RIPEstat 57.250.51.0/24 و57.191.95.0/24 و57.191.96.0/19 و57.191.160.0/19; وتُرجع فحوصات مصادقة RIPEstat لهذه الأصول الأربعة حالة صالحة.
  • تُظهر صفحات SITA العامة لماذا قد يكون عبء العمل مهمًا من الناحية التشغيلية. تقول SITA إنها تخدم اتصالات النقل الجوي وتكنولوجيا المعلومات، وتعمل عبر أكثر من 1000 مطار، وتُسوّقSITA Connectكاتصال مُدار عبر مواقع الطيران.
  • السجل العام لا يُحدد مركز البيانات، أو عدد الرفوف، أو ملكية الخوادم، أو مسار تصعيد الدعم، أو حدود النسخ الاحتياطي، أو إجراءات تصدير العميل، أو تصميم تجاوز الفشل متعدد المواقع خلف Cloud APAC. درجة أدلة الشبكة هي متوسطة: توجيه IPv4 الحالي مرئي ومصادق عليه، لكن المرونة القابلة للاستخدام من قبل العميل لا تزال غير مثبتة.

فاتورة السحابة لا تزال تنتهي عند رف في سنغافورة

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

هذه هي الطريقة المفيدة لقراءة Cloud APAC. البصمة العامة لا تبدو كشركة VPS تجارية مع بطاقات حزم وصفحة دفع. تبدو كعلامة شبكة وسحابة مرمزة في سنغافورة داخل بيئة تكنولوجيا الطيران في SITA.APNIC RDAP لـ AS132399يسمي ASNATICLOUD-AP، ويعطي الوصف SITA Cloud APAC، ويسرد الدولة كـ SG ويسجل المسجل كمنظمة دولية لاتصالات الطيران (SITA). يُظهرعرض whoisمن RIPEstat نفس اسم AS ووصفه ودولته ومصدر APNIC، بالإضافة إلى سطور سياسة التوجيه المستوردة والمصدرة إلى AS15830.

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

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

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

ما تثبته أدلة التوجيه العامة

AS132399 ليس إدخالاً قديمًا. يُبلغنظرة عامة على ASمن RIPEstat أن الحامل هوATICLOUD-AP - SITA Cloud APACويظهر ASN على أنه مُعلَن. يُظهرحالة التوجيهمن RIPEstat أيضًا رؤية IPv4 حالية: 325 من نظراء RIS يرون ASN في الوقت المفحوص، وأربع بادئات IPv4 و16,896 عنوان IPv4. هذه إشارة أقوى بكثير من سجل بقاعدة بيانات بدون مسارات ملاحظة.

قائمة البادئات الحالية محددة. يُدرجالبادئات المُعلَنةمن RIPEstat 57.250.51.0/24 و57.191.95.0/24 و57.191.96.0/19 و57.191.160.0/19 في أحدث نافذة مدتها أسبوعان. تُظهر فحوصات نظرة عامة على البادئات من RIPEstat أن هذه البادئات الأربع مصدرها AS132399:57.250.51.0/24،57.191.95.0/24،57.191.96.0/19و57.191.160.0/19.

جغرافيا السجل مختلطة بطريقة يجب تفسيرها بحذر. APNIC RDAP لـ57.191.95.0/24يسمي النطاقSITA-SPC-SIN-addمع دولة SG. APNIC RDAP لـ57.191.96.0/19يسميهSITA-SPC-SIN-S1مع دولة SG. APNIC RDAP لـ57.191.160.0/19يسميهSITA-SPC-SIN-S2مع دولة SG. APNIC RDAP لـ57.250.51.0/24، مع ذلك، يُرجع تسجيلاً أوسع من 57.250.0.0 إلى 57.250.255.255 باسمSITA-SC-Infrastructureمع دولة BE وكيانات SITA.

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

وضع أصل التوجيه إيجابي. مصادقة أصل التوجيه من RIPEstat لـ57.250.51.0/24،57.191.95.0/24،57.191.96.0/19و57.191.160.0/19تُرجع حالة صالحة لـ AS132399 في الوقت المفحوص. مصادقة أصل التوجيه الصالحة لا تمنع كل حوادث التوجيه، لكنها تقلل فئة مهمة من مخاطر سوء التهيئة والاختطاف. في سوق حيث لا تزال بعض شبكات الاستضافة الصغيرة تمتلك وضع RPKI غير معروف أو غير مكتمل، هذه إشارة إيجابية ذات معنى.

أكبر تحفظ هو IPv6. يُظهر حالة التوجيه من RIPEstat عدم وجود بادئات IPv6 مرئية لـ AS132399 في الوقت المفحوص، على الرغم من أن سجل whois المشتق من APNIC يتضمن سطور سياسة استيراد وتصدير IPv6 مع AS15830. قد يعكس ذلك خيارًا في تصميم الخدمة، أو خطة IPv6 غير معلنة، أو مشكلة رؤية جامع، أو تصميم تسليم لا يحتاج إلى IPv6 مرئي تحت هذا ASN. لا يزال مهمًا للعملاء. إذا كانت Cloud APAC جزءًا من خدمة حديثة مستضافة أو مُدارة، فيجب الإجابة على إمكانية الوصول المزدوجة (dual-stack)، وتصفية IPv6، وتفويض أصل التوجيه والمراقبة بشكل مباشر، وليس تخمينها من رؤية عامة IPv4 فقط.

مزود علوي واحد مرئي هو سؤال تصميم، ليس حكماً

تشير صورة سياسة التوجيه والجار الملاحظ في نفس الاتجاه. تُظهربيانات whois لـ AS132399من RIPEstat واردات من AS15830 تقبل أي شيء وصادرات إلى AS15830 تعلن عن AS132399. يُظهرعرض جيران ASNمن RIPEstat جارًا مرئيًا فريدًا واحدًا، AS15830. يُعرّفRIPE RDAP لـ AS15830اسم AS باسم Equinix ويصف Equinix Internet Access / Equinix Connect كمنصة عبور IP عالمية. يُبلغنظرة عامة على AS لـ AS15830من RIPEstat أن الحامل هو Equinix، ويسردPeeringDBEquinix AS15830 كمزود خدمة شبكة.

Equinix هو سياق علوي معقول وعالي الجودة لشبكة موجهة نحو سنغافورة. تصف صفحات Equinix في سنغافورة وجود مراكز بيانات وترابط محلي، بما في ذلكصفحة مراكز بيانات سنغافورةالعامة،منشأة SG1في Ayer Rajah ومنشأة SG3. هذا السياق يجعل مسار توجيه Cloud APAC مقروءًا: الحافة الإنترنتية المرئية مرتبطة بنظام ترابط وعبور كبير بدلاً من مزود خدمة إنترنت استهلاكي غير معروف.

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

بالنسبة لـ AS132399، تُظهر جامعات التوجيه العامة حاليًا مزودًا علويًا واحدًا مرئيًا. قد يكون ذلك كافيًا للدور الذي يلعبه ASN. إذا كانت Cloud APAC حافة مؤسسية خاضعة للتحكم، أو قطاع سحابي داخلي، أو باب أمامي إقليمي مدعوم باتصال خاص، فقد لا يكون مسار الإنترنت المرئي هو التصميم بأكمله. إذا تم بيعها أو الاعتماد عليها كاستضافة مواجهة للعملاء، فإن وجود مزود علوي واحد مرئي يثير سؤالاً في المشتريات. يجب على العميل أن يسأل عما إذا كان هناك مسار عبور إنترنت ثانٍ، أو مسار WAN خاص، أو ترابط سحابي، أو موقع احتياطي بارد، أو مسار DDoS منفصل، أو إجراء تجاوز فشل يدوي.

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

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

دور SITA في الطيران يرفع عواقب الإخفاقات الصغيرة

تشرح صفحات SITA العامة لماذا تستحق هذه البنية التحتية قراءة أكثر دقة من اسم استضافة صغير عادي. يصف الموقع الرئيسي لـ SITA الشركة بأنها متخصصة في اتصالات النقل الجوي وتكنولوجيا المعلومات ويقدم مدى واسعًا من الوصول إلى المطارات والعملاء. يقولصفحة SITA Membershipإن قاعدة العضوية تشمل شركات الطيران والمطارات والمشاركين الآخرين في النظام البيئي للطيران، وأن أكثر من 13,500 موقع صناعي يتصل عبر شبكة SITA. تُسوّقSITA Connectكاتصال مُدار عبر أكثر من 750 وجهة و 600 مطار متصل مسبقًا و SD-WAN وأمان من فئة SASE واتصال متعدد السحابات ودعم لتطبيقات النقل الجوي.

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

تضيفصفحة إدارة الخدمةمن SITA إشارة دعم مهمة. تصف مجموعة إدارة خدمات متوافقة مع ITIL، وتوفرًا عالميًا على مدار الساعة، ومراقبة استباقية ودعمًا لاحتياجات المطار وشركات الطيران التشغيلية. تقولصفحة حول SITAإن SITA Service Management مدعومة من SITA Global Services وتشير إلى دعم على مدار الساعة وخدمة عملاء عالمية وقوة عاملة متخصصة كبيرة. هذه التصريحات مطمئنة على مستوى الشركات، لكنها لا تجيب على السؤال الخاص بـ Cloud APAC: أي فريق يملك حوادث AS132399، وأي فريق يملك الأيدي في مركز البيانات، وما هي أهداف الخدمة التي تنطبق على عبء عمل عميل معين؟

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

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

سنغافورة مركز قوي بحدود طاقة صارمة

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

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

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

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

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

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

السعة المستضافة تفشل عبر مسارات عادية

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

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

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

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

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

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

دليل الاستعادة يجب أن يتناسب مع عبء العمل

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

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

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

بالنسبة للتطبيقات المُدارة، يجب أن يشمل دليل الاستعادة التبعيات. قد يعتمد نظام شركة طيران أو مطار على موفري الهوية وطوابير الرسائل وقواعد البيانات وواجهات برمجة التطبيقات التابعة لجهات خارجية ومحطات العمل المحلية وأنفاق الشبكة. استعادة خادم التطبيق وحده قد تترك المستخدمين غير قادرين على المعاملة. يجب على العميل أن يطلب قائمة تبعيات تحدد الأنظمة التي تُستعاد معًا، وأيها لها ساعات مستقلة، وأيها خارج مسؤولية Cloud APAC.

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

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

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

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

RPKI يساعد، لكنه ليس إجابة أمن التوجيه الكاملة

حالة RPKI الصالحة لبادئات Cloud APAC الحالية هي إشارة إيجابية مهمة. يصفRFC 6811مصادقة أصل التوجيه: طريقة للشبكات لتقييم ما إذا كان AS المصدر المُعلَن مصرحًا له بالبادئة. من الناحية العملية، تساعد مصادقة الأصل الصالحة في تقليل أخطاء الأصل العرضية أو الخبيثة، خاصة عندما تفرض المزودات العلوية التصفية.

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

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

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

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

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

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

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

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

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

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

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

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

يجب أن تبدأ مراجعة جادة لـ Cloud APAC بخريطة خدمة حالية. يجب أن تحدد المنتج أو الحساب الدقيق، والكيان القانوني المتعاقد، والموقع الأساسي، والموقع الاحتياطي أو الثانوي، ومستوى الإدارة، وASN أو ASNs الأصلية، وبادئات العميل إن وجدت، وهيكل الدعم. إذا كانت الخدمة تستخدم AS132399 الخاص بـ SITA، يجب أن تظهر الخريطة بادئات IPv4 الأربع المرئية وتشرح دورها. إذا كانت الخدمة تستخدم شبكة SITA أخرى أو شبكة مورد، يجب أن تسمي الخريطة ذلك بدلاً من ذلك.

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

الوثيقة الثالثة يجب أن تكون بيان المسار والعبور. بالنسبة لـ AS132399، تظهر الأدلة العامة إعلان IPv4 الحالي عبر Equinix AS15830. يجب على العميل أن يسأل عما إذا كان هذا هو المسار العام الوحيد، وما إذا كانت مسارات شبكة الطيران الخاصة موجودة، وما إذا كان هناك مزود ثانٍ، وما إذا كان RPKI مفروضًا، وما إذا كانت حماية DDoS موجودة، وكيف يتم اكتشاف حوادث التوجيه. إذا كانت الإجابة "لا نكشف عن هذا علنًا"، فهذا جيد. إذا كانت الإجابة غير متاحة حتى تحت العقد، يصبح من الصعب قبول المخاطرة.

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

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

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

درجة الأدلة متوسطة، مع معنى ضيق

Cloud APAC لا تستحق الرفض ولا الثقة المفرطة. أدلة الشبكة العامة أقوى من اسم دليل رفيع بدون مسارات حية. AS132399 نشط في وجهات نظر APNIC وRIPEstat. لديه إعلانات IPv4 حالية. البادئات المرئية محددة. المسارات تصادق تحت فحوصات RPKI الخاصة بـ RIPEstat. المزود العلوي المرئي هو Equinix AS15830، وهو مزود شبكة وترابط معروف. تُظهر مواد SITA العامة سياقًا كبيرًا لتكنولوجيا الطيران وسرد دعم ناضج.

الحدود مهمة بنفس القدر. لا تظهر الأدلة العامة بوابة عميل أو كتالوج استضافة تجزئة أو رفوف مسماة أو ملكية منشأة أو مجموعات hypervisor أو مستودعات نسخ احتياطي أو اختبارات استعادة أو أجهزة احتياطية أو تجاوز فشل متعدد المواقع أو هندسة DDoS أو تصعيد دعم لهذا ASN أو إجراء قابلية نقل بيانات. كما أنها لا تظهر إعلانات IPv6 مرئية تحت AS132399. رمز البلد SG وبادئات سنغافورة المسماة إشارات محلية مفيدة، لكنها ليست ضمانًا كاملاً لسيادة البيانات.

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

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