变更管理

变更分类：按风险分级管控

不能一刀切地要求所有变更都进行测试和风险评估，否则管理成本太高。系统按照变更的风险严重性设计四类变更，分别采用差异化的管控策略。

标准变更：菜单化、模板化、流程化

标准变更是日常频繁发生、可预先定义、风险和成本较低的变更。标准变更的关键不是额外的风险评估，而是通过流程固化管控点，确保合规性和安全性。

• 菜单化：将一系列典型的日常变更定义为"标准变更"菜单，用户按需选择
• 模板化：通过工单模板定义每类标准变更的字段，以及这些字段与CMDB的数据联动关系，在提高CMDB数据复用率的同时，通过标准变更的执行维护和修订CMDB数据
• 流程化：通过流程管控标准变更的合规性，固化基本的安全检查、资源申请合理性、资源回收机制

标准变更分两类：归属"服务请求"管理的（由业务用户发起，服务台受理，如终端、账号、权限申请），和归属"标准变更"管理的（由信息化内外部人员发起，不经过服务台）。建议逐渐将日常频繁发生的低风险变更归属于标准变更，让变更管理的效率持续提高。

正式变更：五步管控流程

对于影响较大、风险不确定的正式变更，需要更加全面彻底的计划和评估，以及更加正式的授权和后续评估。系统建立由技术测试和方案验证、风险评估、变更评估会、实施、变更回顾五个步骤组成的变更管理流程。

一、技术测试和方案验证

风险评估的对象是《实施方案》，因此需要确保实施方案经过了测试，并且经过了多于一个技术人员的验证。

• 通过CMDB列出与变更相关的系统及负责人，要求相关系统负责人进行测试反馈
• 将技术实施经验预制为一系列《实施方案》，形成对特定变更经验的持续沉淀

二、风险评估

风险评估是审批授权的依据。需要解决两个问题：一是通过CMDB准确识别变更影响范围，界定风险评估参与人；二是建立一套统一、多维度、分权重的风险评估方法，避免遗漏风险基本面。

风险评估人员构成：常任风险评估小组（业务系统主管、基础设施运维主管、核心业务系统负责人、安全负责人、技术骨干）+ 动态风险评估成员（依靠CMDB识别与变更对象有调用关系的其他业务系统负责人）。

多维度风险评估模型：系统建立统一的风险评估方法，覆盖变更对象、变更影响、未知风险、风险控制、异常影响五个维度，并通过加权计算得出总体风险评估值。

三、变更评估会

针对高级别风险的变更，需要进行必要的现场方案分析会。变更计划以在线方式提交为数据化可共享的计划，分发给所有CAB成员在会议前阅读。风险极高、未能获得在线批准、或需短时间内部署但未及时获得在线CAB批准的变更，需尽快召开线下会议。

四、实施

执行变更，系统自动发送实施前、后的消息通知。变更计划需比对维护窗口，确保在合适的时间窗口内执行。

五、变更回顾

在变更实施30天后，对变更的效果和是否产生故障进行回顾。

• 内部检查：信息部门检查是否起到了变更效果，是否产生了故障
• 外部评价：业务干系人评价是否起到了变更效果，是否带来了额外成本和不良现象

变更计划：风险评估的基础

变更计划是确保变更成功和风险评估的基础。为了确保所有必要人员在需要时可用，团队提前知道任务和执行时间，而不是在部署前临时得知。

• 停机时间表：用于将计划与发布窗口进行比对的关键信息
• 计划时间：计划开始和结束时间，与发布窗口比对
• 部署工作事务：列表化本次变更涉及的工作事务和软件需求，便于评估和跟踪进度
• 必要文件：操作方案、回退方案、测试文档、验证方案

没有经过测试的程序不应该出现在生产环境中。系统区分开发环境、测试环境和生产环境，测试负责人将代码安装到测试环境并通知关键业务用户进行验收测试，直到获得批准。

CMDB与变更管理集成

如果不能准确掌握信息系统的构成关系，就无法判断每次变更的影响范围，无法界定应有的风险评估参与人。通过配置管理数据库CMDB，系统自动识别变更对象的潜在影响范围，辅助识别风险评估人。

• 自动识别变更对象关联的业务系统及负责人，加入风险评估参与人
• 比对变更方案中的计划时间与业务系统的发布窗口
• 将处于同一时间的所有变更进行集中显示，避免变更计划冲突
• 自动识别系统调用关系、新增虚拟机等潜在变更