2026年1月29日，PeopleCert正式发布了ITIL ITIL (Version 5)。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL (Version 5)到底有哪些重大的更新。






研发负责人和交付负责人对“交付速度”一定不陌生：需求很多、窗口很紧、依赖很多、风险很大。你最常遇到的矛盾，是两股力量在拉扯：

• 业务希望更快：交付周期要短，吞吐量要高
• 运维与治理希望更稳：事故要少，风险要可控
  

过去很多组织用一种简单粗暴的方式解决：要么牺牲速度，要么牺牲稳定性。牺牲速度就会被业务抱怨“拖”；牺牲稳定性就会被事故追着跑，最后交付周期反而更长。真正高水平的组织，解决方式不是二选一，而是让工程实践与治理控制点一起进场：在构建阶段把质量门禁、证据链、可观测性与运营准备做进去，把“快”做成可持续能力。

ITIL 第5版把 Build（构建）作为生命周期关键活动，并把敏捷与 DevOps 视为默认语境，就是在给你一个更成熟的解法：构建不是写完代码就结束，而是交付一个可运营、可验证、可持续改进的成果。你要交付的是“可运行的软件”，更要交付“可被治理的系统”。


一、更新内容概述：六个要点如何改变构建阶段的定义

我们先来回顾一下 ITIL 第5版的核心更新内容。我会从构建阶段的视角解释：为什么新版本更强调工程与治理一体。

1、定位升级：数字化产品和服务管理
构建不再服务于一次性交付，而服务于数字化产品与服务的持续运营。构建阶段必须考虑后续运营、交付与支持的成本与体验。

2、生命周期模型升级：八个活动覆盖从发现到支持
Build 处在 Acquire 之后、Transition 之前，它必须承接前期的价值假设与验收准则，并为转换提供可验证、可回滚、可监控的交付物。

3、人工智能进入方法论核心
AI 会进入构建：代码生成、测试生成、缺陷分析、知识生成、自动化编排。它带来效率，也带来风险边界与证据链要求。构建阶段必须把控制点设计进去。

4、指导原则更强调取舍：尤其是优化和自动化
持续集成与持续交付本质上是“优化和自动化”的工程化落地。但取舍必须明确：哪些能自动化，哪些必须人工确认；哪些高风险变更要更强门禁。

5、实践从清单走向组件库：强调适用性与可裁剪
构建阶段要组合多种实践：软件开发与管理、服务验证与测试、部署管理、变更实施、配置管理、度量与报告等。组合要围绕价值流与风险等级裁剪。

6、持续改进贯穿
构建阶段不只是产出版本，还要产出反馈回路：质量数据、缺陷数据、发布后指标、回滚信息，这些都要能反哺下一轮改进。

你会看到，ITIL 第5版把 Build 放在“端到端能力链”里看，因此它天然要求敏捷与 DevOps 不再是外挂，而是默认的工作方式。



二、敏捷与 DevOps 为什么不再是外挂：因为价值流已经不允许你“开发完再交给别人”

很多组织把敏捷理解成迭代节奏，把 DevOps 理解成自动化流水线。但真正让它们成为默认语境的原因，是价值流的变化：从发现到支持的链条更紧，交付周期被压缩，交接成本被放大。你再用“开发完丢给运维”的方式，链条一定断。

ITIL 第5版的隐含要求是：构建阶段就要把后续的需求考虑进去。你至少要做到三件事：

• 把运营需求当作验收准则的一部分，而不是上线后的抱怨
• 把质量门禁嵌进流水线，而不是靠人肉评审兜底
• 把协作机制做进工作流，而不是靠“临时拉群”解决
  
  

当这三件事成为默认，敏捷与 DevOps 才会从“方法选择”变成“组织能力”。




三、构建阶段的验收准则要升级：从“完成开发”到“可运营的交付物”

很多交付失败，本质上是验收准则写错了。你把“完成开发、完成测试、完成上线”当成完成标准，但这些只是活动完成，不等于成果完成。

在 ITIL 第5版语境下，构建阶段的验收准则应该至少包含四类内容：
1、功能验收：满足核心用例与业务目标

• 用例覆盖是否达标
• 关键路径是否稳定可用
• 不只是功能存在，而是功能在真实场景下可用
  
  

2、质量验收：缺陷水平与性能基线

• 严重缺陷是否清零
• 性能与容量是否达到基线
• 安全与合规扫描是否达标
  
  

3、可运维性验收：可观测性与恢复能力

