在很多企业里,有一场没有硝烟的冲突。

一边是 DevOps 团队:他们追求持续交付,代码一天可能上线几十次,他们的信条是"小步快跑、快速迭代",任何拖慢交付节奏的东西都是敌人。

另一边是变更管理:它要求每个变更经过评估、审批、记录,目的是控制风险、保障稳定。在传统的变更管理流程里,一个变更走完审批可能需要几天。

当这两者相遇,冲突就来了。DevOps 团队说:你们的变更审批流程拖慢了我们的交付速度,我们一天要上线几十次,怎么可能每次都走审批?变更管理团队说:不走审批,变更失控,出了事故谁负责?

这个冲突看起来是不可调和的,但其实不是。变更管理和 DevOps 的目标,本质上是一致的——都是为了又快又稳地交付价值。冲突的根源,是用传统的变更管理方式来管理现代的交付节奏。

---

一、传统变更管理为什么和 DevOps 冲突

要调和这个冲突,先理解它的根源。

传统变更管理假设变更是低频的。 传统变更管理流程的设计,隐含了一个前提:变更是相对低频的事件,每次变更值得投入一套评估、审批、记录的流程。这个假设在变更频率低的时代是成立的,一周做几次变更,每次走审批不是大问题。

但 DevOps 和持续交付改变了变更的频率。一个采用 CI/CD 的团队,一天可能部署几十次甚至上百次。如果每次部署都走传统的人工审批流程,审批本身就会成为交付的瓶颈,这显然不可接受。

传统变更管理依赖人工审批。 传统流程里,变更审批是人工的:变更顾问委员会开会,或者审批人逐个审阅。这种人工审批,在变更频率高的环境下根本无法支撑——没有任何审批委员会能够实时审批每天几十次的部署。

传统变更管理把所有变更同等对待。 传统流程容易陷入"一刀切",所有变更都走同样的审批流程,不区分风险等级。但实际上,一个经过充分自动化测试的、低风险的标准化部署,和一次高风险的架构调整,所需的管控强度完全不同。

---

二、ITIL 4 对变更管理的重新定义

值得注意的是,ITIL 框架本身也在演进。ITIL 4 对变更管理(在 ITIL 4 里叫"变更赋能",Change Enablement)做了重新定义,核心思路就是为了适应包括 DevOps 在内的现代交付方式。

ITIL 4 强调几个关键转变:

从"变更控制"到"变更赋能"。 名称的变化反映了理念的转变:变更管理的目的不是控制和限制变更,而是赋能变更——在保障风险可控的前提下,让变更尽可能顺畅地发生。这个理念和 DevOps 的目标是一致的。

强调变更的分类管理。 ITIL 4 明确区分标准变更、普通变更、紧急变更,并强调对低风险的标准变更,应该尽可能自动化、免审批。这为 DevOps 的高频部署提供了理论框架——把经过验证的、低风险的部署定义为标准变更,就可以自动化处理。

强调自动化。 ITIL 4 鼓励变更管理流程的自动化,减少人工干预的环节。这和 DevOps 的自动化交付管道天然契合。

可以看到,ITIL 4 的变更管理理念,已经为和 DevOps 的融合打下了基础。冲突不是 ITIL 和 DevOps 之间的根本矛盾,而是传统变更管理实践和现代交付节奏之间的不适配。

---

三、标准变更:高频低风险部署的解法

调和变更管理和 DevOps 的核心工具,是"标准变更"(Standard Change)。

标准变更指的是那些经过反复验证、风险极低、有固定操作流程的变更。对于标准变更,不需要每次都审批,而是提前一次性把这类变更的操作规范和风险评估做好,之后符合这个规范的变更就可以自动执行,只需要事后记录。

把 DevOps 的常规部署定义为标准变更,是调和的关键:

预先定义部署的标准。 什么样的部署可以算作标准变更?通常是:经过了完整的自动化测试,通过了代码审查,部署流程是标准化的、可重复的,有自动化的回滚机制。满足这些条件的部署,风险是可控的,可以作为标准变更处理。

