006：变更管控专项（SRE 稳定性 · 变更三板斧 / 灰度 / 评审 / 回滚 SOP）
变更管控专项（变更三板斧对照 · 灰度策略 / 评审必检 / 冻结窗口 · 变更回滚预案 SOP 工程化）
体系定位：变更管控专项（变更三板斧对照 · 灰度策略 / 评审必检 / 冻结窗口 · 变更回滚预案 SOP 工程化） 来源文件数：3（从 005_容灾止损专项.md 拆出：三板斧对照表 + 事故响应手册 8.2(4) 变更管控 + 8.3 预案 SOP） 说明：内容原封不动拆出，仅调整标题层级与图片相对路径
📑 目录
1 稳定性三板斧总纲：变更 / 监控 / 容灾对称对照（面试背这套）
三个 "三板斧" 对称表达（面试背这套对照）：
| 三板斧 | 表达 | 缺一不可的含义 | 与变更的映射 |
|---|---|---|---|
| 变更 | 可灰度、可监控、可回滚 | 没有灰度 = 直接全量炸；没有监控 = 炸了不知道；没有回滚 = 知道了回不去 | 基准 |
| ### 1.1 变更管控（因为多数故障来自变更） |
-
变更三板斧：可灰度、可监控、可回滚（缺一不可上线）。
-
灰度策略：1% → 10% → 50% → 100%，每档观察窗口 + 自动熔断回滚。
-
变更评审必检项：DB 索引 / 慢查询影响、容量影响、依赖影响、回滚方案、是否覆盖非核心路径（TikTok / 支付案例的共同缺口）。
-
变更冻结窗口：大促、节假日、重大迁移后加固期禁止非必要变更。
1.2 预案（SOP）工程化
一条工程化的预案必须具备三要素（可被自动化执行的前提）：
sop\_id: rollback-order-db
trigger: # 触发条件（可机器判定）
  - metric: order\_svc.error\_rate
  op: ">"
  threshold: 0.05
  duration: 3m
steps: # 操作步骤（原子、幂等、可 dry-run）
  - id: 1
  action: traffic.shift
  params: { from: az-a, to: az-b, ratio: 100 }
  blast\_radius: 高 # 低/中/高，决定审批级别
  dry\_run\_supported: true
termination: # 终止条件（成功/失败/中止）
  success: order\_svc.error\_rate < 0.01 for 5m
  abort: order\_svc.error\_rate > 0.15 # 恶化则立即中止
rollback: # 预案自身的回退方案
  - action: traffic.shift
  params: { from: az-b, to: az-a, ratio: 100 }
面试加分点
：能指出「预案必须有
终止条件
和
预案自身的回滚方案
」。绝大多数团队的预案只写了操作步骤，没写「什么情况下要停手」，导致自动化预案反而放大事故。