变更控制流程图（change control）
变更控制流程模板：提出申请、影响与风险评估、CAB 审批、带回滚方案的实施、验证与结案，另含一条成文的紧急通道。
什么是变更控制流程图（change control）流程
变更控制就是介于“有人想改点什么”和“变更已经上线”之间的那一连串关口。每一道关口都留下一条记录：申请了什么、影响评估发现了什么、谁批准的、什么时候执行的、验证是否通过、评审得出了什么结论。在 IT 与工程团队里，它通常以 ITIL 式的变更管理来运行，配一个 CAB；在受监管的质量管理体系里，它是那套防止已验证流程发生漂移的受控变更程序。两处的流程形态是一样的。
变更控制的失败大多是交接的失败，而不是流程本身的失败。申请人不知道评估需要哪些信息，CAB 看的是一条工单评论串而不是一份评估记录，实施人做出一个没有回滚的方案，事后又没有人把记录关闭。这也是这份模板被画成泳道的原因：申请人、变更负责人、CAB、实施人与 QA 各自拥有特定的步骤，而图让工作在哪里易手变得一目了然。
团队最常不写下来的两条分支，恰好也是事后争议最多的两条：紧急通道，以及被驳回的变更该怎么办。这张图把两者都画了出来。紧急变更由 CAB 主席作出加急授权，并汇入完全相同的实施与评审路径，因此它们永远不会成为没有记录的变更。被驳回的变更带着 CAB 的意见回到申请人，并进入一个决策点：要么回到重新评估，要么把申请关闭为暂缓。
本流程图涵盖的内容
本模板包含
- 申请人与变更负责人两条泳道上的受理与分流：提出变更申请、登记进变更登记册，然后是一个三向的变更类型决策，把标准变更直接送往实施规划，把常规变更送入影响评估与 CAB 审议，把紧急变更送到 CAB 主席
- 评估：评估影响与风险，与申请人确认范围和停机时段，并把结果汇总进一份评估记录，让 CAB 审的是一份文件，而不是一串评论
- CAB 泳道中的决策点：CAB 审议变更申请，随后批准它进入实施规划，或者把它驳回给变更负责人
- 驳回与暂缓分支：CAB 的意见返回申请人，申请人要么修改后重新提交——回到影响评估——要么把申请关闭为暂缓
- 紧急通道：紧急变更通过 CAB 主席的加急授权跳过常规的 CAB 议程，随后汇入完全相同的规划、实施与评审路径
- 实施人与 QA 泳道中的实施与验证：规划实施方案与回滚方案、安排变更时段、执行变更，然后由 QA 测试并验证。验证不通过会触发回滚方案并回到规划；验证通过则进入实施后评审并关闭变更记录
何时使用本模板
- 你们要为 IT 运维或平台团队记录一套 ITIL 式的变更管理程序，包括谁在 CAB 中、以及他们在决策之前看到的是什么
- 你们要为质量管理体系编写受控变更 SOP，其中对已验证流程或产品的变更需要一份成文的影响评估和一位具名批准人
- 你们要带新的变更负责人、CAB 成员或值班工程师上手，他们需要知道哪些变更需要审批、哪些不需要
- 你们想在 Jira、ServiceNow 或某个 QMS 中把它配置成工作流之前，先把谁批准什么定下来，让工具承载一个已达成一致的流程，而不是自己发明一个
- 客户或审核员询问变更是如何被批准、测试和回滚的，你们需要一份可以指过去的成文流程
运作方式
把泳道改成你们真实的角色
把申请人、变更负责人、CAB、实施人与 QA，换成你们实际拥有的角色与团队。如果同一个人既是变更负责人又是 CAB 主席，就把这两条泳道合并，而不是假装它们是分开的。把泳道数量控制在五条或以下，图才保持可读。
在分流决策处定义你们的变更类别
变更类型决策已经分出标准、常规与紧急三类。写下在你们组织里各自的资格条件，并把这些界线放在决策旁边。按风险与影响范围来划分，而不是按工单大小；并且让预先批准的标准变更清单短到真的有人愿意维护。
指定变更授权方及其会议节奏
在 CAB 审议这一步记下：批准人是谁、他们多久开一次会、进入议程的截止时间是什么时候。另行说明紧急授权方，因为有权批准非工作时间抢修的，通常不是整个委员会。
写明评估记录必须包含什么
把评估这一步变成一张真正的检查表：受影响的服务与用户、停机时段、风险等级、依赖关系、测试方案与回滚方案。CAB 的决策不可能好过这份记录，而它同时也是这次变更留下的审计轨迹。
设定回滚与验证的规则
决定由谁执行回滚、需要多长时间、什么条件触发这个决定。然后定义验证在你们这里意味着什么：冒烟测试、回归测试套件，还是服务负责人的签署确认。如果你们的政策是立即回滚而不是重新规划，就相应调整验证失败的回路。
把它发布出去，并保持版本管理
把图分享到工作真正发生的地方——变更申请表单旁边，或者运行手册里。每当有一次变更出了问题，就把它重看一遍；并保留历史版本，以便说明程序是何时改的、为什么改。
常见问题
变更控制与变更管理有什么区别？
变更控制是狭义的、程序性的那一部分：一项具体的拟议变更如何被提出、评估、授权、实施、验证与结案，并在每一步留下记录。变更管理的范围更宽，包含策略、类别、角色、沟通，以及流程本身的持续改进。这张流程图画的是变更控制程序，而它通常是最先被记录下来的东西，因为它才是大家日常真正遵循的。
谁应当批准一项变更，是不是所有变更都要过完整的 CAB？
不是。把每一项变更都送过整个委员会会制造排队，而排队会促使人们绕开流程。多数团队采用三档：有成文操作方式、无需审议的预先批准标准变更；送交 CAB 的常规变更；以及由单一具名授权方（通常是 CAB 主席或值班负责人）批准的紧急变更。按风险与影响范围来划定界线，而不是按工单大小，并把它们写在分流决策旁边。
紧急变更怎样才能既走得通、又不架空流程？
紧急变更压缩的是审批，而不是取消审批。在这张图里，紧急分支跳过了常规的 CAB 议程，但仍然要拿到明确的授权，仍然要走带回滚方案的实施规划，也仍然会落到实施后评审与结案。多数团队最终采用的实用规则是：在几分钟内口头批准，但当天就把变更记录写好，并在下一次 CAB 会议上复核每一项紧急变更，确认这个类别用得是否站得住脚。
被 CAB 驳回或暂缓的变更会怎样？
它们需要一个明确的结局，否则会以无记录的工作重新冒出来。在这份模板里，变更负责人把 CAB 的理由带回给申请人，申请人随后面对一个决策：修改并重新提交，从而回到影响评估和第二次审议；或者接受这一结果，把申请关闭为暂缓。记录理由和记录决定同样重要，因为暂缓的变更通常会在阻塞的依赖关系解除之后再度回来。
这和文件变更控制或 SOP 变更控制是一回事吗？
不是一回事。这张图对应的是通用的、偏 IT 运维口味的变更控制：一个 CAB、一份回滚方案，加上一步部署与验证，都是为系统与服务层面的变更而设计的。/zh/templates/文件变更控制流程 与 /zh/templates/SOP变更控制流程 是同一形态针对特定文件类型的更窄变体，CAB 换成了文件评审人与审批人，回滚方案换成了对已作废版本的撤回。如果你们真正想要的是版本控制与变更控制之间的概念区别，而不是一张图，请参见 /guides/version-control-vs-change-control。