变更管理流程图（ITIL）

什么是变更管理流程图（itil）流程

本模板里的变更管理，指的是信息技术服务的变更管理：每一项对生产服务的变更都要走的那条固定流程，从提出变更请求开始，到变更记录关闭为止。它不是组织变革管理——那是与人相关的学科，通常与 ADKAR 或科特八步这类模型联系在一起——尽管两者在中文里经常被混着叫作“变更管理”。这里画出来的，是由变更经理和变更咨询委员会（CAB）持续运行的、ITIL 风格的运营流程。

大部分价值集中在靠前的一个决策上：这是哪一类变更？把所有变更都送进同一套完整评估、同一个每周例会，只会排出一条队；而队列正是把人推向流程之外去改动系统的原因。所以这张图只分流一次，而且分得很早。标准变更依据一份成文的变更模型预先获批，直接进入排期。常规变更接受风险与影响评估，然后送 CAB。紧急变更由紧急 CAB 加急授权，之后重新汇入完全相同的排期、实施与评审路径，因此一次紧急修复永远不会成为一次无记录的修复。

图能定下来的另一件事是归属，这也是它被画成泳道的原因：申请人、变更经理、CAB、实施团队与服务负责人。服务负责人单独占一条泳道，因为验证正是各团队最常跳过的一步。“已经部署了”和“服务是好的”是两个不同的说法，而两者之间的差距，就是回滚路径存在的全部理由。在这张图里，验证不通过会触发回滚方案，而成功的变更与已回滚的变更同样都要走到实施后评审与关闭。

本流程图涵盖的内容

本模板包含

• 跨申请人与变更经理两条泳道的受理：提出变更请求、把 RFC 登记进变更登记册，然后是“请求是否完整且在范围内？”这道完整性过滤——内容单薄的请求会被退回给申请人补齐细节，再回到同一道检查
• “变更类型？”处的三向分流：标准变更直接进入变更日历，常规变更进入风险与影响评估，紧急变更进入 ECAB 授权
• 评估与审批：评估风险与服务影响，把评估结果与回滚方案记录成一份完整文件而不是一串工单留言，然后是 CAB 评审以及批准或驳回的决策，被驳回的变更止于申请人泳道中的“变更被驳回并关闭”终止节点
• 排期：已批准、紧急与标准三条路径在变更日历上汇合，并遇到一次与其他已排期变更的冲突检查，撞期的变更被退回重新排期
• 实施团队泳道中的构建与实施：构建并测试变更，然后在获批的时间窗内实施
• 验证与关闭：服务负责人验证服务并回答“变更是否成功？”，失败则执行回滚方案，两种结果都汇合到实施后评审与变更记录的关闭

何时使用本模板

• 为服务台、平台团队或基础设施团队编写或更新一套 ITIL 风格的变更管理程序，而这些团队目前靠的是习惯和聊天记录
• 在 ServiceNow、Jira Service Management 或 Freshservice 里配置变更类型之前，先就什么算标准、什么算常规、什么算紧急达成一致，让工具承载你们已经作出的决定，而不是替你们发明一个
• 带新任变更经理、CAB 成员或值班工程师上手，他们需要知道哪些变更需要审批、由谁审批，以及非工作时间怎么办
• 向审计员或客户说明变更如何评估、授权、测试与回退，例如对照 SOC 2 的 CC8.1 准则或 ISO/IEC 27001:2022 附录 A 的 8.32 控制项。图记录的是程序；证据是它产生的那些变更记录
• 在一个糟糕的季度之后降低变更失败率，需要看清验证与回滚究竟在哪一步、由谁负责

运作方式

1. 把泳道改成你们实际拥有的角色

   把申请人、变更经理、CAB、实施团队与服务负责人替换成你们真实的职能。不少组织由同一个人兼任变更经理和 CAB 主席，规模更小的团队根本没有独立的实施团队。与其画一个你们并不存在的结构，不如把泳道合并，并且把泳道控制在五条以内——再多，这张图就没法一眼读懂了。

