如何创建变更控制流程
如何设计变更控制流程：定义变更类别，把预批准清单保持简短，要求每项变更都有回滚计划，并如实画出紧急通道，而不是假装它不存在。
变更控制流程规定一项拟议变更如何被评估、授权、实施、验证和关闭——由变更类别决定每项变更需要接受多严格的审查。
简而言之
- 三个类别：标准、常规、紧急——按风险和影响范围划分，而不是按规模。
- 预批准的标准变更清单要短到有人愿意维护它。
- 评估记录该包含什么，属于流程的规定，而不是提交人的判断。
- 每项变更都要有回滚计划，而回滚之后回到计划环节，不是就此结束。
- 把紧急通道画出来；否则就会有一条没有记录的紧急通道。
按变更对象选择流程
类别决定了这个流程会不会被使用
变更控制的成败取决于它的类别划分。把每一项变更都送进每周一次的变更委员会，人们就会想办法不提变更，于是控制问题变成了看不见的问题。预批准的范围放得太宽，委员会审的又都是无关紧要的东西。类别定义——标准、常规、紧急——才是真正的设计工作，而它们通常写得最晚，也最含糊。
第二件值得做对的事是评估记录。变更咨询委员会的水平不可能高于呈到它面前的材料，而把步骤名称写成“评估影响与风险”，几乎必然带来参差不齐的提交内容。明确规定这份记录必须包含什么——受影响的服务、停机窗口、风险等级、依赖关系、测试方案和回滚方案——才能让委员会的决定从一种印象变成一次真正的评审。
下面的示例是一个横跨五条泳道的变更控制流程。它包含任何可用流程都需要的三条通道：完全绕过委员会的标准变更、经过评估和 CAB 的常规变更，以及拥有独立授权人的紧急通道——外加一条回到计划环节而不是就此结束的回滚路径。
这个示例以 IT 服务变更为主。若要改的是已发布的实物零件、图纸或 BOM，请看 /zh/templates/工程变更申请流程 的 ECR-014：除了评估与授权，还须记录零件版本、生效批次、旧库存的已批准处置与首件验证。获批后的文件修订接到 /zh/templates/文件变更控制流程，再把发布证据交回变更负责人结案。
一个流程，三条通道
从提出到关闭的变更控制流程。注意分流决策如何把三个类别送上三条不同的路径。
分流决定了下游的一切
提出变更、登记进变更台账，然后是一个三向的类型判断。标准变更直接进入实施，常规变更进入评估，紧急变更走自己的授权通道——一个决策就决定了整项变更的成本。
评估就是委员会的输入
评估影响与风险、确认范围和停机窗口、记录评估结果，然后是 CAB 评审与批准。如果没有规定这份记录必须包含什么，委员会就会把会议时间花在索要信息上，而不是做决定。
被驳回是一条通道，不是终点
CAB 的意见回到提出人，提出人可以修改后重新提交，也可以接受延期——紧急通道带着自己的授权在这里汇入。没有修改回路的流程，只会让变更被放弃，而不是被改好。
在变更之前先规划回滚
实施方案与回滚方案一起规划，安排窗口，然后实施变更。回滚方案与变更同时规划，才会是真的；事后补写的回滚方案只是一段没人验证过的文字。
验证，失败就回到循环
测试与验证，失败则执行回滚并退回计划环节，随后是实施后评审与关闭。以实施为终点的变更控制流程，根本无从知道自己的变更是否奏效。
运作方式
定义你们的三个类别
写下在你们组织里什么算标准变更、什么算常规变更、什么算紧急变更，依据是风险和影响范围，而不是工作量。对支付系统改一行配置不是标准变更；一次规模很大但已反复演练过的例行部署，反而可能是。
预批准清单要短，而且要有人负责
标准变更只有在清单被持续维护时才成立。给它指定负责人和复查日期，并要求一项常规变更反复证明自己之后才能进入清单。无人维护的标准清单，最终会变成所有变更都走的那条路。
规定评估记录的内容
把评估这一步变成一张检查表：受影响的服务与用户、停机窗口、风险等级、依赖关系、测试方案、回滚方案，以及已征询过谁的意见。这是对变更咨询委员会作用提升最大的一处改动。
指定变更授权方及其会议节奏
谁批准、多久开一次会、议题的截止时间。然后单独指定紧急授权人——有权批准非工作时间抢修的，很少是整个委员会，而把这一点留白，正是紧急变更最终无人批准的原因。
要求回滚计划，并明确由谁下令
每项变更都要有一份，与实施方案一起规划。事先决定谁有权触发回滚、回滚需要多长时间，以及达到什么阈值就下令——事故进行中，没有人愿意还在解读一份制度。
如实画出紧急通道
每个组织都有紧急通道。给它判定标准、指定授权人，并要求事后在固定期限内补上回顾记录。画出来并带有文档义务的紧急通道是一项控制项；没画出来的那一条，只是凌晨两点实际发生的事。
应避免的错误
所有变更走同一条路
把琐碎变更也送进每周的委员会，只会教会大家绕开流程，于是真正重要的变更反而看不见了。
评估要求含糊不清
委员会变成索要信息的场合，而不是做决定的场合，而批准的质量取决于谁的提交材料写得最好。
回滚方案在计划之后才补
事后想出来的回滚方案未经验证，而且经常根本行不通。两者一起规划，否则等于没有。
假装没有紧急变更
拒绝把紧急通道写下来并不会让它消失——消失的只是判定标准、授权人和记录。
创建自己的变更控制流程
把变更控制示例打开为你们自己的图表，写入你们的类别定义，并指定你们的变更授权方。
相关指南
常见问题
变更控制和变更管理有什么区别？
变更控制是程序性的那一部分：一项具体的拟议变更如何被提出、评估、授权、实施、验证和关闭，并在每一步留下记录。变更管理的范围更宽——流程本身的策略、类别、角色、沟通与改进，在有些组织里还包括组织变革中与人相关的全部内容。人们首先需要画出来的流程图几乎总是变更控制，因为那是他们每天要遵循的东西。
标准变更、常规变更和紧急变更分别是什么？
标准变更是预先批准的、低风险且可重复的变更，因此不经委员会，直接按既定程序执行。常规变更要走评估与授权。紧急变更由一个精简的授权方批准，因为等待常规通道所造成的损害会大于这项变更本身的风险。三者都应按风险和影响范围来定义，而不是按规模，并要求紧急变更在固定期限内补齐记录。
变更咨询委员会应该由谁组成？
应当是能够评估影响、并能代表受影响服务发言的人：服务负责人、运维、必要时的安全人员，以及一位代表客户或业务影响的成员。人数要少到能做决定，并设一位有决定权的主席。十五个人的委员会不会认真评审任何事——而如果某位成员从未提出过任何疑问，那他只是在出席，不是在评审。
变更验证不通过时应该怎么办？
执行回滚并回到计划环节，而不是在时间压力下试图向前修复。这正是回滚计划要与变更同时写好、触发回滚的权限要事先指定的原因。恢复之后，这项失败的变更带着得到的经验重新走一遍评估——把它当成一项没有历史的新变更，只会让同样的失败换一批人再发生一次。
变更控制和版本控制有什么区别？
版本控制识别并记住一份文件连续的各个状态——哪一个是当前版本，之前又是什么样子。变更控制是更宽的那套流程，从评估、授权、实施、验证到关闭，判断的是一项拟议变更究竟是否被允许发生，一旦获批，通常才会产生一个新版本。概念上的区别详见 /zh/guides/版本控制与变更控制的区别；/zh/templates/文件变更控制流程 与 /zh/templates/SOP变更控制流程 则是这同一形态针对特定文件类型的变体。
