结论先行：策略开错之后把责任平摊给"申请、审批、执行"三方，是最省事也最没用的处理方式。三段各自掌握的东西不一样：申请人掌握需求真不真，审批人掌握该不该，执行人掌握有没有照单做。责任要落在"本来能改变结果却没改"的那一段，其余两段只承担配合说明的义务。
本文只谈策略变更出错之后的责任回溯顺序与证据来源，不谈变更流程怎么设计，也不谈事故当时的止损动作怎么排。
为什么不能平摊
平摊看起来公平，实际后果是三方都学不到东西。申请人下次还会把"临时开通三个月的测试通道"写成普通开通需求，因为他觉得自己只是提需求；审批人下次还会扫一眼就批，因为"执行的时候会再看"；执行人下次还会照着单子敲，因为"批都批了"。
更麻烦的是，平摊会让追责这件事本身失去意义——三方都有责任等于三方都能说"我也有责任，但不能全怪我"，最后落到一句"流程需要优化"。真正要回答的问题被绕掉了：这条策略为什么会以这个范围、在这个时间点、落到这台设备上。
三段各自该看什么
申请人这一段
判据是需求描述与实际业务是否一致，以及期限有没有写清。常见的三类问题：把临时需求写成长期需求；把"某个网段"写成"整个区域"；只写"要通"，不写"通到哪里、通多久、谁能用"。这三类都不是技术判断，是需求表达问题，只有申请人能改。
这一段的责任通常落在业务侧或项目侧，而不是技术侧。把它算到执行人头上，等于承认需求描述不需要准确。
审批人这一段
判据是有没有看范围、有没有按既有规则批、对超出常规的需求有没有升级。审批这一环的价值不在签字本身，在"看到不该批的东西时说停"。如果审批人拿到的材料和执行人拿到的是同一份，且没有额外的判断依据，那这个环节在制度上存在、在事实上空转。
有一种情形值得单独提：审批人批了，但批的范围和申请人要的范围不一致，执行人按申请人的范围做了。这种错在事后最容易扯不清，因为它不是任何一方单独造成的，是单子没对齐。
执行人这一段
判据只有三条：有没有照审批单执行；下发之后有没有做验证；发现异常有没有停下来。第三条最关键。变更现场最容易出现的错，是执行人在敲命令的过程中发现了不对劲，但想到"单子已经批了、窗口只剩二十分钟"，就按下去了。
这一段还有一条常被忽略的责任：验证。策略下发成功和策略生效不是一回事，配置进了设备、规则顺序排错了、被前面的规则遮蔽，现象都是"下发成功"。谁做的下发，谁负责给出验证结果，这条不能转移给申请人。
证据从哪几个地方取
没有留痕的追责只能靠回忆，而回忆在事故之后通常已经对齐过了。可用的证据来源大致是五处：工单里的需求原文；审批链上的意见与时间戳；下发记录（谁、什么时候、从哪个入口、下发到哪些设备）；设备侧的规则描述字段；回退记录。
其中设备侧的描述字段最容易被跳过。策略表里的备注、描述这类字段，长度有限、批量下发时会互相覆盖、历史策略往往是空的——所以它不是可靠的证据源，只能作为旁证。真正能定顺序的是审批链和下发记录这两处，它们带时间戳，改不了。
反过来说，如果这几处对不上，比如工单说批了三台、下发记录显示八台，那么问题就不在三段责任的划分上，而在流程本身有绕过审批的路径。这种时候追谁的责任都是次要的，先把那条路径堵上。
恢复动作不能等责任定完
一个现场规律：事故之后如果先开会定责任，业务恢复通常会晚一到两个小时。原因不复杂——参会的人在等自己那一段被排除，没人愿意在自己还可能是责任方的时候主动提出回退方案。
所以顺序应该是恢复在前、定责在后。但恢复动作本身必须留痕，否则会出现更难处理的局面：回退之后现象消失了，原始状态没了，谁都说不清了。回退前存配置、存截图、存当时的规则顺序，这几步花不了十分钟。
落地清单
- 追责前先做一件事：把需求原文、审批意见、下发记录、回退记录四份材料摊在一张桌上对齐。
- 按"谁能改变结果"归段，不按职位高低归段。
- 执行人这一段只核三条：照单、验证、发现异常是否停。
- 把"下发成功不等于生效"写进岗位要求，验证结果由执行人返回。
- 恢复优先于定责，但恢复过程必须留痕。
这套顺序对采购方也有用。签合同的时候问一句：变更出错之后，你们怎么分责任、依据哪几份记录——回答里如果只有"我们有严格的流程"，那多半意味着追责那天要靠开会吵架解决。深圳市奇摩计算机有限公司在承接这类运维项目时，会把变更的申请、审批、配置、回退四段都放在同一条线上留痕，目的不是防客户，是让半年后的一次回溯不需要靠回忆。