RIPE تغلق بلاغ RPKI واللوحة نفسها تبقى قيد الصيانة

الخلاصة

وضعت RIPE NCC علامة completed على سجل الصيانة الخاص بلوحة RPKI Dashboard في 3 نوفمبر 2026 عند 21:06:58 بتوقيت وسط أوروبا، بعد بدء العمل عند 21:00:08. أما سجل Access وبوابة LIR وقاعدة البيانات فبقي جارياً بعد 21:08 وأصبح يتضمن اللوحة نفسها.
عرضت واجهة حالة المكونات اللوحة على أنها under_maintenance بينما أعلن سجلها الخاص الإكمال. ولم تنشر RIPE اختباراً ناجحاً للدخول إلى الحساب وفتح اللوحة وإرسال ROA يحسم ما كان العضو يستطيع فعله.

إنهاء تذكرة إدارية لا يجيب وحده عن سؤال المستخدم: هل أستطيع الآن تنفيذ المهمة؟ في مساء 3 نوفمبر، نشرت RIPE NCC الإجابتين على صفحة حالة واحدة. عند 21:06:58 بتوقيت وسط أوروبا، تحوّل سجل صيانة نظام RPKI إلى completed. وكان قد دخل حالة العمل عند 21:00:08. المكون المذكور فيه هو RPKI Dashboard. من يقرأ هذه البطاقة وحدها يرى عملاً استغرق أقل من سبع دقائق وانتهى.

لكن سجل الصيانة الموازي لحسابات Access وبوابة LIR وقاعدة RIPE أدرج اللوحة نفسها ضمن مكوناته أثناء التنفيذ. تحديثه عند 21:08:58 قال إن العمل مستمر؛ ونسخة محفوظة بعد 21:41 ظلت تعرض in_progress. انتقل وقت النهاية المخطط أولاً إلى 21:40 ثم إلى 21:59. وتؤرخ واجهة حالات المكونات تحديث علامة under_maintenance للوحة عند 21:08:58، بعد نحو دقيقتين من إغلاق سجلها الخاص. وعاد Access إلى operational عند 21:41:21 بينما ظلت اللوحة والبوابة وقاعدة البيانات موسومة بالصيانة. بطاقة مخصصة تقول «اكتمل»، وسطر الخدمة ذاتها يقول «قيد الصيانة». RIPE NCC تنشر الجوابين.

تغيرت البطاقة الثانية خلال العملية. النسخة المحفوظة قبل بدء العمل لم تذكر سوى قاعدة البيانات والبوابة والدخول، وحددت 21:10 نهاية متوقعة. النسخ المحفوظة أثناء التنفيذ أضافت اللوحة مكوناً رابعاً وعرضت 21:40 ثم 21:59 موعداً متوقعاً. سجّل API بداية العمل واستمراره، لكنه لم يكتب تحديثاً مؤرخاً يشرح متى ولماذا أضيفت اللوحة أو مُدّد الوقت إجمالاً 49 دقيقة. من يصل إلى السجل الحالي وحده لا يستطيع رؤية ما كان مكتوباً قبل التعديل.

وصلت النهاية الفعلية قبل آخر موعد متوقع. عادت حالة مكون Dashboard إلى operational عند 21:46:51، وأغلق البلاغ الثاني عند 21:47:19. بين إغلاق بلاغ RPKI الخاص عند 21:06:58 وعودة علامة التشغيل للمكون 39 دقيقة و52 ثانية. وبين علامتي إغلاق البلاغين 40 دقيقة و21 ثانية. كانت 21:59 خطة معدلة لا وقت الانتهاء الفعلي. هذا فرق بين علامات منشورة، وليس قياساً لمدة تعذر فيها استخدام الخدمة.

لا تعني الكلمات المنشورة قياس انقطاع الخدمة الفعلي. completed ختم إغلاق لبلاغ معين؛ وunder_maintenance وصف منشور لحالة مكون في لحظة محددة. ولا يثبت أي منهما إن كان العضو قادراً عند 21:07 على الدخول، أو عند 21:22 على فتح اللوحة، أو عند 21:31 على إرسال تصريح ROA. يوضح دليل RIPE لاستضافة RPKI أن العضو يدخل بحساب RIPE NCC مرتبط بعضوية LIR إلى اللوحة لإدارة تصاريح منشأ المسارات. ويضع دليل Access اللوحة وراء مدخل الحساب نفسه. المهمة التي يهم العضو إنجازها تمر عبر السجلين معاً.

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

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

سجلات RIPE NCC الأصلية