الخلاصة

  • تفصل المراجعة 14 من مسودة NMOP بين دورة الحادث الشبكي raised وupdated وcleared، ودورة عمل المشغّل acknowledged وdiagnosed وresolved.
  • قد يستهدف incident-resolve عدة حوادث، ثم تظهر النتيجة في إشعار مستقل غير متزامن. وأشارت مراجعة YANG Doctors إلى غياب وسيلة لربط الإشعار بطلب RPC الذي أنتجه.
  • ينبغي أن يحفظ إيصال من الأمر إلى cleared هوية الطلب والتفويض والأهداف والتنفيذ والإشعار وربط التذكرة واختبار الخدمة. هذا اقتراح تحريري وليس مطلباً من IETF.

الرقم يثبت هوية الحادث لا نسب النتيجة

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

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

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

فصل دورتين يمنع اختصاراً خطراً

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

وتضيف الاعتبارات التشغيلية نظام التذاكر. تطلب المسودة طبقة ترجمة حتمية بين حالات YANG وحالات مثل Open وAssigned وIn-Progress وResolved، منعاً لانقسام الرؤية بين طبقة الشبكة وطبقة OSS.

الحتمية تعني أن القاعدة تعطي النتيجة نفسها للمدخل نفسه؛ لا تعني أن المدخل يثبت سببه. ترجمة cleared إلى Resolved قد توحّد الشاشتين بسرعة، لكنها قد تنقل يقيناً لم يُبنَ على رابط بين الأمر والنتيجة.

المراجعة الرسمية حددت الفجوة

في 31 أغسطس، منحت مراجعة YANG Doctors الوثيقة نتيجة Almost Ready، ثم ذكرت أن نتائج RPC تصل عبر الإشعارات من دون طريقة لتحديد أي إشعار نتج من أي RPC. وطرحت السؤال نفسه حول التشخيص، كما طلبت توضيح آلات الحالات، ومعرّفات الحوادث، والقوائم الخالية، وبنية الأخطاء، ومصدر الإشعار ووجهته.

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

كما تسجل محاضر NMOP في IETF 126 نقاشاً عن علاقة مفتاح القائمة برقم الحادث ومعرّفه. وهي تثبت أن الهوية كانت موضع فحص، لا أنها تقدم حكماً نهائياً.

المصادقة تحمي الفعل ولا تفسر الأثر اللاحق

تضع المسودة النموذج خلف NETCONF أو RESTCONF بنقل آمن ومصادقة متبادلة. ويستطيع NACM تقييد المستخدمين والعمليات والبيانات. وتوجد أسباب فشل مثل بقاء السبب المرجح بلا حل، أو رفض الإذن، أو انتهاء المهلة، أو عدم توافر المورد.

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

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

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

الأمر الجماعي يوزع الفضل والمسؤولية

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

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

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

اجتياز التحقق ليس اعتماداً تشغيلياً

بدأت المراجعة النهائية في مجموعة NMOP في 19 أغسطس وانتهت في 3 سبتمبر. عند تجميد الأدلة في 9 سبتمبر، ظل Datatracker يعرض In WG Last Call بلا مدير منطقة مسؤول أو موعد IESG. المراجعة 14 مسودة نشطة مقصودة لمسار المعايير، وليست RFC ولا موافقة نهائية.

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

إيصال يستطيع قول «غير معلوم»

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

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

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

يسأل The Policy Mirror أين كُتبت السلطة: يمنح NACM الإذن، وتسجل RPC النية، ويكتب مخزن الحوادث المشاهدة، وتكتب التذكرة خاتمة المؤسسة، ويواجه اختبار الخدمة الواقع. ويطالب Running-Code Primacy بأن تلتقي هذه الأدلة في التنفيذ. أما Reality, Not Advocacy فيحصر النتيجة: تمنح المسودة لغة مفيدة للحوادث، لكن cleared لا يثبت سبب نفسه.

المصادر