الخلاصة

  • يقول إصدار RIPE Atlas 5130 إن 5120 وضع نصف زمن الذهاب والإياب في خانة إزاحة ساعة NTP. قيمة offset في 5120 غير صحيحة، أما rtt فلم يتأثر بهذه النكسة.
  • في لقطة API غير مخبأة عند 03:12 UTC يوم 31 أغسطس، ظهر 2721 سجل مسبار بحالة Connected ونسخة 5120، مقابل 2350 على 5130 و14680 سجلاً متصلاً إجمالاً.
  • العدد 2721 ليس عدداً للقياسات الخاطئة أو المستخدمين. لكن النتيجة الخام تحمل مسبقاً fw وprb_id والطابع الزمني، وهي مفاتيح تكفي لتحديد صفوف 5120 واستبعادها.
  • المطلوب سجل تصحيح قابل لاكتشاف الآلة يربط الحقل المتأثر والحقول السليمة وحدود الزمن والإجراء المعتمد والإصدار البديل. أما تقدم ترقية المسابر فهو إيصال منفصل.

ما يفهمه القارئ لا يفهمه العميل تلقائياً

نشرت RIPE NCC في 12 أغسطس وثيقة firmware 5130. نصها محدد: الانحدار الذي جاء مع 5120 أبلغ عن نصف RTT بدلاً من إزاحة الساعة. ثم يفصل البيان بين الحقلين، فيقول إن إزاحات 5120 غير صحيحة وإن زمن الذهاب والإياب لم يتأثر.

إذا قرأ محلل هذه الصفحة قبل تنزيل البيانات، يستطيع اتخاذ احتياط. أما برنامج يجلب نتائج Atlas دورياً فلا توجد في الصفحات التي فُحصت إشارة مشتركة تخبره بأن معنى offset تغيّر عند fw=5120. إشعار الإصدار موجود، والبيانات موجودة، لكن القرار الذي يصل بينهما ما زال عملاً يدوياً.

هذه الفجوة ليست نظرية. بعد تسعة عشر يوماً من نشر 5130، أعادت واجهة المسابر العامة 2721 سجلاً متصلاً يعلن 5120. وبلغت سجلات 5130 المتصلة 2350، بينما كان الإجمالي 14680. أي إن 5120 ظهر في نحو 18.5% من السجلات المتصلة في تلك اللحظة.

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

إصلاح أول أغلق القضية ثم فتحها بصورة أخرى

بدأ issue 130 في 11 يوليو 2025 بمشكلة مختلفة. وصف التقرير الطوابع الأربعة لتبادل NTP بأنها صحيحة، لكن ترتيبها في حساب الإزاحة كان معكوساً مقارنة بالـRFC، فأنتج علامة معاكسة.

في 29 أكتوبر 2025، نشر المشروع software probe 5120 معلناً إصلاح حسابات الإزاحة. نص الإصدار على أنه خاص بالمسابر البرمجية. وفي تعليق في اليوم نفسه، قال أحد موظفي RIPE NCC إن العطل أصلح في commit محدد.

غير أن الاختبار لإصدار 5130 أعاد فتح القضية في 23 يوليو 2026. كتب المشرف أن التغيير ربما لم يصلح المشكلة، وربما جعلها أسوأ. واقترح patch يحسب RTT والإزاحة كلّاً على حدة من أربعة طوابع 64-bit fixed-point وفق معادلات RFC 5905.

في 12 أغسطس، أغلق 5130 القضية مع commit 197b599a7faa811d97ebd273078be176842264bb. وحدد شكل الخلل الجديد: نصف RTT ظهر بصفته offset. لذلك لا يصح وصف التاريخ كله بأنه مجرد «علامة معكوسة». هناك عيب أصلي، ومحاولة إصلاح، ونكسة 5120؛ وأي معالجة تاريخية يجب أن تعرف أي حالة أنتجت كل نتيجة.

النتيجة الخام تحمل محدد النسخة

تحتوي صيغة نتيجة NTP على عناصر مفيدة للمراجعة: fw لنسخة البرنامج، وprb_id للمسبار، وtimestamp للوقت. وداخل النتيجة يظهر offset مستقلاً عن rtt، إلى جانب طوابع origin وreceive وtransmit وfinal.

هذه نقطة قوة. من يعرف التحذير يستطيع استبعاد صفوف fw=5120 من تحليل الإزاحة من دون كشف هوية المضيف. ولا يوجد أساس لإسقاط ping أو DNS أو traceroute للمسبار نفسه، ولا لاعتبار RTT خاطئاً بعد أن استثناه البيان الرسمي.

