摘要

  • draft-feng-netconf-naim-op-00 把补偿表示为一个或多个 Operation IR 对象，其目的可以是反转，也可以只是缓解已经执行的变化；草案同时明确要求实现考虑补偿失败、成组执行超时与回滚途中失联。
  • 共享事务标识解决的是“哪些操作属于同一组”，没有规定全有或全无提交、隔离、锁、顺序、持久日志或跨设备共同恢复点。
  • 可信的恢复结论必须把前向操作与补偿操作、各自授权、实时前置条件、并发写入、协议回执、操作后状态、独立服务验证和不可逆残留分别记录。

“反向操作”发生在一个已经改变的世界

设想一项自动化任务：把十个边缘接口切换到新路由策略，如果连通性检查失败，就把旧策略引用写回去。AI 代理表达意图，Handler 校验字段并开始下发。前三个设备接受了变化，第四个失联，服务检查失败。

此时的世界已不是生成计划时的世界。另一个控制器可能刚修正其中一个接口；对等网络已经看到路由变化；通知系统已经唤醒人工流程；某个恢复角色的权限比原操作角色更窄。把旧值写回，有可能在两台设备上正确，在第三台覆盖合法并发更新，在失联设备上甚至无法判断请求是否到达。

草案对 Compensation Operation 的定义非常克制：它是一项“意在反转或缓解”先前操作影响的操作。“意在”描述目标，不描述结果；“缓解”更明确承认，有些影响没有精确逆过程。补偿对象因此是一份行动主张，而不是时间倒流的证明。

Operation IR 把意图和协议执行分开

Operation IR 试图在自然语言意图与 NETCONF、RESTCONF 等网络管理协议之间提供一种协议中立的中间表示。它可以承载写入、读取、RPC 或 action、过滤器、datastore 选择、前置条件、动态表达式、事务元数据与补偿。AI 的角色是意图编码者；确定性的 Handler 负责依据规范上下文进行校验、读取实时状态、生成协议消息并执行。

这套分工值得研究，但不能夸大文档的成熟度。Datatracker 将 2026 年 7 月 18 日发布的 00 版列为活跃的个人 Internet-Draft；没有 RFC stream，也没有正式的 Intended RFC status，并明确说明任何人都可提交 I-D、该文档不获 IETF 背书、在标准流程中没有正式地位。投稿文本的页眉写着“NETCONF Working Group”和“Intended status: Standards Track”，那是作者提交的页眉声明，不是工作组采纳或 IETF 共识的证据。

草案还主动排除了自动推导补偿的算法、执行引擎调度细节与私有工作流逻辑。也就是说，不同 Handler 面对同一前向意图，完全可能构造不同的补偿步骤。审计记录若只写“已触发自动回滚”，便丢失了真正需要检查的对象：到底对什么目标、以什么值、在什么 datastore、依据什么假设，生成并执行了哪一组操作。

事务标识负责串联，不负责原子性

第 12 节说，多个 Operation IR 对象可以通过一个共享事务标识关联。关联非常重要，它让分散的日志有机会拼成同一条执行链。但草案没有说这个标识创造了全有或全无的 commit，也没有规定可串行化隔离、全局锁、强制顺序、持久事务日志或唯一回滚点。

跨系统操作会立即暴露这一区别。一台设备可能支持 candidate datastore 与 confirmed commit；另一台直接修改 running；第三步或许调用具有外部副作用的应用 action。同一个标识可以把三者放进一份报告，却不能让三者拥有相同的能力、时钟或故障语义。

顺序同样不能靠“反向执行”四个字解决。创建策略、绑定策略、激活服务之间存在依赖。恢复时通常应先解绑再删除；可是，如果其他业务已经合法引用了该策略，删除就会制造新故障。语法上精确的逆操作，面对新的实时状态仍可能是错的。

补偿要重新取得权力

草案要求补偿操作接受与普通操作相同的授权、校验和日志预期。安全章节又单独列出补偿操作的授权，以及执行与回滚的审计日志。这不是重复措辞，而是关键控制面。

