2. 变更申请基础：定义、类型与核心字段解析
变更申请（Request for Change, RFC）是ITIL变更管理流程的起点，也是后续影响评估、授权与实施活动的唯一正式输入。在实际故障排查场景中，一份填写不完整或分类错误的RFC往往会导致评估遗漏、回滚困难甚至服务中断。本节将系统梳理变更申请的定义、三种类型及其适用场景，并逐字段解析标准RFC表单的结构。
2.1 变更申请的定义与流程定位
变更申请是一份正式记录，用于描述对IT基础设施、应用系统、配置项或服务管理流程的任何新增、修改或移除操作。它不仅是技术请求，更是一份包含业务理由、风险预判、实施计划与回滚方案的治理文档。
关键原则：没有RFC，就没有变更。任何绕过RFC的“偷偷修改”都应被视作非计划变更，在故障排查中需优先追溯。
在ITIL服务过渡阶段，RFC的流转路径如下：
- 发起：由请求者（变更申请人）填写表单并提交。
- 分类与优先级分配：变更管理员根据类型、影响范围与紧急程度打标。
- 影响评估：变更顾问委员会（CAB）或紧急变更委员会（ECAB）进行评审。
- 授权与实施：通过后由变更实施团队执行。
- 回顾与关闭：实施后验证结果，关闭RFC。
2.2 变更申请的三种类型
ITIL v3/4将变更申请划分为标准变更、紧急变更和正常变更三大类。分类的准确性直接影响审批路径、评估深度与实施节奏。在故障排查中，错误分类（如将紧急变更误标为标准变更）是常见的根因之一。
| 类型 | 定义 | 审批路径 | 典型场景 | 故障排查关注点 |
|---|---|---|---|---|
| 标准变更 | 预授权、低风险、重复执行的变更 | 无需CAB审批，按预定义流程执行 | 密码重置、补丁安装、虚拟机模板部署 | 检查是否超出预授权范围；是否遗漏配置项更新 |
| 紧急变更 | 必须尽快实施以修复或预防重大服务中断 | ECAB快速审批，可事后补录 | 安全漏洞热修复、核心数据库宕机恢复 | 回滚方案是否完整；是否跳过必要测试 |
| 正常变更 | 非标准、非紧急，需完整评估与授权 | CAB评审，分常规与重大两个子类 | 架构升级、新应用上线、网络拓扑调整 | 影响评估是否覆盖所有依赖项；变更窗口是否合理 |
常见陷阱：将紧急变更当作“免检通道”，在故障排查中频繁出现。紧急变更必须附带紧急理由说明和事后回顾承诺，否则应降级为正常变更并重新评估。
2.3 变更申请表单的核心字段解析
一份标准的RFC表单通常包含元数据字段、业务字段和技术字段三大类。以下逐一解析每个字段在故障排查中的关键作用。
2.3.1 元数据字段
| 字段名 | 说明 | 故障排查价值 |
|---|---|---|
| RFC编号 | 全局唯一标识符 | 用于关联事件、问题、已知错误记录 |
| 申请日期 | 提交时间戳 | 判断变更是否在变更窗口内；追溯审批延迟 |
| 申请人 | 发起变更的个人或团队 | 确认申请人是否具备相应权限；联系回滚负责人 |
| 变更类型 | 标准/紧急/正常 | 验证分类是否匹配实际紧急程度 |
| 优先级 | P1~P4（影响+紧急度矩阵） | 决定评估深度与实施速度 |
2.3.2 业务字段
| 字段名 | 说明 | 故障排查价值 |
|---|---|---|
| 变更标题 | 简短描述变更内容 | 快速判断变更意图；与事件/问题描述交叉比对 |
| 业务理由 | 为什么需要此变更 | 评估变更的必要性；识别是否由已知问题驱动 |
| 预期收益 | 可量化的业务价值 | 作为实施后回顾的衡量基准 |
| 关联服务 | 受影响的业务服务列表 | 确定影响范围；触发对应SLA的评估 |
2.3.3 技术字段
| 字段名 | 说明 | 故障排查价值 |
|---|---|---|
| 配置项（CI）列表 | 受变更影响的CI及其版本 | 验证CI是否在CMDB中正确注册；识别依赖关系 |
| 实施计划 | 详细步骤、时间线、负责人 | 检查步骤是否完整；是否存在单点故障 |
| 回滚方案 | 失败时的恢复步骤与触发条件 | 故障排查中最关键的字段——缺失回滚方案应直接拒绝 |
| 测试结果 | 预生产环境的验证数据 | 确认测试覆盖度；识别未覆盖的边界条件 |
| 风险评估 | 影响、概率、应对措施 | 与CAB评估结果对比；发现被低估的风险项 |
2.4 字段填写质量对故障排查的影响
在实际故障排查案例中，RFC表单字段的填写质量直接决定了问题定位的效率。以下列出三个典型场景：
- 场景A：回滚方案缺失 —— 变更实施失败后，团队花费2小时临时编写回滚步骤，导致MTTR（平均修复时间）延长300%。
- 场景B：配置项列表不完整 —— 变更涉及数据库集群，但RFC只列出了主库CI，未列出从库，导致从库同步异常未被纳入评估。
- 场景C：业务理由模糊 —— 仅写“性能优化”，未关联具体KPI，实施后无法验证是否达到预期，引发业务部门投诉。
最佳实践：在变更申请阶段引入字段完整性检查清单，由变更管理员在接收RFC时逐项核对。对于缺失关键字段（尤其是回滚方案、CI列表、风险评估）的RFC，直接退回并要求补充，而非进入评估流程。