4. 变更风险评估模型：风险等级划分与影响评估
变更风险是数据库可靠性事故的首要诱因。一个可量化的风险评估模型，能够帮助运维团队在变更窗口内快速判断“该不该做”、“怎么做”、“要不要回滚”。本章围绕风险等级划分、影响范围评估和回滚复杂度评估三个核心维度，构建完整的变更风险判定体系。
4.1 风险等级划分标准（低/中/高/严重）
风险等级由变更影响范围与变更失败后果两个因子联合决定。采用四档分级制，每档对应不同的审批流程与执行策略。
| 风险等级 | 定义 | 典型场景 | 审批要求 | 执行窗口 |
|---|---|---|---|---|
| 低 | 影响单个非核心表，失败可快速重试，无数据丢失风险 | 添加索引、修改非关键字段注释、清理过期分区 | 团队内 Peer Review | 任意维护窗口 |
| 中 | 影响核心表但可灰度执行，失败可回滚且回滚时间可控 | DDL 变更（加字段）、重建索引、修改存储过程 | 技术主管审批 | 常规变更窗口 |
| 高 | 影响多个核心表或跨库操作，失败可能导致 5 分钟以上中断 | 表结构重构、数据迁移、主从切换、大表 truncate | DBA 负责人 + 业务方审批 | 专用大变更窗口 |
| 严重 | 影响全局数据库或跨集群，失败可能导致长时间不可用或数据丢失 | 版本升级、内核参数调整、存储迁移、跨机房切换 | CTO / 技术委员会审批 | 封网期外紧急窗口 |
判定口诀：“低改单表不改核，中改核心可回滚，高改多库有中断，严重全局动根基。” 每次变更前，先对照口诀快速定位风险档位。
4.2 影响范围评估模型
影响范围评估不能仅凭“感觉”，需要从数据维度、业务维度和链路维度三个层面进行量化打分。
4.2.1 三维度影响评分矩阵
| 评估维度 | 评估项 | 低分（1 分） | 中分（2 分） | 高分（3 分） |
|---|---|---|---|---|
| 数据维度 | 涉及表数量 | 1 张非核心表 | 1~3 张核心表 | 3 张以上或跨库 |
| 数据量级 | < 100 万行 | 100 万 ~ 1 亿行 | > 1 亿行 | |
| 业务维度 | 关联业务线 | 内部工具 / 后台 | 单条核心业务线 | 多条核心业务线 |
| 峰值 QPS 影响 | < 5% 抖动 | 5%~20% 抖动 | > 20% 或直接报错 | |
| 链路维度 | 依赖下游 | 无下游消费 | 1~2 个下游系统 | 3 个以上或核心链路 |
| 变更并发度 | 单节点串行 | 多节点并行（同机房） | 跨机房 / 跨集群 |
总分计算：将六个评估项的得分相加，总分 6~8 分为低影响，9~12 分为中影响，13~15 分为高影响，16~18 分为严重影响。该分数与风险等级联合使用，作为审批升级的参考依据。
4.2.2 影响范围评估流程
- 前置扫描：通过元数据管理平台自动扫描变更涉及的表、索引、存储过程列表。
- 依赖分析：调用链路追踪系统，识别变更对象的下游消费者和上游依赖。
- 流量评估：从监控系统拉取变更对象的实时 QPS、慢查询占比、锁等待频率。
- 打分定级：按照三维度评分矩阵逐项打分，输出影响范围等级。
- 人工复核：DBA 对自动评分结果进行抽样确认，修正误判项。
案例：某次变更计划对一张 5000 万行的订单表增加字段。自动扫描发现该表被 4 个下游实时消费，峰值 QPS 8000，且变更期间需要重建索引。三维度评分结果为 14 分（高影响），最终风险等级被判定为“高”，要求业务方提前降级消费、安排灰度执行。
4.3 回滚复杂度评估
回滚不是“撤销操作”，而是“恢复到变更前的稳定状态”。回滚复杂度评估决定了变更是否具备执行条件，以及回滚预案需要做到什么粒度。
4.3.1 回滚复杂度分级
| 复杂度等级 | 定义 | 典型变更 | 回滚耗时 | 回滚风险 |
|---|---|---|---|---|
| 简单 | 可执行反向 DDL 或单条命令回滚 | 加索引（DROP INDEX）、加字段（ALTER 回退） | < 1 分钟 | 极低 |
| 中等 | 需要执行预编写的回滚脚本，涉及数据补偿 | 修改字段类型、数据迁移（回迁脚本） | 1~10 分钟 | 低 |
| 复杂 | 需要重建数据或依赖备份恢复，涉及多个步骤 | 大表 truncate 后恢复、分区合并回退 | 10~60 分钟 | 中 |
| 极高 | 无法原地回滚，只能通过备份重建或切换至灾备 | 内核升级、存储引擎切换、跨版本迁移 | > 60 分钟 | 高 |
4.3.2 回滚复杂度评估要素
- 可逆性：变更操作是否有对应的反向操作？DDL 是否支持 IF NOT EXISTS / IF EXISTS 保护？
- 数据补偿：变更过程中是否产生了增量数据？回滚时是否需要补偿这些增量？
- 依赖恢复：下游系统是否感知到变更？回滚后是否需要通知下游重新消费？
- 备份可用性：变更前是否完成了全量+binlog 备份？备份恢复的 RTO 是否在可接受范围内？
- 回滚脚本成熟度：回滚脚本是否经过预演？是否包含数据校验步骤？
关键原则：任何“高”或“严重”风险的变更，回滚复杂度必须为“简单”或“中等”才能执行。如果回滚复杂度为“复杂”或“极高”，必须重新设计变更方案，降低回滚成本，否则禁止在常规变更窗口执行。
4.4 风险等级与回滚复杂度联合决策矩阵
将风险等级与回滚复杂度组合，形成最终的变更执行决策：
| 风险等级 \ 回滚复杂度 | 简单 | 中等 | 复杂 | 极高 |
|---|---|---|---|---|
| 低 | ✅ 直接执行 | ✅ 直接执行 | ⚠️ 需主管确认 | ❌ 禁止执行 |
| 中 | ✅ 正常执行 | ✅ 需预演回滚 | ❌ 禁止执行 | ❌ 禁止执行 |
| 高 | ✅ 灰度执行 | ⚠️ 需重新设计 | ❌ 禁止执行 | ❌ 禁止执行 |
| 严重 | ⚠️ 紧急审批 | ❌ 禁止执行 | ❌ 禁止执行 | ❌ 禁止执行 |
决策逻辑：绿色（✅）表示可执行，黄色（⚠️）表示需附加条件，红色（❌）表示禁止。所有“禁止执行”的组合，必须退回变更设计阶段，重新评估方案或拆分变更粒度。
4.5 变更风险评估模型总览
下图展示了从变更输入到最终决策的完整评估链路：
4.6 评估模型落地检查清单
每次变更执行前，DBA 或变更负责人应逐项确认以下检查项：
- □ 风险等级已判定：对照四档标准，明确当前变更属于低/中/高/严重。
- □ 影响范围已量化：三维度评分已完成，总分记录在变更工单中。
- □ 回滚复杂度已评估：五要素检查完毕，回滚脚本已准备或已预演。
- □ 联合决策已通过：风险等级与回滚复杂度组合不在“禁止执行”区域。
- □ 审批流程已触发：根据风险等级，对应的审批人已完成审批。
- □ 回滚预案已就绪：回滚步骤、执行人、预计耗时、数据校验方法均已明确。
最佳实践：将上述检查清单嵌入变更管理平台的工单流程中，系统自动根据风险等级和回滚复杂度锁定审批节点，避免人为遗漏。每次变更完成后，将实际影响与评估结果进行对比，持续校准模型参数。