• 关键指标是否可监控，日志是否可检索
• 告警是否合理，噪声是否控制
• 回滚与恢复是否经过验证
  
  

4、治理验收：证据链与责任边界

• 配置项与配置记录是否齐全
• 更轨迹是否可追溯
• 谁批准、依据是什么、门禁是否执行，是否可审计
  
  

当验收准则这样写，你的构建阶段才会逼迫团队把“上线后会痛的地方”提前解决。



四、把流水线做成治理工具：质量门禁、风险门禁与人工确认点

研发负责人最需要的不是更多会议，而是一条可靠的交付流水线。可靠不是指“永远不出错”，而是指“错误能被尽早发现、影响可控、恢复有路”。

我建议你把流水线至少做成三层门禁：
1、质量门禁：防止缺陷与性能问题进入生产

• 单元测试、集成测试、服务验证与测试必须自动化
• 覆盖率、关键用例通过率、性能基线达标作为门禁条件
• 不达标就不能推进，而不是“先上线再补”
  
  

2、风险门禁：按风险等级裁剪控制强度

• 标准变更可以更快，但必须满足预设条件
• 高风险变更必须人工批准，必须有回滚方案
• 关键业务功能相关变更必须增加验证与监控
  
  

3、人工确认点：把人放在该放的位置

• 人不应该做重复手工操作
• 人应该做价值判断与高风险决策
  
  

所以人工确认点要留在高风险决策处，而不是留在流水线每一步
这样做的结果是：你既能提高速度，又能保持风险可控。因为控制点被放在关键处，而不是平均分配到每个人身上。



五、配置记录与证据链：交付越快，越需要可追溯

交付节奏一旦快起来，最容易被忽略的是配置记录与证据链。很多团队觉得“记录会拖慢速度”，于是把记录当负担。可现实是：交付越快，一旦出事，缺记录的代价越大。

你至少要保证三类东西可追溯：
1、配置项 (CI) 与依赖关系

• 交付物关联哪些服务与配置项
• 依赖哪些组件、哪些外部能力
• 版本与环境关系是否清晰
  
  

2、变更轨迹

• 谁发起、谁批准、谁执行
• 依据是什么，验收准则是什么
• 哪些自动化动作被触发，结果如何
  
  

3、知识与沟通记录

• 发布说明、已知问题、回滚路径
• 重大变更的风险提示与沟通模板
  
  

这些不是文档洁癖，而是让支持与运营在关键时刻有路可走。
ITIL 第5版强调可审计性与治理，就是在告诉你：速度不能用“不可追溯”去换。不可追溯带来的不是快，而是未来的慢。



六、把运营准备做进构建：别等到 Transition 才发现“这东西不好运维”

很多组织把运营准备推到转换阶段，结果在上线前几天才发现：

• 监控没接
• 告警没配
• 日志看不懂
• 回滚没演练
• 支持团队不了解变更内容
  
  

这会直接导致上线风险飙升，最后被迫延期或带病上线。ITIL v5 把 Operate、Deliver、Support 拆开讲，也是为了提醒你：运营、交付、支持都是专业能力，不是上线后一把抓。

所以构建阶段就要与运营、支持对齐：

• 可观测性方案：指标、日志、追踪、告警
• 恢复策略：回滚、降级、灾难恢复计划触发条件
• 支持准备：知识条目、常见问题、升级路径与责任
  
  

当这些成为构建验收的一部分，你的上线会更稳，交付也更快。



七、AI 进入构建：别让“效率工具”变成“风险放大器”

AI 在构建阶段有巨大价值：生成代码、生成测试、辅助排查、生成文档。但你必须守住能力边界与治理控制点：

• 代码与测试的关键改动必须经过人工审核
• 关键安全与合规扫描不能被跳过
• AI 生成的文档必须可追溯来源，不能凭空编造
• 自动化脚本必须有回滚与失败恢复机制
  
  

你越追求速度，越要把这些控制点做扎实。否则 AI 会把错误规模化，你得到的是更快的事故，而不是更快的交付。


ITIL 第5版把 Build 放进端到端生命周期，并把敏捷与 DevOps 视为默认语境，是为了让交付速度与治理可控不再对立。构建阶段的关键不是“把功能做出来”，而是交付一个可运营、可验证、可追溯的成果：验收准则要成果化，流水线要内建门禁，配置记录与证据链要可审计，运营准备要前置。你把这些做成工程纪律，速度自然会上来，而且上来得更稳。


欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。

