变更风险评估是什么
变更风险评估围绕影响范围、回退可行性、验证手段、实施时机与历史经验展开，输出风险等级与控制措施，用于决定审批层级与实施方式。评估的目的不是写一份文档，而是强制回答两个问题：出了问题怎么退，上线后怎么确认成功。评分模型不必复杂，维度越多越难维护；关键是让控制强度与风险相称，并让低风险变更可以自动化通过。
基本信息
| 评估维度 | 影响、回退、验证、时机、历史经验 |
|---|---|
| 输出 | 风险等级 + 控制措施 |
| 常用手段 | 检查表、评分卡、历史失败率 |
| 关键两问 | 回退是否可行、验证是否明确 |
| 分级用处 | 决定审批层级与实施窗口 |
| 数据支撑 | 同类变更的历史失败与回退记录 |
典型使用场景
- 变更单提交：填写影响范围、回退方案与验证方式
- 审批分层：低风险自动放行，高风险进入 CAB 或专项评审
- 窗口选择：避开业务高峰与冻结期，必要时缩小实施批次
- 经验复用：参考同类变更的失败原因调整控制措施
- 回退验证：高风险变更上线前验证回退脚本可用
- 复盘改进：把失败变更的评估遗漏项补进检查表
风险评估检查表
风险评估检查表
□ 影响哪些服务与用户？回退需要多久？
□ 回退是否演练或验证过？
□ 上线后如何验证成功（指标或探测）？
□ 是否位于业务高峰或冻结期？
□ 同类变更历史上是否发生过故障？风险等级与控制
| 风险等级 | 判定线索 | 控制措施 |
|---|---|---|
| 低 | 影响小、回退成熟、可自动验证 | 预授权，按模板执行 |
| 中 | 影响可控但需要协调 | 变更单评审 + 窗口实施 |
| 高 | 影响核心业务或无法快速回退 | 逐项评审 + 演练 + 灰度实施 |
评分不必复杂：关键是强制回答回退与验证两个问题，其余维度用于区分控制强度，而不是追求精确打分。