لكن المحدد لا يساوي سياسة تصحيح. هل المطلوب الاستبعاد أم إعادة الحساب؟ ما أول وآخر صف متأثر لكل مسبار؟ ما النسخة المعتمدة من الإرشاد؟ وهل يوجد استثناء لمنصة معينة؟ لا تمنح release dates هذه الحدود، لأن يوم نشر 5120 ليس يوم تثبيته في كل مكان، ويوم نشر 5130 ليس يوم اختفاء 5120.

الاحتياط العام الممكن الآن هو الاستبعاد. عبارة «نصف RTT» لا تكفي لتفويض ضرب كل offset في ثابت. صفوف الأخطاء وإعادة المحاولة والفوارق المعمارية وحواف الانتقال تحتاج عقداً منشوراً واختبارات معروفة.

ثلاثة أزمنة لا يجوز ضغطها في تاريخي إصدار

هناك وقت نشر 5120، ووقت تثبيته فعلياً على كل مسبار، ووقت توليد كل نتيجة. هذه ليست ساعة واحدة. تاريخ 29 أكتوبر 2025 يثبت أن الحزمة أصبحت متاحة، لكنه لا يثبت أن كل مضيف أخذها في ذلك اليوم. وبالمثل، يثبت 12 أغسطس 2026 أن 5130 نُشر، لا أن كل صف لاحق لذلك اليوم خرج من 5130. بقاء 2721 سجلاً متصلاً على 5120 في 31 أغسطس هو الدليل العملي على الفجوة بين تقويم الإصدار وتقويم الأسطول.

لهذا يجب أن يعمل المحدد على مستوى النتيجة لا على مستوى التقويم وحده. يبدأ من fw=5120، ثم يربط prb_id والطابع الزمني وهوية النتيجة، ويضيف أول صف متأثر وآخر صف متأثر عندما تصبح هذه الحدود معروفة. وإذا تغيرت الحدود بعد مراجعة جديدة، لا تمحى السابقة؛ تسجل مراجعة أخرى بحيث يعرف المستخدم ما الذي تغير ولماذا.

يحتاج العميل كذلك إلى التمييز بين فعلين. الأول قرار جودة: لا تستخدم result[].offset في الصف المحدد. والثاني قرار اشتقاق: أنشئ قيمة بديلة بطريقة معتمدة. القرار الأول ممكن بصورة تحفظية اليوم. أما الثاني فيحتاج وصفاً قابلاً للاختبار للمدخلات والمعادلة والتعامل مع الاستثناءات، لا مجرد قراءة تفسير بشري للخلل. بهذه الحدود لا تتحول الصراحة في release note إلى ترخيص أوسع مما قالته RIPE NCC.

التحذير الذي لا يسافر مع البيانات يفقد جزءاً من سلطته

يمكن للإنسان أن يقرأ صفحة 5130 ثم يعدل استعلامه. لكن جامعاً آلياً يعمل ليلاً، أو أرشيفاً استلم ملفات النتائج فقط، أو فريقاً ثبت dataset قبل نشر التنبيه، لن يحصل تلقائياً على السياق نفسه. قد تبقى قيمة fw في الملف بينما تنفصل عنها الصفحة التي تشرح أثرها.

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

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

سجل التصحيح ليس لوحة انتشار النسخة

يمكن أن تنشر RIPE NCC إيصال انتشار يحصي المسابر المتصلة بحسب firmware ووقت الرصد. هذا يجيب: هل يتحرك الأسطول من 5120 إلى 5130؟ ولا يجيب: كم نتيجة NTP خاطئة بقيت في الأرشيف؟

أما سجل التصحيح فيحتاج معرفاً ثابتاً ومراجعة؛ اسم المنتج ومخطط النتيجة؛ 5120 ونطاق منصاته؛ result[].offset بصفته الحقل المتأثر؛ rtt بصفته غير متأثر؛ محدداً يجمع النسخة والمسبار وهوية النتيجة والزمن؛ الحدود الفعلية؛ إجراءً معتمداً؛ 5130 والـcommit؛ وقنوات الإخطار وتاريخ تعديل النص.

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

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

لقد قدم 5130 اعترافاً واضحاً، وقدمت صيغة Atlas مفتاح fw. تحويلهما إلى سجل واحد محمول سيجعل التحذير يعيش بقدر ما تعيش البيانات.

المصادر