2026年1月29日，PeopleCert正式发布了ITIL ITIL (Version 5)。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL (Version 5)到底有哪些重大的更新。






研发负责人和交付负责人对“交付速度”一定不陌生：需求很多、窗口很紧、依赖很多、风险很大。你最常遇到的矛盾，是两股力量在拉扯：

• 业务希望更快：交付周期要短，吞吐量要高
• 运维与治理希望更稳：事故要少，风险要可控
  

过去很多组织用一种简单粗暴的方式解决：要么牺牲速度，要么牺牲稳定性。牺牲速度就会被业务抱怨“拖”；牺牲稳定性就会被事故追着跑，最后交付周期反而更长。真正高水平的组织，解决方式不是二选一，而是让工程实践与治理控制点一起进场：在构建阶段把质量门禁、证据链、可观测性与运营准备做进去，把“快”做成可持续能力。

ITIL 第5版把 Build（构建）作为生命周期关键活动，并把敏捷与 DevOps 视为默认语境，就是在给你一个更成熟的解法：构建不是写完代码就结束，而是交付一个可运营、可验证、可持续改进的成果。你要交付的是“可运行的软件”，更要交付“可被治理的系统”。


一、更新内容概述：六个要点如何改变构建阶段的定义

我们先来回顾一下 ITIL 第5版的核心更新内容。我会从构建阶段的视角解释：为什么新版本更强调工程与治理一体。

1、定位升级：数字化产品和服务管理
构建不再服务于一次性交付，而服务于数字化产品与服务的持续运营。构建阶段必须考虑后续运营、交付与支持的成本与体验。

2、生命周期模型升级：八个活动覆盖从发现到支持
Build 处在 Acquire 之后、Transition 之前，它必须承接前期的价值假设与验收准则，并为转换提供可验证、可回滚、可监控的交付物。

3、人工智能进入方法论核心
AI 会进入构建：代码生成、测试生成、缺陷分析、知识生成、自动化编排。它带来效率，也带来风险边界与证据链要求。构建阶段必须把控制点设计进去。

4、指导原则更强调取舍：尤其是优化和自动化
持续集成与持续交付本质上是“优化和自动化”的工程化落地。但取舍必须明确：哪些能自动化，哪些必须人工确认；哪些高风险变更要更强门禁。

5、实践从清单走向组件库：强调适用性与可裁剪
构建阶段要组合多种实践：软件开发与管理、服务验证与测试、部署管理、变更实施、配置管理、度量与报告等。组合要围绕价值流与风险等级裁剪。

6、持续改进贯穿
构建阶段不只是产出版本，还要产出反馈回路：质量数据、缺陷数据、发布后指标、回滚信息，这些都要能反哺下一轮改进。

你会看到，ITIL 第5版把 Build 放在“端到端能力链”里看，因此它天然要求敏捷与 DevOps 不再是外挂，而是默认的工作方式。



二、敏捷与 DevOps 为什么不再是外挂：因为价值流已经不允许你“开发完再交给别人”

很多组织把敏捷理解成迭代节奏，把 DevOps 理解成自动化流水线。但真正让它们成为默认语境的原因，是价值流的变化：从发现到支持的链条更紧，交付周期被压缩，交接成本被放大。你再用“开发完丢给运维”的方式，链条一定断。

ITIL 第5版的隐含要求是：构建阶段就要把后续的需求考虑进去。你至少要做到三件事：

• 把运营需求当作验收准则的一部分，而不是上线后的抱怨
• 把质量门禁嵌进流水线，而不是靠人肉评审兜底
• 把协作机制做进工作流，而不是靠“临时拉群”解决
  
  

当这三件事成为默认，敏捷与 DevOps 才会从“方法选择”变成“组织能力”。




三、构建阶段的验收准则要升级：从“完成开发”到“可运营的交付物”

很多交付失败，本质上是验收准则写错了。你把“完成开发、完成测试、完成上线”当成完成标准，但这些只是活动完成，不等于成果完成。

在 ITIL 第5版语境下，构建阶段的验收准则应该至少包含四类内容：
1、功能验收：满足核心用例与业务目标

• 用例覆盖是否达标
• 关键路径是否稳定可用
• 不只是功能存在，而是功能在真实场景下可用
  
  

2、质量验收：缺陷水平与性能基线

• 严重缺陷是否清零
• 性能与容量是否达到基线
• 安全与合规扫描是否达标
  
  

3、可运维性验收：可观测性与恢复能力

