云上变更管理实战：从人工审批到自动化发布，别再让变更背锅

去年一个客户，周五下午发了个变更，改了一行配置。结果连锁反应，整个周末都在修故障。周一复盘，所有人都在问：谁批的？为什么没人审？为什么没回滚方案？

最后结论：变更流程有问题。

这是大多数公司的真实写照：出事之前，没人关心变更流程；出事之后，所有人都怪变更流程。

今天聊聊云上变更管理。不是那种“变更要走审批”的废话，而是帮你理清楚：怎么分类变更、怎么设计审批流程、怎么用自动化降低风险、怎么让变更不再背锅。

01 不是所有变更都需要审批

很多人理解变更管理，就是“上线前找领导签个字”。这是对变更管理最大的误解。

变更管理的目的是控制风险，不是制造流程。不同风险的变更，应该走不同的路。

低风险变更：自动化执行，事后审计

• 修改非核心配置、日常运维操作、常规发布

• 不需要人工审批，但要留日志，能追溯到谁在什么时候做了什么

中风险变更：简单审批，自动化执行

• 修改核心配置、发布新功能、扩缩容

• 需要技术负责人确认，但执行可以自动化

高风险变更：严格审批，计划窗口，必须有回滚方案

• 数据库迁移、架构调整、核心系统重构

• 需要变更评审委员会（CAB）审批，必须在指定窗口执行，必须有回滚计划

那家公司出事的变更，属于高风险操作——改的是核心路由配置。但没走高风险流程，连个审批都没有。

反常识观点：审批不是越严越好。 对低风险变更设过多审批，团队会绕开流程，反而更危险。

02 变更窗口：古董还是神器？

传统ITIL有个概念叫“变更窗口”——只有特定时间才能上线。比如每周四下午2点到4点。

现代DevOps讲究持续交付，随时可以上线。这两个理念冲突吗？

不冲突。高风险变更需要窗口，低风险变更不需要。

• 数据库迁移、核心架构调整：选业务低峰期，留足回滚时间

• 日常功能发布：随时上，反正能快速回滚

那家公司把高风险变更也当日常发布，周五下午直接上，没人把关，周末修了两天。

变更窗口的价值不是限制你，是倒逼你想清楚回滚方案。 如果你觉得“随时可以上”，那也意味着“随时可能崩”。

03 回滚不是备胎，是必修课

变更管理的核心，不是“怎么上”，是“怎么下”。

每次变更必须回答三个问题：

• 如果出问题，怎么回滚？

• 回滚需要多长时间？

• 回滚会丢数据吗？

答不上来的，不许上。

回滚策略分几种：

• 原地回滚：直接恢复到上一个版本。最快，但数据库变更可能不兼容。

• 蓝绿切换：两个环境，蓝是现网，绿是新版。出问题切回蓝。秒级回滚，需要双份资源。

• 金丝雀撤离：只放少量流量到新版，有问题立刻切回。影响面最小。

那家公司改的是配置，没有回滚方案。出问题后不知道该怎么退回去，只能硬扛着修。

反常识观点：没有回滚方案的变更，等于在赌博。 回滚不是失败了才想，是上线前就想好。

04 变更审批：谁来批？怎么批？

审批流程不是越复杂越好。关键是：谁有能力判断风险？谁能为结果负责？

审批矩阵示例：

变更评审委员会（CAB） 不用天天开会。可以搞个“变更周会”，每周一次集中评审下周的高风险变更。

那家公司后来设立了CAB，高风险变更必须三人签字：技术负责人、运维负责人、安全负责人。每周三开评审会，通过后才能排期到周四上线。

05 自动化发布 + 人工门禁

现代变更管理，不是“手动执行”，也不是“完全自动”。是自动化执行 + 人工门禁。

• 自动化构建、自动化测试、自动化部署

• 在关键节点插入人工确认：测试通过后、上线前、切流量前

好处：

• 人工只做决策，不执行操作（避免手误）

• 执行过程可重复、可审计

• 紧急变更可以跳过某些门禁，但要留下记录

那家公司后来把发布流程改成：CI/CD自动打包、自动部署到测试环境，然后人工在钉钉点“确认上线”，自动部署到生产。每个步骤都有日志，谁批准的、什么时间执行的，一清二楚。

06 一个真实案例：从无流程到规范化

一个金融客户，之前没有变更管理。谁都能上生产，没有审批、没有窗口、没有回滚方案。一年出了三次重大故障，都是变更引起的。

我们帮他们建立了变更管理流程：

第一步：变更分类。 梳理所有变更类型，按风险分三类。

第二步：审批矩阵。 中风险找技术负责人，高风险开CAB会。低风险自动执行。

第三步：变更窗口。 高风险变更只能在周二、周四下午2-4点执行。其他时间锁住。

第四步：自动化发布。 CI/CD流水线，人工只负责“点确认”。

第五步：变更日历。 所有变更排进日历，避免冲突。周一看这周要上什么，周四复盘上周上了什么。

推行半年后，变更导致的故障从一年三次降到零。运维负责人说：“以前变更像拆弹，现在变更像流水线。”

写在最后

变更管理这事，说复杂也复杂，说简单也简单。复杂在要分类、要审批、要窗口、要回滚。简单在核心只有一条：别让变更成为事故的唯一原因。

那家公司的运维负责人后来总结了一句话：“以前觉得变更流程是束缚，现在觉得是保护。保护系统不被瞎改，保护工程师不被背锅。”

你的变更，现在有流程吗？还是出事了才想起来要管？