الخلاصة

  • في 17 يونيو 2016، قالت Cloudflare إنها رصدت عند الساعة 08:32 بالتوقيت العالمي فقداً ملحوظاً للرزم عبر Telia Carrier، صاحبة النظام المستقل AS1299. أصبح الفقد متقطعاً ثم اختفى أثناء التحليل. يثبت ذلك وجود مشكلة في إيصال الرزم، لكنه لا يكشف سبباً داخلياً ولا يثبت انقطاعاً متصلاً حتى 20 يونيو. [1]

  • في 20 يونيو، رصدت Cloudflare فقداً وصفته بالكثيف عند 12:10، وربطت الحالة بإسقاط رزم تخصها وتخص عملاء آخرين لدى Telia وبزيادة أخطاء HTTP 522. وعند 12:30 أغلقت منافذها مع Telia وحولت الحركة إلى مزودين آخرين؛ أي إنها استخدمت سلطة كانت تملكها على اختيار العبور، لا سلطة على إصلاح شبكة Telia الداخلية. [1]

  • تحتفظ Catchpoint بنص إشعار لعملاء Telia يصف مرحلة لاحقة في اليوم نفسه: تحديثاً روتينياً لسياسة توجيه البادئات التجميعية داخل نواة IP، بدأ أثره المعلن عند 16:00، وأدخل الحركة المتجهة إلى بادئات واقعة داخل تلك التجميعات في ثقب أسود. ووفق الإشعار، أعيدت السياسة السابقة عند 17:05 وبدأت الخدمات تتعافى تدريجياً. [2]

  • لا تثبت السجلات المنشورة أن فقد الرزم عند 12:10 وتغيير السياسة عند 16:00 كانا آلية تقنية واحدة متصلة. يجمعهما اليوم نفسه والمشغّل نفسه، لكن التوقيت والوصف مختلفان. لذلك ينبغي قراءتهما كدليلين تشغيليين متجاورين، لا كسلسلة سببية مكتملة لم تُنشر تفاصيلها.

  • تقع مسؤولية Telia في السياسة التي تشغّلها، ونطاق نشرها، ومراقبة التمرير، وإيقاف التغيير، والتراجع، وإبلاغ العملاء. وتقع مسؤولية العميل في تنويع مزودي العبور، وقياس الفقد بصورة مستقلة، وتحديد عتبة السحب، وتوفير سعة بديلة قابلة للاستخدام. اشتراك الطرفين في منظومة واحدة لا يجعل قدرتهما أو مسؤوليتهما متماثلتين. [1][2]

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

تسلسل زمني حذر ليومي 17 و20 يونيو

يبدأ الحدث المحدود يوم الجمعة 17 يونيو، حين أعلنت Cloudflare أن أنظمتها اكتشفت فقداً كبيراً للرزم بين وجهات متعددة عبر Telia عند 08:32 بالتوقيت العالمي. وتقول روايتها إن الفقد صار متقطعاً ثم زال بينما كان المهندسون يحققون فيه. هذه شهادة عميل كبير لديه قياسات تشغيلية، وليست تحليلاً داخلياً لأجهزة AS1299. لذلك لا يمكن منها تعيين الموجّه أو السياسة أو المنطقة، ولا مد زمن الواقعة تلقائياً إلى يوم الاثنين. [1]

في 20 يونيو ظهرت ملاحظة منفصلة. عند 12:10 رصدت Cloudflare فقداً كثيفاً للرزم، وقالت إن رزمها ورزم عملاء آخرين كانت تُسقط. انعكس ذلك في ارتفاع أخطاء HTTP 522، وهي إشارة على عجز خدماتها عن إكمال الاتصال بالوجهة الأصلية في حالات رصدتها. وعند 12:30 اتخذت قراراً تشغيلياً بسحب منافذ Telia، فانتقلت الحركة إلى اتصالات أخرى كانت متاحة لديها. [1]

أما الساعة 16:00 فتأتي من إشعار Telia الذي أعادت Catchpoint نشره، لا من تقرير جذري كامل متاح مباشرة من المشغّل. يصف الإشعار تحديثاً روتينياً لسياسة البادئات المجمعة في نواة Telia Carrier IP، ويقول إن الحركة إلى البادئات المحتواة جرى إسقاطها. وعند 17:05 أعادت Telia السياسة التي كانت تعمل سابقاً، ثم وصفت استعادة تدريجية للخدمة. كلمة «تدريجية» مهمة: تنفيذ التراجع لحظة إدارية، أما تعافي المسارات والتمرير والتطبيقات فعملية تحتاج إلى قياس. [2]

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