2. 在分流决策处定义你们的三种变更类型

   在“变更类型？”这个决策旁边写清楚什么算标准、什么算常规、什么算紧急，并按风险和影响范围而不是按工作量或工单大小来划界。把预先批准的标准变更清单保持得足够短，短到真的有人愿意维护它，并为每一项标准变更配一份必须遵循的成文变更模型。

3. 指定变更授权方、它的会议节奏，以及它的紧急对应方

   在 CAB 评审这一步记下审批人是谁、多久开一次会、上议程的截止时间。ECAB 要单独定义：有权批准非工作时间修复的，很少是整个委员会。多数团队最后采用的规则是：几分钟内口头授权，当天补齐记录，在下一次 CAB 上评审。

4. 写明评估记录必须包含什么

   把“记录评估与回滚方案”变成一份真正的检查表：受影响的服务与用户、风险评级、依赖关系、停机时间窗、测试方法、回滚步骤，以及由谁执行回滚。CAB 的决策不会好过这份记录的质量，而它正是审计员几个月之后会来索取的那份文件。

5. 把排期与冲突规则写明白

   写清楚你们的冻结期、最短提前量，以及变更日历由谁负责。这张图里的冲突检查被刻意画成一个决策而不是一道手续，因为大多数撞期是两个团队碰到了同一个共享依赖，而不是碰了同一个系统。事先决定：撞期意味着重新排期，还是意味着升级。

6. 定义什么叫成功，然后发布并对程序做版本管理

   说清楚“变更是否成功？”在你们这里意味着什么：哪些冒烟测试、服务负责人观察多久、什么情况下下达回滚指令。然后把图放到工作真正发生的地方——变更申请表旁边或者运行手册里——向图中点名的人收集审批，并保留历史版本，好让你们能说明程序是什么时候改的、为什么改。

常见问题

这是信息技术变更管理，还是组织变革管理？

是信息技术变更管理。两者共用一个名字，此外几乎毫无关系。这张流程图画的是 ITIL 风格的生产服务变更运营流程：提出 RFC，分流、评估、授权、排期、实施、验证、关闭。组织变革管理是与人相关的学科，帮助员工接受一种新的工作方式，通常围绕 ADKAR 或科特八步这类模型来组织，它没有 CAB、没有变更日历、也没有回滚方案。如果你们要找的是干系人分析与沟通规划，那就找错图了。

标准变更、常规变更和紧急变更有什么区别？

标准变更风险低、执行频繁，并且依据一份成文的变更模型预先获批，因此无需逐项审批，直接进入排期。常规变更是指必须就事论事地评估和审批的变更，走的是从风险与影响评估到 CAB 的那条路。紧急变更是指等到下一次 CAB 造成的损害会大于变更本身风险的情形，因此由紧急 CAB 加急授权。在这张图里三者都汇入同一个变更日历、同一套实施与评审，因为类别改变的是审批路径，而不是记录。

每一项变更都要上 CAB 吗？

不需要，而且把所有变更都送上去，是让人绕开流程的最快办法。CAB 存在的意义，是评审那些风险尚未被摸清的变更。当某一类变更执行的次数已经多到有了可靠的程序和已知的失效模式，就把它升为带成文模型的标准变更，并从议程上拿掉。一个把会议时间花在给日常工作盖章上的 CAB，其实什么也没有评审；而它造出来的队列，会把真正有风险的变更推向紧急通道。

变更失败了应该怎么办？

它走的是和成功变更完全一样的那条关闭路径。在这张图里，“变更是否成功？”处验证不通过会触发实施团队泳道中的回滚方案，随后这项已回滚的变更同样进入实施后评审与关闭。让这一点在实践中站得住的有两件事：回滚方案是在变更执行之前就写好并获批的，而不是在事故当中临时想出来的；以及评审既问变更是否奏效，也问当初的变更类型判断对不对。第二次尝试是一份新的 RFC，因此失败的那一次保留着它自己的记录。