自动化测试和质量门禁作为"审批"。 在 DevOps 的环境里,变更的"审批"不再是人工审阅,而是自动化的质量门禁:代码必须通过单元测试、集成测试、安全扫描,必须通过代码审查,才能进入部署流程。这些自动化的检查,实际上承担了传统人工审批的风险控制功能,而且更严格、更一致、更快速。

部署即记录。 标准变更不需要审批,但需要记录。在 CI/CD 管道里,每次部署自动在变更管理系统里创建一条变更记录,记录部署的内容、时间、版本、执行人。这样既满足了变更可追溯的要求,又不增加任何人工负担。

通过标准变更机制,DevOps 的高频部署得以在变更管理的框架内顺畅进行:常规部署自动化执行、自动记录,不需要人工审批;变更管理对这些部署有完整的记录和可追溯性,风险通过自动化质量门禁来控制。

---

四、哪些变更仍然需要人工审批

把常规部署定义为标准变更之后,仍然有一部分变更需要保留人工审批。区分清楚哪些可以自动化、哪些需要人工把关,是变更管理和 DevOps 融合的关键。

高风险变更仍需人工评估。 数据库结构的重大调整、核心架构的变更、影响多个系统的变更,这些高风险变更即使在 DevOps 环境里,也应该保留人工的评估和审批。这类变更不是高频的,人工审批不会成为瓶颈,而它们的风险需要人的专业判断。

涉及合规的变更需要审批留痕。 某些行业的合规要求,明确规定特定类型的变更必须经过审批。这类变更需要保留人工审批环节,确保合规。

跨团队影响的变更需要协调。 一个变更如果会影响其他团队负责的系统,需要跨团队的协调和确认。这种协调,自动化无法完全替代,需要相关团队的人工参与。

首次执行的新类型变更需要验证。 一个新类型的变更,在它被验证为低风险、可以纳入标准变更之前,应该先走人工审批的普通变更流程。经过几次验证,确认它确实低风险、流程稳定之后,再把它纳入标准变更的范畴。

这种分层的处理方式——常规部署自动化、高风险变更人工把关——让变更管理既不拖慢 DevOps 的常规交付,又对真正需要管控的变更保持把关。

---

五、构建适应 DevOps 的变更管理体系

要让变更管理和 DevOps 真正融合,需要在几个方面做出调整。

变更管理系统和 CI/CD 管道集成。 变更管理系统需要能够和 CI/CD 工具集成,让部署可以自动触发变更记录的创建,部署结果可以反映到变更状态里。这种集成,是实现"部署即记录"的技术基础,避免 DevOps 团队为了满足变更管理要求而做额外的手工操作。

建立标准变更的快速通道和审核机制。 明确定义哪些变更属于标准变更,建立把新类型变更纳入标准变更的审核机制。这个机制要既严谨(确保只有真正低风险的变更才被纳入)又高效(不要让审核本身成为新的瓶颈)。

用数据持续优化变更管理。 跟踪变更相关的数据:变更成功率、变更引发的事故比例、标准变更的占比。这些数据帮助评估变更管理是否在有效控制风险,以及是否有更多的变更可以安全地纳入标准变更范畴,进一步提升交付效率。

保持变更的可追溯性。 无论是自动化的标准变更还是人工审批的变更,都要保持完整的记录和可追溯性。当出现问题时,能够快速追溯到相关的变更,这是变更管理价值的核心,在 DevOps 环境里同样重要——高频部署意味着当出问题时,需要快速判断是哪次部署引起的,完整的变更记录是这个判断的基础。

---

变更管理和 DevOps 不是对立的,而是可以融合的。融合的关键,是用现代的变更管理理念(ITIL 4 的变更赋能)和工具(标准变更、自动化、CI/CD 集成),取代传统的、假设变更低频的、依赖人工审批的旧实践。当变更管理适应了 DevOps 的节奏,它就不再是交付的阻碍,而是高频交付的安全保障——让团队既能快速交付,又能控制风险。

ManageEngine ServiceDesk Plus 的变更管理模块支持标准变更、普通变更、紧急变更的分类管理,支持与外部工具的集成,可以配置标准变更的自动化处理,保持完整的变更记录和可追溯性。对于正在探索变更管理和 DevOps 融合的团队,可以申请试用评估。