الخلاصة

  • في 7 أكتوبر عند 09:46 بتوقيت وسط أوروبا الصيفي، قالت RIPE NCC إن بعض الطلبات إلى تطبيق RIPE Database على الويب تفشل برمز 502. وفي 09:47 أعلنت تطبيق إصلاح ومراقبة النتائج؛ ثم صنّفت الحادثة محلولة في 8 أكتوبر عند 10:21.
  • الفاصل البالغ 24 ساعة و34 دقيقة يمتد بين تحديث المراقبة وإعلان الحل. ولا يثبت أن الأخطاء استمرت طواله، أو عدد الطلبات التي فشلت، أو أن طريقة استعلام أخرى كانت متاحة.

تسلسل الحالة لا يساوي مدة التعطل

يتألف السجل المنشور من ثلاث محطات: بلاغ أول، ثم انتقال إلى المراقبة بعد دقيقة، ثم إعلان الحل في صباح اليوم التالي. ولم تحدد RIPE NCC النطاق إلا بعبارة «بعض الطلبات». فلا نقطة نهاية ولا عملية بعينها ولا سبب مذكور. والفارق بين وقتي النشر لا يثبت أن اكتشاف المشكلة وإصلاحها استغرق دقيقة؛ إنه يصف توقيت التحديثات العلنية فقط.

من 09:47 بتوقيت وسط أوروبا الصيفي في 7 أكتوبر إلى 10:21 في 8 أكتوبر تمر 24 ساعة و34 دقيقة. هذه مدة الانتقال المنشور من «المراقبة» إلى «محلولة»، وليست نافذة انقطاع مقاسة. ولا تعرض الصفحة أول طلب فاشل أو آخره، ولا توضح إن كانت الأخطاء قد استمرت بعد الإصلاح.

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

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

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

المصادر