1. 变更可靠性基础
为什么先建“风险登记册”而不是先写变更方案
变更可靠性管理的起点不是审批，而是把“即将发生什么”变成一张可排序、可追踪、可评审的清单。风险登记册的核心作用是把模糊的“这次变更有点危险”转化为可比较的字段：变更类型、影响范围、风险等级、回滚难度。只有字段统一，团队评审时才能在同一尺度上争论，而不是各说各话。
登记册字段定义
| 字段 | 取值示例 | 判断依据 |
|---|---|---|
| 变更类型 | 配置 / 代码 / 数据 / 基础设施 | 按变更对象归类，决定后续影响矩阵 |
| 影响范围 | 单服务 / 多服务 / 全站 | 按调用链上下游与用户可见面判断 |
| 风险等级 | 高 / 中 / 低 | 影响范围 × 变更类型 × 可观测性缺口 |
| 回滚难度 | 一键回滚 / 需人工 / 不可逆 | 是否有幂等回滚路径、数据是否已写入 |
典型线上系统示例：近期变更项
假设一个电商订单系统，近期计划中的变更项如下（示例数据，用于教学）：
- 变更A：订单服务连接池参数调整（配置类，单服务，影响下单接口，可一键回滚）
- 变更B：优惠券计算逻辑灰度发布（代码类，多服务，影响结算金额，需人工回滚）
- 变更C：订单表新增索引（数据类，单服务，影响查询性能，不可逆但可在线执行）
- 变更D：网关节点扩容（基础设施类，全站，影响所有入口流量，可一键回滚）
团队评审：从登记册到行动项
评审不是逐条念表，而是围绕“高风险 + 难回滚”区域集中讨论。以上图为例，变更B（优惠券灰度）落在高风险、需人工回滚象限，应优先安排：
- 确认灰度批次与回滚脚本是否已就绪；
- 指定变更窗口与观察指标（结算成功率、金额偏差）；
- 明确回滚触发条件（如5分钟内错误率超过0.5%）。
变更C（订单表索引）虽风险中等，但回滚不可逆，评审时应确认：是否已备份、是否在低峰期执行、是否有在线DDL方案。变更A和D风险较低且可一键回滚，可简化评审，但仍需登记以便追踪。
登记册的价值在于“先分类、再排序、后行动”。没有登记册，评审容易变成对最熟悉变更的反复讨论；有了登记册，团队可以按风险等级分配注意力，把有限的时间花在真正可能引发故障的变更上。
评审后的登记册更新
评审结束后，登记册应补充以下字段并归档：评审结论（通过/有条件通过/驳回）、责任人、计划执行时间、回滚验证方式。这样下一次变更评审时，可以直接参考历史登记册中的相似变更，减少重复判断。