AS1299 وسياق النقل من المستوى الأول

يمثل AS1299 نظاماً مستقلاً تديره Telia Carrier في سياق الواقعة التاريخية. وتساعد سجلات ASN وخدمات مثل RIPEstat على ربط الرقم بالمشغّل وعلى عرض معلومات توجيه حالية وتاريخية، لكنها لا تُشغّل موجّهات Telia ولا تضمن أن مساراً ظاهراً يمرر الرزم. السجل يعرّف علاقة تشغيلية ويهيئ دليلاً، ولا يصنع نتيجة الشبكة بذاته. [14]

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

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

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

كيف صنعت سياسة البادئات التجميعية مسار إسقاط

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

بحسب إشعار Telia المحفوظ لدى Catchpoint، مسّ التحديث الروتيني سياسة التوجيه الخاصة بالبادئات التجميعية، وكانت النتيجة أن الحركة إلى بادئات داخلها دخلت ثقباً أسود. يمكن عندئذ أن تبقى البادئة الأوسع مرئية ومقبولة لدى الجيران، فتستمر الشبكات الخارجية في إرسال الرزم نحو AS1299، بينما لا يجد مستوى التمرير داخله مساراً صالحاً لبعض الوجهات، أو يوجّهها إلى إجراء إسقاط. هذا هو الفارق بين الثقب الأسود والسحب النظيف: عند اختفاء المسار قد يُختار بديل؛ أما المسار الظاهر فيستطيع مواصلة جذب حركة لن تُسلّم. [2]

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

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

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

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

ما تقيسه المشاهدات وما لا تستطيع إثباته

قارنت Catchpoint إشعار المشغّل بمشاهدات من المجمّع rrc01 التابع لخدمة RIPE RIS في نقطة LINX. وأفادت بأن نظيرين من AS1299 أظهرا ارتفاعاً حاداً في الإعلانات والسحوبات قرب توقيت الإشعار، مع أحداث مست نحو 500 ألف شبكة IPv4 و32 ألف شبكة IPv6 ضمن ما ظهر عبر هذين النظيرين. هذه أعداد لأحداث ومسارات مرئية من نظيرين، وليست تعداداً لمستخدمين متضررين أو رزم مفقودة أو خسائر مالية. وقد تُحدّث البادئة الواحدة مرات عدة. [2]

تحتفظ RIPE RIS وRouteViews بلقطات وتحديثات BGP من مشاركين ونقاط رصد متعددة. تمكّن هذه السجلات الباحث من السؤال: متى ظهر إعلان أو سحب؟ وما مسار AS الذي رآه مجمّع بعينه؟ لكنها لا ترى كل وصلة خاصة، ولا التفضيل المحلي داخل كل شبكة، ولا جدول التمرير في كل موجّه، ولا حركة الرزم نفسها. وغياب ظاهرة عن مجمّع واحد لا يثبت غيابها عن الشبكة كلها، كما أن ظهور تحديث واسع لا يساوي انقطاعاً واسعاً بالقدر نفسه. [15][16]

تضيف رواية Cloudflare طبقة مختلفة: فقداً للرزم، وأخطاء تطبيقية، وقراراً بإبعاد Telia ثم تحولاً إلى مزودين آخرين. إنها أقرب إلى تجربة التمرير التي عاشها عميل، لكنها تظل تجربة عميل ذي بنية وانتشار محددين، لا مسحاً لكل عملاء AS1299. [1]

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

حالة التوجيه الجارية هي الواقع التشغيلي

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

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

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

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

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

المسؤولية تتبع القدرة الفعلية على التحكم

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

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

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

نشر السياسة والتراجع: الإجراء ليس دليلاً كافياً على الاستعادة

تفيد رسالة Telia إلى العملاء، كما حفظتها Catchpoint، بأن مرحلة بدأت عند الساعة 16:00 بالتوقيت العالمي في 20 يونيو/حزيران 2016 أثناء تحديث روتيني لسياسة توجيه البادئات التجميعية في نواة IP لدى الشركة. ونسبت الرسالة الأثر إلى إسقاط حركة البادئات الواقعة داخل تلك التجميعات في مسار عديم التصريف، ثم قالت إن السياسة السابقة العاملة أُعيدت عند 17:05 وإن الخدمات بدأت تتعافى تدريجياً. هذه رواية مشغّل محفوظة لدى مصدر مستقل، وليست سجلاً كاملاً لأوامر التهيئة أو لكل جهاز تأثر [2].

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

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

