---
url: /sre/devops/cicd/change-management.md
description: SRE 变更管理核心原则与发布准入机制，践行「可灰度、可观测、可回滚」的变更管理金科玉律。
---

在 SRE 运维体系中，有一句公认的行业共识：「**生产环境 70% 的故障是由变更引起的。**」

所谓变更，是指**任何对生产环境物理或逻辑状态造成系统级别变化的动作**。这不仅包括应用代码的发布，还包括数据库 DDL / DML 的执行、网络策略的修改、第三方 API 秘钥的轮转以及系统环境变量的变更。

对生产环境必须心存敬畏。为了将变更引发故障的概率和影响范围降到最低，团队应在 L5 治理阶段构建严密的变更准入与防护机制。

***

## 变更管理的三板斧原则

无论是全自动流水线还是人工干预的复杂发布，所有变更都必须遵循以下三大铁律：

### 1. 可灰度（Reduce Blast Radius）

* **核心思想**：绝不进行「全量一次性」变更。
* **落地实践**：通过金丝雀发布（Canary）、蓝绿部署或渐进式流量切分（如 $1% \to 10% \to 50% \to 100%$），确保新版本在小范围内验证。如果发生故障，影响的“爆炸半径”控制在最小范围内。

### 2. 可观测（Monitor Health Index）

* **核心思想**：如果没有监控，就等于在黑暗中开车。变更是否成功必须用客观指标来判定。
* **落地实践**：在变更执行的几分钟内，实时监控系统黄金指标（QPS、错误率、响应延迟、CPU / 内存）。在流水线中集成自动化指标探测，当错误率出现陡增时，自动触发报警并挂起变更。

### 3. 可回滚（Fail-Fast & Rollback）

* **核心思想**：任何变更在动工前，必须准备好一键回滚的退路。
* **落地实践**：对于无状态应用，保障老版本容器镜像随时可拉起同步；对于有状态变更（如数据库），必须在变更单中附带经过验证的逆向 SQL 脚本（如 Liquibase 的 rollback 机制）。

***

## 变更范畴与分级管控

团队不需要对所有变更采取相同的审批强度，否则会严重拖累交付效率。变更应分为以下三类进行精细化治理：

| 变更级别 | 典型场景 | 管控策略 | 审批流程 |
| :--- | :--- | :--- | :--- |
| **标准变更 (Standard)** | 日志级别调整、文档发布、配置白名单更新 | 预先定义好且验证过的低风险变更 | 流水线全自动执行，事后留痕 |
| **常规变更 (Normal)** | 应用大版本发布、数据库 DDL 结构变动 | 存在一定故障风险的日常迭代变动 | 触发质量门禁（SonarQube、单元测试），由技术 Owner 审批后流水线执行 |
| **紧急变更 (Emergency)** | 线上故障热修复（Hotfix）、安全漏洞紧急修补 | 恢复生产服务所必需的即时变动 | 快速通道发布，事后 24 小时内补办变更说明并进行故障复盘 |

***

## 变更就绪性审查（Readiness Review）

在正式点击「发布」按钮前，流水线或发布负责人需对照以下就绪清单进行审查（Checklists）：

* \[ ] **逆向方案**：数据库变更是否配有回滚 SQL？应用是否能在 2 分钟内一键回撤？
* \[ ] **容量评估**：当前变更是否会在启动时导致 CPU 飙升？是否有足够的服务器空闲槽位以支持滚动更新（Rolling Update）？
* \[ ] **时间窗口**：变更是否避开了业务交易的高峰期？是否避开了节假日或封网期？
* \[ ] **质量门禁**：静态代码扫描与第三方依赖漏洞扫描（SBOM）是否全部通过？
* \[ ] **通知周知**：关联的客服、产品与运营团队是否已知晓本次发布可能带来的短暂波动？

***

## 总结：从人工评审到声明式守门人

随着 DevOps 走向深水区，变更管理不应再依赖冗长低效的「人工开会评审」，而应逐步演进为**声明式的质量守门人**。

通过将变更准入条件（如测试覆盖率 $>80%$、无高危漏洞、镜像哈希一致性）写进 CI/CD 配置，配合 AI 对日志和系统指标的实时异常检测（Anomaly Detection），实现自动化的风险拦截与即时自愈。

## 参考

1. Google SRE Book - Chapter 16: Managing State
2. 变更管理定义与实践：https://zhuanlan.zhihu.com/p/1951699422309220395