运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
变更管理平台（Change Management Platform）
下面我从“生产系统风险控制中枢”的视角，对 变更管理平台（Change Management Platform）进行一次企业级、强治理、可演进的系统性拆解。重点不是“怎么提单”，而是：如何让系统变化始终处于可控、可审计、可回退的状态。
一、变更管理平台的本质定位
1️⃣ 一句话定义
变更管理平台，是对一切可能影响生产稳定性的“主动行为”进行统一评估、控制、执行、验证和复盘的风险治理中枢。
关键词：
- Risk Control
- Governance
- Decouple
- Auditability
2️⃣ 为什么“现代系统”更需要变更管理
| 传统理解 | 现实情况 |
|---|---|
| 变更是低频 | 变更是高频常态 |
| 发布=变更 | 配置 / 策略 / 灰度 / 流量都是变更 |
| 审批是重点 | 风险评估与回滚才是重点 |
经验事实：
超过 70% 的重大事故，与变更直接或间接相关。
二、变更的统一对象模型（核心）
1️⃣ 什么是“变更”
凡是可能影响线上系统行为、性能、安全、用户体验的动作，都是变更。
常见变更类型
- 应用发布（Release）
- 配置变更
- Feature Flag 调整
- 流量策略
- 基础设施变更
2️⃣ 变更对象的核心字段
- 变更类型
- 影响系统 / 服务
- 风险等级
- 执行窗口
- 回滚方案
- 验证指标
📌 没有回滚方案的变更，本质上是“赌博”。
三、变更管理平台的核心能力模块
1️⃣ 变更计划（Plan）
- 变更描述
- 影响范围（CMDB）
- 风险评估
- 验证标准
自动校验：
- 是否在冻结期
- 是否有未关闭事件
- 是否触碰 Error Budget
2️⃣ 评审与审批（Review & Approve）
不是“走流程”，而是风险门禁：
- 自动审批（低风险）
- 人工审批（高风险）
- 责任人明确
3️⃣ 变更执行（Execute）
- 自动化执行（CI/CD / API）
- 灰度 / 分批
- 实时监控
4️⃣ 变更验证（Verify）
- 指标对比（Before / After）
- SLO 校验
- 用户体验监测
5️⃣ 回滚与止血（Rollback）
- 自动回滚
- 一键回退
- Kill Switch
6️⃣ 复盘与审计（Review & Audit）
- 影响评估
- 是否触发事件
- 流程是否合理
四、变更风险控制的关键能力（平台价值）
1️⃣ 风险分级模型
| 级别 | 特征 |
|---|---|
| Low | 配置 / 开关 |
| Medium | 功能灰度 |
| High | 架构 / 数据 |
2️⃣ 变更门禁（Change Gate）
- 冻结窗口
- SLO 门禁
- 事件门禁
- 安全门禁
3️⃣ 变更与事故的强关联
Change #123
↓
Alert
↓
Incident
👉 平台可自动标记：
- 变更引入风险
- 是否需回滚
五、与周边平台的协同关系
与发布平台
- 发布即变更来源
- 执行通道
与灰度平台
- 生效控制
- 风险放量
与配置中心
- 配置即变更
- 即时回滚
与事件中心
- 事故自动关联
- 快速止血
与 CMDB
- 影响面分析
- Owner 定位
六、常见失败模式（真实教训）
- 变更只剩审批
- 发布绕过平台
- 没有回滚路径
- 变更记录不可追溯
七、成熟度演进模型
L1：人工审批
- 表单 + 邮件
L2：平台化
- 统一登记
L3：自动化
- 自动执行 / 回滚
L4：SRE 化
- Error Budget 驱动
L5：智能化
- 风险预测
- 自动止损
八、一句话总结（适合对内宣讲）
变更管理平台不是“拖慢发布的官僚系统”，而是：让系统敢于高频变化却依然稳定的“风险缓冲器”。