• 关键指标是否可监控，日志是否可检索
• 告警是否合理，噪声是否控制
• 回滚与恢复是否经过验证
  
  

4、治理验收：证据链与责任边界

• 配置项与配置记录是否齐全
• 更轨迹是否可追溯
• 谁批准、依据是什么、门禁是否执行，是否可审计
  
  

当验收准则这样写，你的构建阶段才会逼迫团队把“上线后会痛的地方”提前解决。



四、把流水线做成治理工具：质量门禁、风险门禁与人工确认点

研发负责人最需要的不是更多会议，而是一条可靠的交付流水线。可靠不是指“永远不出错”，而是指“错误能被尽早发现、影响可控、恢复有路”。

我建议你把流水线至少做成三层门禁：
1、质量门禁：防止缺陷与性能问题进入生产

• 单元测试、集成测试、服务验证与测试必须自动化
• 覆盖率、关键用例通过率、性能基线达标作为门禁条件
• 不达标就不能推进，而不是“先上线再补”
  
  

2、风险门禁：按风险等级裁剪控制强度

• 标准变更可以更快，但必须满足预设条件
• 高风险变更必须人工批准，必须有回滚方案
• 关键业务功能相关变更必须增加验证与监控
  
  

3、人工确认点：把人放在该放的位置

• 人不应该做重复手工操作
• 人应该做价值判断与高风险决策
  
  

所以人工确认点要留在高风险决策处，而不是留在流水线每一步
这样做的结果是：你既能提高速度，又能保持风险可控。因为控制点被放在关键处，而不是平均分配到每个人身上。



五、配置记录与证据链：交付越快，越需要可追溯

交付节奏一旦快起来，最容易被忽略的是配置记录与证据链。很多团队觉得“记录会拖慢速度”，于是把记录当负担。可现实是：交付越快，一旦出事，缺记录的代价越大。

你至少要保证三类东西可追溯：
1、配置项 (CI) 与依赖关系

• 交付物关联哪些服务与配置项
• 依赖哪些组件、哪些外部能力
• 版本与环境关系是否清晰
  
  

2、变更轨迹

• 谁发起、谁批准、谁执行
• 依据是什么，验收准则是什么
• 哪些自动化动作被触发，结果如何
  
  

3、知识与沟通记录

• 发布说明、已知问题、回滚路径
• 重大变更的风险提示与沟通模板
  
  

这些不是文档洁癖，而是让支持与运营在关键时刻有路可走。
ITIL 第5版强调可审计性与治理，就是在告诉你：速度不能用“不可追溯”去换。不可追溯带来的不是快，而是未来的慢。



六、把运营准备做进构建：别等到 Transition 才发现“这东西不好运维”

很多组织把运营准备推到转换阶段，结果在上线前几天才发现：

• 监控没接
• 告警没配
• 日志看不懂
• 回滚没演练
• 支持团队不了解变更内容
  
  

这会直接导致上线风险飙升，最后被迫延期或带病上线。ITIL v5 把 Operate、Deliver、Support 拆开讲，也是为了提醒你：运营、交付、支持都是专业能力，不是上线后一把抓。

所以构建阶段就要与运营、支持对齐：

• 可观测性方案：指标、日志、追踪、告警
• 恢复策略：回滚、降级、灾难恢复计划触发条件
• 支持准备：知识条目、常见问题、升级路径与责任
  
  

当这些成为构建验收的一部分，你的上线会更稳，交付也更快。



七、AI 进入构建：别让“效率工具”变成“风险放大器”

AI 在构建阶段有巨大价值：生成代码、生成测试、辅助排查、生成文档。但你必须守住能力边界与治理控制点：

• 代码与测试的关键改动必须经过人工审核
• 关键安全与合规扫描不能被跳过
• AI 生成的文档必须可追溯来源，不能凭空编造
• 自动化脚本必须有回滚与失败恢复机制
  
  

你越追求速度，越要把这些控制点做扎实。否则 AI 会把错误规模化，你得到的是更快的事故，而不是更快的交付。


ITIL 第5版把 Build 放进端到端生命周期，并把敏捷与 DevOps 视为默认语境，是为了让交付速度与治理可控不再对立。构建阶段的关键不是“把功能做出来”，而是交付一个可运营、可验证、可追溯的成果：验收准则要成果化，流水线要内建门禁，配置记录与证据链要可审计，运营准备要前置。你把这些做成工程纪律，速度自然会上来，而且上来得更稳。


欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。