摘要

  • RFC 9940 将 Value、Event、Fault、Problem、Symptom、Cause、Alert 和 Alarm 分成不同的管理对象；图示解释这些对象如何关联，并不自动授权补救动作。
  • 一项告警可以显示不希望出现的资源状态；即使操作员把工作关闭，原因、服务恢复和下一步变更的授权仍应有各自的证据。

监控面板从绿变黄，通常不是小事：某项特征的数值发生变化，系统认为它与政策有关，于是把它送给人或自动化处理。真正的风险不在这一步，而在随后把整个过程压缩成一句话：“故障导致中断，系统已经修好。”这句话至少混合了观测、分类、因果判断、授权和效果五类主张。

RFC 9940 是 IETF 于 2026 年 4 月发布的信息性文件，为网络层及以下的网络故障与问题管理定义术语。它服务于报告、呈现和管理故障的问题模型与管理协议，目的在于让不同组件说清同一件事。它不是根因发现协议，不证明某项服务已恢复，也没有把修改另一系统的权力交给告警。

这套术语从可核验的对象开始。Characteristic 是资源可观察或可测量的方面，Value 是其测量值；Change 是数值随时间的变化，Event 则是在一个可区分时刻发生的变化。Condition 是对一个或多个数值的解释，State 是资源在某一时刻所处的条件。也就是说，从数值到状态已经跨过一次解释：取样频率、比较窗口和阈值都会影响结果。一条丢包读数本身，并不自动等同于服务处于劣化状态。

之后还要经过政策。Relevance 取决于政策、视角、意图以及其他事件、状态和值；Occurrence 是被认为相关的事件或变化。Fault 是不希望出现的 Occurrence，可能指向现在或未来不希望出现的 State；Problem 是可能需要补救的不希望状态，却未必能归到一个 Cause。Symptom 指示 Problem；Cause 可以由多个 Fault、Problem 和 Symptom 指出或确定。Alert 指示 Fault；Alarm 表示资源存在需要纠正关注的不希望状态。

系统看似恢复时，这些区别尤其重要。RFC 9940 用“光路丢失”说明：服务可以恢复，但近期故障仍未解释；修好一处光纤微弯，能够回答一个直接原因，却未必回答怎样避免再次发生。因而“现在流量正常”是一项当前状态证据，不是抹掉历史问题、因果不确定性和预防责任的总开关。

RFC 8632 把同一条界线落实到告警数据模型中。候选根因资源只是给客户端的提示，不是归责结论。它还明确区分告警的 is-cleared 和操作员的 closed：前者说明观测到的条件被清除，后者说明操作员认为纠正工作成功。二者可以同时为真，却不能各自证明测量覆盖面、真正根因，或所有依赖服务的结果。

遥测也不应吞没“意图”。RFC 9940 依次讨论遥测、监控、分析和可观测性，并明确遥测数据本身不含服务定义意图。RFC 9315 将 intent 定义为声明式目标和结果，而网络不会自动知道某个运营者的具体目标。RFC 9417 又把 metric、symptom、health score 和无法获取 metric 的情形分别定义。健康分数可以排定调查优先级，不能单独授权撤路、计费、关闭事故或承诺客户结果。

Daniel Kade 将 docs/heng-lu-note.md 中现实层次的区分作为编辑透镜，而非 IETF 新规则：原始读数、阈值与政策、分类、因果假设、获授权的决定、实际变更和变更后的观测应是不同记录。这样，系统可以迅速提醒，也不会让一个熟悉的标签替代完整证据链。

来源