2. 变更管理基础：变更类型、生命周期与风险等级划分
变更管理是发布工程的“交通规则”。没有规范的变更管理，每一次上线都可能成为一次不可控的故障注入。本节从变更类型、生命周期和风险等级三个维度，建立变更管理的核心认知框架。
2.1 变更类型：标准 / 正常 / 紧急
ITIL 框架将变更分为三种类型，分别对应不同的审批流程和执行节奏。理解三者的区别，是设计变更冻结闸口的前提。
| 类型 | 定义 | 审批流程 | 典型场景 |
|---|---|---|---|
| 标准变更 | 低风险、预授权、重复执行的变更 | 无需单独审批，按预定义流程执行 | 日常补丁更新、配置参数调整、非核心服务重启 |
| 正常变更 | 有计划、需评估、按标准流程推进的变更 | 需提交变更请求（RFC），经变更咨询委员会（CAB）评审 | 功能上线、数据库迁移、架构升级 |
| 紧急变更 | 为修复生产故障或安全漏洞而必须立即执行的变更 | 快速通道审批，事后补录 | 线上事故热修复、安全漏洞紧急封堵 |
实践要点： 紧急变更应严格限制使用频率。建议设定“紧急变更占比 ≤ 5%”的 SLO，避免紧急通道被滥用为“常规捷径”。
2.2 变更生命周期：从请求到关闭
每一次变更都经历完整的生命周期。标准化的生命周期管理，确保变更可追溯、可回滚、可审计。
变更生命周期 7 阶段：
- 创建与分类 — 提交 RFC，确定变更类型与风险等级
- 评估与审批 — 技术评审、CAB 审批、风险影响分析
- 计划与调度 — 确定变更窗口、回滚方案、通知干系人
- 构建与测试 — 在预发环境验证变更内容
- 实施与部署 — 按计划执行变更，监控关键指标
- 验证与确认 — 确认变更达到预期效果，无副作用
- 关闭与回顾 — 关闭 RFC，记录经验教训
2.3 变更风险等级划分
风险等级决定了变更的审批层级、冻结策略和监控力度。通常采用“影响范围 × 故障严重度”的二维矩阵进行评级。
2.3.1 风险等级定义
| 等级 | 标签 | 影响范围 | 审批要求 | 冻结策略 |
|---|---|---|---|---|
| P0 | 最高风险 | 全站 / 核心业务 / 用户数据 | CTO + 架构师 + CAB 联合审批 | 冻结期内禁止，除非紧急变更 |
| P1 | 高风险 | 多服务 / 重要功能模块 | 架构师 + 技术负责人审批 | 冻结期内需特批 |
| P2 | 中风险 | 单服务 / 非核心功能 | 技术负责人审批 | 冻结期内可执行，需备案 |
| P3 | 低风险 | 内部工具 / 运维脚本 | 自助审批或标准变更 | 不受冻结限制 |
2.3.2 风险等级判定矩阵
判定风险等级时，需同时评估变更的影响范围和故障严重度。以下矩阵可作为参考模板：
| 影响范围 \ 故障严重度 | 严重（S1） | 中等（S2） | 轻微（S3） |
|---|---|---|---|
| 全局（全站/核心数据） | P0 | P0 | P1 |
| 局部（多服务/重要模块） | P0 | P1 | P2 |
| 单点（单服务/非核心） | P1 | P2 | P3 |
常见误区： 仅凭“变更内容大小”判定风险等级。例如“只改一行配置”可能影响全局路由，应判定为 P0 而非 P3。风险等级应基于变更的潜在影响，而非变更本身的代码量或复杂度。
2.4 变更类型与风险等级的关联策略
变更类型和风险等级共同决定了变更的执行策略。以下为推荐关联矩阵：
| 风险等级 | 标准变更 | 正常变更 | 紧急变更 |
|---|---|---|---|
| P0 | 不允许 | 需 CTO + CAB 审批，冻结期内禁止 | 仅限生产事故修复，事后 24h 内补录 |
| P1 | 不允许 | 需架构师审批，冻结期内特批 | 需技术负责人 + 架构师双签 |
| P2 | 允许（预授权清单内） | 需技术负责人审批 | 需技术负责人审批，事后补录 |
| P3 | 允许 | 自助审批 | 自助审批 |
关键原则：
- 风险等级决定审批层级 — P0 变更必须由最高技术决策者审批
- 变更类型决定流程通道 — 紧急变更走快速通道，但事后必须补全审计信息
- 冻结闸口只拦截 P0/P1 — 低风险变更在冻结期内仍可正常执行，避免过度管控影响效率
- 动态调整机制 — 每次变更关闭后，应回顾风险等级判定是否准确，持续校准判定标准