الخلاصة

  • أعلنت RIPE NCC التحقيق في إخفاقات متقطعة لتحديث WHOIS عند 20:04 بتوقيت CET في 28 أكتوبر، ثم أعادت مكوّن قاعدة البيانات إلى حالة التشغيل عند 20:23 وأغلقت الحادث عند 20:32.
  • سجل الحالة يثبت مسار الإصلاح العام، لكنه لا يذكر طلبات التعديل أو الكائنات التي نجحت كتابتها لكل مستخدم.

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

يحمل سجل الحادث الرسمي بصيغة JSON ثلاث لحظات دقيقة بتوقيت وسط أوروبا: تحقيق عند 20:04:48، إصلاح قيد المراقبة عند 20:23:24، وإغلاق عند 20:32:00. صُنّف مكوّن RIPE Database انقطاعاً جزئياً أثناء التحقيق وعاد إلى التشغيل عند بدء المراقبة، فيما حمل الحادث كله تصنيف أثر «كبير». لا يورد السجل سبب الخلل أو وسيلة التحديث المتأثرة أو عدد الطلبات التي أخفقت. هذه أوقات بلاغات المؤسسة، وليست قياساً لبداية ونهاية إخفاق كل طلب.

توضح إرشادات الإقرار بالاستلام لماذا لا يكفي اللون الأخضر. يعود إقرار واحد لكل عملية إرسال ويعرض نتائج الكائنات الموجودة فيها. في Syncupdates قد يشير HTTP 200 إلى معالجة الرسالة مع فشل تعديل كائن داخلها؛ يحسم ملخص الإقرار النتيجة. وترد واجهة REST بصيغة مختلفة. لم يحدد إعلان الأربعاء أي مسار تأثر.

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

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