前向动作的权限不能自动继承给补偿。创建对象与删除对象可能需要不同权限；某个角色可能已过期；动态引用再次求值时可能指向另一个目标；故障期间访问策略本身也可能变化。RFC 8341 对 NETCONF/RESTCONF 的操作与数据节点分别实施访问控制，“为了恢复”不是绕过控制的通行证。

前置条件能够防止明显的陈旧写入。Operation IR 可以要求某个路径在执行前仍等于期望值；不满足时不得执行。但通过前置条件只说明某一时刻的一次读取成立，并不证明随后写入成功、持续存在或让服务恢复。每个补偿步骤都应保留主体、现行策略、解析后的目标、读取值、授权决定和执行结果。

恢复路径本身也会失败

草案要求支持事务的实现定义多种失败行为：前置条件失败、事务中途失败、补偿失败、成组执行超时，以及回滚期间连接丢失。这一列表把“回滚”重新放回分布式系统的真实世界：恢复不是故障模型之外的特权动作。

在请求发出后链路中断，Handler 可能无法区分“设备未收到”“已应用但响应丢失”和“部分应用”。盲目重试可能重复非幂等副作用；直接放弃又可能留下半成品。一个 rolled_back: true/false 无法表达这些状态。至少应区分已计划、已授权、已检查前置条件、已发送、已确认、已独立观察与已验证服务；未知必须作为未知保留。

NETCONF 的窄回滚反而说明边界多么重要

RFC 6241 给出了一个更窄的参照。当服务器声明 rollback-on-error 能力时，edit-config 在发生错误后可以停止，并把所指定的配置恢复到该次操作开始时的完整状态。这是绑定到具体能力、协议操作与配置范围的语义。

即便如此，RFC 仍警告：在共享配置上，如果没有先加锁，回滚可能意外更改或删除其他 NETCONF 会话的变化。它还定义了 rollback-failed 错误。confirmed commit 也依赖自身能力与 candidate datastore。

Operation IR 的补偿可能被映射到这种机制，也可能被编译为 RESTCONF 写入或业务 action。某个后端最强的保证，不能因为大家都叫“回滚”就扩展到整组操作。协议内配置恢复，更不能自动证明跨协议、跨设备和面向用户的结果全部恢复。

配置相同，不代表历史相同

RFC 8342 将预期配置与运行状态区分开来。即使某个配置子树与快照一致，设备实际应用、学习或派生出的状态仍可能不同。离开 datastore，差距更明显：已经转发的包收不回来，已经被消费的通知无法取消，已经暴露的凭据不会因删除配置重新成为秘密，超时、计费记录、客户告警与人工决策也已进入历史。

补偿完全可能成功，却只能构成缓解而非复原。问题不在补偿机制，而在仪表盘把“补偿完成”自动改写成“无影响”或“恢复原状”。诚实结论必须说明：哪个建模范围回到了参考值，哪个范围无法观察，哪些外部影响仍然存在。

Dry-run 展示计划，而不是预言

草案规定 dry-run 不得实际改动目标，并建议预览解析后的对象、输入值、datastore、前置检查、协议消息摘要、补偿计划、已知副作用及限制。它也坦承：当实时依赖、授权结果或外部条件只有执行时才能确认，预览可能不完整。

因此，一张绿色预览卡只有在显著展示未知项时才有意义：哪些目标基于快照解析，哪些权限尚未检查，哪些外部系统无法模拟，哪些副作用根本没有逆操作。结构化预览帮助人作决定，但不会把未来变成确定事实。

恢复证据应是一条链

每个事务至少应分开保存：不可变的前向 Operation IR 与语义上下文版本；Handler 使用的完整模型；每步授权；带时间戳的前置条件读取；实际生成的协议消息；按顺序记录的确认、失败与超时；准确的补偿对象；补偿自己的授权与校验；锁与并发写入；补偿后的配置和运行状态观察；无法撤销的外部残留；以及来自 Handler 之外的服务验证。

最终状态也应拆成三层：“已尝试补偿”“在声明范围内恢复建模状态”“服务已恢复”。前一层不能自动推导后一层。事务标识把证据接起来，却不能替代证据。

来源