IT运维变更管理实践的评估要素和相关定义
4）变更评估要素
在变更评估要素用于指导变更请求人、变更审批人、变更授权人在提交变更请求、审批或授权时应该考虑的因素，以便更改提前识别风险，以提出应对方案，提升变更的效率和成功率；
表：变更评估要素
序号 | 风险衡量因素 | 权重 | 评判标准 | 得分 |
1 | 业务影响面 | 15% | 1.影响三个及以上接入单位； 2.影响机关重要用户 | 3 |
1.影响两个接入单位； 2.影响机关用户 | 2 | |||
1.影响一个接入单位 | 1 | |||
1.影响个别用户； | 0 | |||
2 | 业务影响度 | 15% | 顾客服务将受到长时间实际影响（业务系统停机超过30分钟） | 3 |
顾客服务将受到瞬时实际影响（业务系统短暂中断） | 2 | |||
顾客服务将受到潜在影响（业务系统系能下降） | 1 | |||
业务系统性能不受影响 | 0 | |||
3 | 安全策略 | 30% | 涉及主干的物理安全策略，访问控制、防护等技术安全策略，运行安全策略 | 3 |
涉及一个单位的物理安全策略，访问控制、防护等技术安全策略，运行安全策略 | 2 | |||
不影响全局及本单位安全策略的局部安全策略变更 | ||||
不影响安全策略 | 0 | |||
4 | 变更成功的可能性 | 10% | 无法/未经测试，变更失败可能性很高 | 3 |
能实现部分测试，变更失败可能性较高 | 2 | |||
有成熟的变更方案，或无须测试，变更失败可能低 | 1 | |||
5 | 回退时间 | 10% | 回退难度中等以上，回退时间超过1小时 | 3 |
回退难度适中（1小时或更短） | 2 | |||
易于回退（30分钟或更短） | 1 | |||
6 | 变更实施时间/实施所需的停机时间 | 10% | 超过1小时 | 3 |
不到1小时 | 2 | |||
不到30分钟 | 1 | |||
7 | 变更复杂度 | 10% | 新的发布，或需要多方（多部门/多小组）协同参与的变更 | 3 |
只需1个支持小组参与的变更 | 2 | |||
有标准的、可重复的执行步骤的变更 |
总得分=Z（得分项X权重）
表：变更评估要素应用-变更类型确定
总得分 | 风险等级 | 变更类型 |
2+ | 高 | 重大变更 |
0-2 | 中 | 一般变更 |
6）变更前导时间定义
前导时间是指从提交变更到变更实施之前所需要进行评估、预审核及必要的实施前准备活动的最少时间。
表：变更前导时间定义
变更优先级 | 变更前导时间 |
紧急变更 | N/A |
重大变更 | 10工作日 |
一般变更 | 5工作日 |
临时变更 | 2工作日 |
标准变更 | N/A |
7）变更窗口时间定义
变更窗口是约定的、周期性的时间，在此期间实施变更或发布对服务的影响最小。变更窗口的制定需要考虑下列因素：
·对业务的影响较小（决定了窗口选择的日期）
·个别客户的特定业务需求（决定了窗口选择的日期）·变更实施和回退的时间（决定了窗口的持续时间）。
表：变更窗口时间定义
变更类型 | 变更窗口 | 窗口 |
重大变更 | 时间段 | 18：00-次日6：00 |
一般变更 | 时间段 | 18：00-次日6：00 |
标准变更 | 时间段 | N/A |
紧急变更 | 时间段 | N/A |
8）变更关闭代码定义
变更关闭代码用于分析统计变更被解决的状态，便于变革回顾流程中对变更模型的评审与更新。
表：变更关闭代码定义
代码 | 描述 |
成功 | 变更成功实施 |
部分成功 | 变更部分成功，需经相关方确认并提交部分失败报告，及后续改进计划 |
失败 | 变更实施不成功，执行回退计划，需提交变更失败报告 |
驳回 | 变更未通过审批 |
取消 | 取消执行已通过审批的变更 已批准变更，若需要修改变更内容，必须先取消当前变更，然后通过创建一个新的变更来完成变更内容的修改。 |
9）事件关闭代码定义
事件关闭代码用于分析统计事件被解决的状态，便于事件回顾流程中对事件模型的评审与更新。
表：事件关闭代码
关闭状态 | 描述 |
成功解决 | 事件被正常解决。 |
变通方案解决 | 事件已通过变通方法解决掉，但是需要进行更进一步的根源分析。用户认可可以作为一种特殊的变通方法。 |
事件消失 | 没有找到错误或不能重现故障 |
无法解决 | 现有情况下无法解决 |
关闭方式 | 描述 |
用户确认关闭 | 经用户确认后，服务台关闭 |
默认关闭 | 如果累计两次与用户确认，用户未能配合确认的，并且事件解决已超过48小时的，可由服务台选择自动关闭 |
注：事件只有在解决后才能关闭，暂时无法解决的不能关闭。 | |
10）流程衡量指标
表：变更管理流程衡量指标
衡量指标 | 指标说明 | 考核对象 | 参考 |
变更总数 | 数量：在所有RFC中根据【变更发生时间】在统计周期内这一条件过滤 | ||
不同变更类型变更的比率 | 数量：在变更总数中过滤【变更类型】=‘紧急’、‘重大’、‘一般（设计开发类）’、‘一般（非设计开 发类）’、‘标准’ 比例：数量/变更总数×100% | ||
根据变更类别统计变更的比率 | 数量：在变更总数中过滤【变更分类】=‘对应类别’; 比率：数量/变更总数×100% | ||
紧急变更成功的比率 | 数量：在紧急变更总数中过滤【变更关闭】=‘成功’&‘部分成功’ 比率：数量/变更总数×100% | 95% | |
成功变更的比率 | 数量：在变更总数中过滤【变更关闭】=‘成功’&‘部分成功’ 比率：数量/变更总数×100% | 95% | |
失败变更的比率 | 数量：在变更总数中过滤【变更关闭】=‘失败’ 比率：数量/变更总数×100% | 5% | |
无差错变更的比率 | 数量：在变更总数中过滤【变更评价】=‘变更无差错 比率：数量/（变更总数*【已执行变更比率】）×100% | 变更实施人 | 98% |
部分差错变更的比率 | 数量：在变更总数中过滤【变更评价】=‘变更出现部分差错 比率：数量/（变更总数*【已执行变更比率】）×100% | ||
出现差错并回退的比率 | 数量：在已执行变更总数中过滤【变更评价】=‘变更出现差错并被回退’ 比率：数量/（变更总数*【已执行变更比率】）×100% |
续表
衡量指标 | 指标说明 | 考核对象 | 参考 |
人员实施差错率 | 数量：在变更总数中过滤【变更评价】=‘变更出现差错并被回退’或‘变更出现部分差错’and【实施变更部门】=’对应实施人‘and【变更类型】=’一般（设计开发类）‘or’一般（非设计开发类）‘ or‘重大变更 比率：数量/（变更总数*【已执行变更比率】）×100% | 变更实施人 | |
已审批变更单汇总 | 数量：在变更总数中过滤【变更状态】=‘已审批’ 比率：数量/变更总数×100% | ||
变更完成情况统计 | 数量：在变更总数中过滤【变更状态】=‘已完成 比率：数量/变更总数×100% | ||
变更导致事件的数量 | 数量：事件总数中过滤由变更导致的数量 | 变更实施人/配合人 | |
参考数字化IT运维管理体系建设指南等书籍资料