ولا يجوز وصل هذه المرحلة تلقائياً بقياس Cloudflare عند 12:10 وقرارها عند 12:30 في سلسلة تقنية واحدة. الحدثان وقعا في اليوم نفسه ولدى الناقل نفسه، لكن السجل العلني لا يثبت أن فقد الحزم المبكر وتحديث الساعة 16:00 كانا آلية متصلة بلا انقطاع. هذه الحدود الزمنية تحمي التحليل من اختراع سبب موحد لا تكشفه المصادر [1][2].

تركّز العبور وسحب منافذ Cloudflare

قالت Cloudflare إنها رصدت في 20 يونيو/حزيران فقداً هائلاً للحزم عبر Telia عند 12:10 بالتوقيت العالمي. وبعد عشرين دقيقة، أوقفت منافذها مع Telia كي تنتقل الحركة إلى مزودين آخرين. كانت هذه الخطوة ممكنة لأنها احتفظت بترابطات عبور وتناظر أخرى؛ وهي تقدم دليلاً عملياً على أن العميل يستطيع تقليل مدة تعرضه لمسار متدهور حين يملك بديلاً صالحاً وسلطة تشغيله [1].

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

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

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

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

مجمّعات المسارات لا ترى مستوى التمرير كله

قارنت Catchpoint رسالة Telia بمشاهدات من المجمّع rrc01 التابع لخدمة RIPE RIS في نقطة LINX. وذكرت ارتفاعاً حاداً في الإعلانات والسحوبات من نظيرين تابعين لـ AS1299 قرب توقيت المرحلة المعلنة، وقدرت أن الأحداث المرصودة تعلقت بنحو 500 ألف شبكة IPv4 و32 ألف شبكة IPv6. هذه أعداد لأحداث ومسارات ظهرت من نظيرين عند نقطة رصد مختارة؛ وليست تعداداً للمستخدمين المتضررين، ولا للحزم المفقودة، ولا لكل الشبكات التي تعذر الوصول إليها [2].

يسجل مجمّع المسارات ما يعلنه النظراء له وما يسحبونه، وفق موقعه وعلاقاته وسياساتهم. ولا يرى بالضرورة التفضيل المحلي داخل كل شبكة، أو جداول التمرير الخاصة بكل موجّه، أو الوصلات الخاصة، أو أحجام الحركة، أو الوجهة الفعلية لكل حزمة. لذلك توفر RIPE RIS وRouteViews أرشيفاً مهماً لتوقيت الاضطراب ومقارنة المسارات، لكنهما لا يشكلان مسحاً شاملاً للإنترنت ولا شهادة على سلامة التوصيل [15][16].

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

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

الاتصال التشغيلي جزء من التعافي

أقرت رسالة Telia المحفوظة بأن كثافة الشكاوى أخرت الاتصال عبر البريد الإلكتروني والهاتف، فيما قالت Cloudflare إن رسائلها الخارجية الأولى لم تحدد الاعتماد على الناقل بالدقة المطلوبة وإن عليها تحسين التواصل [1][2]. لا تجعل هذه الاعترافات الاتصال مسألة علاقات عامة؛ فالمعلومة التشغيلية تحدد ما إذا كان العميل سيبقي المسار، أو يسحبه، أو يحجز سعة، أو يبحث عن عطل داخل شبكته.

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

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

المصادر

  1. https://blog.cloudflare.com/a-post-mortem-on-this-mornings-incident/
  2. https://www.catchpoint.com/blog/incident-review-an-account-of-the-telia-outage-and-its-ripple-effect
  3. https://www.thousandeyes.com/blog/analyzing-internet-issues-traffic-outage-detection
  4. https://servebolt.com/articles/telia-went-down-and-so-did-we/
  5. https://www.theregister.com/2016/06/20/telia_engineer_blamed_massive_net_outage/
  6. https://www.theregister.com/2016/06/21/cloudflare_apologizes_for_telia_screwing_you_over/
  7. https://datatracker.ietf.org/doc/html/rfc7908
  8. https://datatracker.ietf.org/doc/html/rfc7454
  9. https://datatracker.ietf.org/doc/html/rfc8212
  10. https://datatracker.ietf.org/doc/html/rfc9234
  11. https://datatracker.ietf.org/doc/html/rfc6811
  12. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
  13. https://www.manrs.org/wp-content/uploads/2021/02/MANRS-Network-Operators-Actions-v2.4.4.pdf
  14. https://stat.ripe.net/AS1299
  15. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
  16. https://archive.routeviews.org/bgpdata/2016.06/UPDATES/
  17. https://arxiv.org/abs/2006.06576