摘要

  • draft-ietf-nmop-network-incident-yang 第 16 版明确选择让事件模型独立于置信度；第 17 版仍能结构化表达“可能根因”，但不携带评分、分析者身份、模型版本或校准记录。
  • 相邻的 NMOP 异常生命周期和语义草案却保留 confidence、concern、annotator 与版本。风险不在于分层本身，而在于异常被汇总成事件时，上游证据封套被丢弃、原因标签却继续流转。
  • 原因分类不是修复授权。自动化需要把观测、分析版本、竞争假设、阈值、事件修订、授权动作和实际服务结果连接成可追溯记录。

一张过于整洁的事件卡片

假设值班屏幕上出现一条严重事件：节点和接口已经定位，原因名称是 interface-hardware-failure，关联事件是 loss of signal，优先级为 critical。每个字段都很规整，读者很容易把“规整”误读成“确定”。

换一组问题，画面就不同了。这个判断来自光功率阈值、拓扑规则、人工工程师，还是学习模型？分析器给出的 confidence 是 52 还是 98？使用的是哪个版本？它看到了多长时间窗？第二候选原因是什么？后来补到的数据是否会改写排序？

基础事件对象没有回答这些问题。第 17 版的修订记录明确写着：第 15 版到第 16 版的变化之一，是让事件模型保持“independent of confidence”。对比文本可以看到，第 15 版曾说相邻的异常检测文件会用 confidence 和 concern 给结果评分；第 16 版删去了这句评分说明，但保留了与异常检测架构的关系。第 17 版延续了这种边界。

这不是说置信度不重要，而是说公共事件词汇不负责统一所有判断方法。它描述一个可以在多系统之间交换的运营对象，不替运营者规定唯一的“相信方式”。

事件核心知道什么

第 17 版允许先创建事件、后补来源。sources 列表可以为空，诊断完成后再填入。原因一旦形成，probable-causes 可以引用网络、节点和资源，写入基于 identity 的 cause-name 与细节；probable-events 可以回指相关事件。domain、priority 和 category 在事件分组中是必填项。

这套结构解决了真正的互操作问题。下游不必从一段自然语言里猜“光信号丢失”“路由误配置”“服务误配置”是否属于同一类。节点与资源引用限定了对象，原因 identity 提供共同词汇，事件引用保留了回看观测的入口。

但“字段精确”不等于“判断可靠”。priority 说明处理紧迫性，不是诊断正确概率；category 说明类别，不是校准结论；相关事件说明联系，不自动证明充分因果；identityref 让名称可交换，不会把名称变成事实。

草案对 Probable Root Cause 的定义反而很严格：完整移除该故障条件，应当终止正在发生的事件并防止复发；仅仅影响结果的条件只是 contributing cause。可是原因对象本身没有记录移除试验、反事实验证、复发观察窗或竞争解释。定义规定了语义门槛，不等于每个实例都已经通过验证。

置信度没有消失，它留在上游

相邻的 draft-ietf-nmop-network-anomaly-lifecycle-07 把 confidence 与 concern 分开。confidence 是 0 到 100 的异常判断强度；concern 是 0 到 100 的关注与行动程度。它还能记录异常版本、阶段、annotator 的身份与名称、annotator 是人还是算法，以及其版本。Detection、Validation、Refinement 构成循环，允许判断被纠正。

draft-ietf-nmop-network-anomaly-semantics-06 又把这些内容放进序列化词汇：strategy、confidence、concern、annotator type、annotator version 都有明确位置。示例中的 confidence 也可以是 null。这一点很重要：保留封套不等于制造确定性，封套自己也可能不完整。

因此，真实边界是：同一运营环境可以在上游拥有丰富的异常产生与评估记录，而归一化事件只保留被选中的原因和相关事件。如果两者有稳定连接，分层是清楚的；如果连接丢了，下游看到的原因会因为限定信息消失而显得更确定。

这是压缩的代价。把海量告警、指标和异常合成少量事件，可以大幅降低噪声。但压缩一定会选择哪些信息继续存在。原因名称因为便于派单和自动化而被保留，分析器版本、落选假设和校准背景却可能被当作临时分析数据。几周以后，修复系统只看到耐久标签，不再看到标签形成时的犹豫。

Confidence、concern 与 priority 是三件事

高 confidence 不一定高 concern。一次规律性的流量偏移可能非常“异常”，却对服务没有伤害。低 confidence 也可能高 concern：一条并不充分的信号若指向承载关键业务的光路故障，仍值得谨慎调查。事件 priority 又是第三个维度；潜在损害很大时，即使首选原因仍不确定，也可能需要 critical 处置。

所以，把一个分数复制到三个位置，比基础模型不带置信度更危险。不同检测器的 90 分未必可比较，它们的样本、规则、时间窗与校准方法可能完全不同。让公共事件对象独立于方法，可以避免把本地量表冒充全球量表。

相应的运营责任是：不能因为公共对象不带分数，就把三种判断压成一个红黄绿灯。方法独立必须配合证据可追溯，而不是证据遗忘。

权限决定谁能做，不决定原因是否正确

第 17 版要求 YANG 管理协议使用安全传输与相互认证，并引用 NACM 限制操作和内容访问。这些控制十分必要。事件对象可能暴露客户 VPN、端点以及网络故障形态；诊断与修复操作也可能占用资源或影响在线业务。

认证可以说明谁建立了管理会话，NACM 可以说明这个主体是否有权读取原因或发起动作。它们都不能校准诊断。一个完全获得授权的主体仍可能依据证据薄弱的原因行动；一个高 confidence 的原因也不会自行生成变更权限。

因此至少要保留两条独立链：原因为何值得相信，以及谁依据什么制度被允许行动。把两者混在一起，就会让分析分数获得它不应拥有的制度权力。

“有运行代码”也有证据边界

草案的 Implementation Status 写明，Huawei iMaster NCE 已实现与 intent management 和 AI tools 配合的事件模型，覆盖 RESTCONF、事件生命周期、通知和事件列表查询。这是有价值的运行代码线索。

同一章节也明确说明：信息由贡献者提供，IETF 没有验证，列入不等于背书，也不是实现目录。冻结来源没有给出置信度与 annotator provenance 如何穿过事件生成的互操作轨迹，没有准确率或校准报告，也没有生产事件结果。

严谨结论既不是“没有实现”，也不是“架构已经被证明”。文件记录了一个具名实现；证据封套是否被完整保留，仍需实测。

与旧文的分界

BTW 已有 A Cleared Incident Does Not Prove Which Command Cleared It，研究的是第 14 版里 incident-resolve 请求与稍后 cleared 通知之间缺少请求关联的问题。它问的是：哪条命令造成了状态变化？

本文问的是后续版本才明确的问题：在任何命令被选择以前，原因判断携带了哪些认知证据？再完美的 request ID 也无法恢复已经丢失的 confidence；再准确的原因也仍需独立授权；再好的动作关联也不能替代服务结果验证。认知因果与执行因果发生在不同接缝，不能互相覆盖。

来源