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








运维、SRE、服务台负责人最熟悉的一种混乱是：

• 线上有告警要处理
• 用户申告在催
• 业务在问交付进度
• 研发在推新版本
  
  

最后所有人都在“忙”，但没有人能清楚回答：我们到底是在运营、在交付，还是在支持？三件事混在一起做，最后三件事都做不好。

ITIL 第5版把 Operate（运营）、Deliver（交付）、Support（支持）拆开讲，表面看像是“拆概念”，其实是在帮一线管理者解决一个长期痛点：目标不同的工作混在一起，就会互相消耗。运营追求稳定与可预期，交付追求按承诺把价值送达，支持追求快速响应与体验修复。你把三者混成一锅粥，最容易出现三种后果：

• 运营被交付节奏打穿，稳定性下降
• 交付被支持打断，交付周期变长
• 支持被运营与交付挤压，响应慢、满意度下降
  
  

所以这篇我用三段分别把三者点亮：它们各自的目标是什么、关键触点在哪里、该用什么指标衡量。最后再讲一件更关键的：三者怎么在端到端价值流里协同，而不是相互甩锅。




一、更新内容概述：六个要点如何让“运营、交付、支持”必须拆开


我们先来回顾一下 ITIL v5 的核心更新内容。我会从一线运营视角解释：为什么这六个变化逼着我们把三者拆开。

1、定位升级：数字化产品和服务管理
端到端体验成为核心后，支持不再只是“接电话”，交付不再只是“交东西”，运营不再只是“守系统”。三者都直接影响体验与价值流。

2、生命周期模型升级：八个活动覆盖从发现到支持
后半段的三项活动被拆开，意味着组织需要更清楚的责任与协作边界，而不是用一个“运维部”兜住所有事。

3、人工智能进入方法论核心
生成式 AI、自动化编排、智能服务台的引入，会重塑支持与运营的工作方式。边界不清时，AI 最容易变成噪声制造机。

4、指导原则更强调取舍：尤其是优化和自动化
自动化应该优先用在重复劳动与可控动作上，而不是让一线人员疲于应付。要做到这一点，必须区分运营的控制点、交付的承诺点、支持的触点。

5、实践从清单走向组件库：强调适用性与可裁剪
运营、交付、支持需要组合不同实践组件。你如果不拆开，就很难裁剪，也很难明确优先级与度量。

6、持续改进的对象扩大
改进不只是改一个流程，而是改整个管理系统。运营、交付、支持的反馈回路不同，输入输出不同，必须拆开才能形成闭环。

你会发现，拆开不是为了复杂化，而是为了让目标更清楚、协作更顺畅、度量更真实。



二、Operate（运营）：目标是稳定与可预期，关键触点在“系统行为”

运营的核心对象是运行中的系统：基础架构、平台、服务、容量、性能、可用性与安全。运营工作的成功，不是“今天没出事”，而是“即使出事也能快速恢复，并且系统越来越可预期”。

1、运营的目标

• 稳定：可用性、可靠性、性能稳定
• 可预期：容量趋势可预测，风险可控
• 可恢复：出现中断或重大事件时恢复路径明确
  
  

2、运营的关键触点

• 告警与事件触发：监控系统、日志、追踪、仪表板
• 重大事件处置：协调、恢复、沟通与复盘
• 风险控制点：变更冻结、容量红线、关键依赖监控
  
  

3、运营的关键指标

• 可用性与可靠性相关指标
• 平均恢复时间与重大事件数量
• 告警质量：噪声比例、误报率、漏报率
• 资源利用率与容量趋势
  
  

运营的一个典型误区，是被动救火，把运维做成事故处理工厂。ITIL 第5版强调持续改进，就是希望你把运营从“救火”拉回“工程化可预期”：用可观测性与数据治理，减少意外，缩短恢复。


三、Deliver（交付）：目标是把价值按承诺送达，关键触点在“承诺与验收”


交付的核心对象是承诺：承诺给业务团队、承诺给客户组织、承诺给内部用户。交付做得好，靠的不是加班，而是节奏、质量门禁与端到端协作。

1、交付的目标

• 按承诺交付：范围、时间、质量符合预期
• 把价值送达：用户能用、体验能感知
• 风险可控：上线节奏与变更冲突可管理
  
  

2、交付的关键触点

• 发布节奏与变更日程：避免风险叠加
• 验收准则：成果型而不是活动型
• 稳定期验证：上线后指标收敛，风险曲线回落
  
  

3、交付的关键指标

• 交付周期与周期时间
• 发布成功率、回滚率
• 返工率与缺陷泄漏率
• 关键触点体验指标的变化
  
  

交付最怕被支持打断、被运营卡住。拆开 Deliver 的意义，是让交付有清晰节奏与门禁，而不是在告警与用户申告的缝隙里挤时间。


四、Support（支持）：目标是修复体验与信任，关键触点在“人”


支持的核心对象是人：服务用户、业务团队、客户代表。支持做得好，不是“工单关得快”，而是“用户感知被修复，信任被恢复，问题能被定位并转化为改进”。

1、支持的目标

• 快速响应：让用户知道有人在处理
• 快速恢复体验：能解决就解决，不能解决就正确升级
• 把问题变成改进输入：避免同类问题重复出现
  
  

2、支持的关键触点

• 服务台与多渠道入口：电话、门户、聊天机器人
• 分类与分派：优先级排序、正确升级
• 集中会诊 (swar**)：复杂问题快速拉齐专家协作
• 知识管理：可用、可追溯、版本化的知识条目
  
  

3、支持的关键指标

• 首次响应时间与一次解决率
• 升级率与误分派率
• 用户满意度与投诉率
• 知识命中率与知识质量指标
  
  

支持最容易被误解成“接单与分派”。ITIL 第5版强调体验与 AI，是希望支持能成为体验修复的前线与持续改进的入口，而不是信息中转站。


五、为什么一定要拆开：三者的边界一清，协作反而更顺


拆开不是画三条墙，而是划清边界之后更容易协作。你可以这样理解三者的分工：

• 运营负责系统健康：让系统稳定、可观测、可恢复
• 交付负责价值落地：把变更可控地送到用户手里，并验证稳定期
• 支持负责体验修复：接住用户申告，正确升级，修复信任，并把问题回流到改进
  
  

当边界清楚，协作就会自然形成：

• 支持发现高频问题，把数据与案例回流给运营做根因消除
• 运营发现风险趋势，把控制点与告警优化回流给交付调整发布节奏
• 交付把变更内容、已知问题与回滚路径提前交付给支持，减少上线后的混乱
  
  

这就是端到端价值流的协作方式：不是谁背锅，而是谁接住哪段链条。



六、AI 与自动化在三者之间怎么放：别让“智能支持”变成“智能噪声”


很多组织最先在 Support 上引入生成式 AI：聊天机器人、智能检索、自动回复。方向没错，但如果运营与交付不配合，AI 会很快制造噪声。

我建议你把 AI 与自动化按三者边界放好位置：
1、支持侧：AI 优先做“检索、摘要、初步分类”，谨慎做“对外承诺”

• AI 可以辅助检索知识、汇总工单历史
• AI 可以做初步分类与分派建议
• 对外回复与关键承诺必须人工审核，避免误导
  
  

2、运营侧：自动化优先做“可回滚的补救动作”，并强化可观测性

• 自动补救要有阈值、暂停权与回滚机制
• 关键在证据链：执行轨迹可追溯，失败可恢复
  
  

3、交付侧：自动化优先做“门禁后的部署执行”，AI 辅助风险评估

• AI 可以提示依赖冲突与风险模式
• 批准必须由变更授权人承担责任
• 门禁与稳定期验证必须保留
  
  

这样放置，你会得到真正的效率，而不是更快的混乱。


七、把三者做成一个闭环：支持输入、运营修复、交付固化

最后我想给你一个一线非常实用的闭环模型：

• 支持负责收集：高频用户申告、错误模式、体验断点
• 运营负责修复：根因消除、可观测性增强、自动化补救
• 交付负责固化：把修复变成可复制的发布规范、门禁、验收准则与知识
  
  

当这个闭环跑起来，你会发现三者不再互相消耗，反而互相补位。支持不再只是接单，运营不再只是救火，交付不再只是赶工。组织速度会上升，稳定性也会上升，这是 ITIL 第5版更想看到的状态。


ITIL 第5版把 Operate、Deliver、Support 拆开讲，是为了让目标更清楚、边界更明确、协作更顺畅：运营守系统健康，交付守承诺与稳定期，支持守体验与信任。你只要把三者各自的触点与指标抓牢，再用数据与证据链把协作闭环跑起来，后半段生命周期就会从“混乱现场”变成“可持续运营能力”。


我是AI+ITIL教练长河achotsao，欢迎添加长河老师微信 achotsao 深入交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。

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








运维、SRE、服务台负责人最熟悉的一种混乱是：

• 线上有告警要处理
• 用户申告在催
• 业务在问交付进度
• 研发在推新版本
  
  

最后所有人都在“忙”，但没有人能清楚回答：我们到底是在运营、在交付，还是在支持？三件事混在一起做，最后三件事都做不好。

ITIL 第5版把 Operate（运营）、Deliver（交付）、Support（支持）拆开讲，表面看像是“拆概念”，其实是在帮一线管理者解决一个长期痛点：目标不同的工作混在一起，就会互相消耗。运营追求稳定与可预期，交付追求按承诺把价值送达，支持追求快速响应与体验修复。你把三者混成一锅粥，最容易出现三种后果：

• 运营被交付节奏打穿，稳定性下降
• 交付被支持打断，交付周期变长
• 支持被运营与交付挤压，响应慢、满意度下降
  
  

所以这篇我用三段分别把三者点亮：它们各自的目标是什么、关键触点在哪里、该用什么指标衡量。最后再讲一件更关键的：三者怎么在端到端价值流里协同，而不是相互甩锅。




一、更新内容概述：六个要点如何让“运营、交付、支持”必须拆开


我们先来回顾一下 ITIL v5 的核心更新内容。我会从一线运营视角解释：为什么这六个变化逼着我们把三者拆开。

1、定位升级：数字化产品和服务管理
端到端体验成为核心后，支持不再只是“接电话”，交付不再只是“交东西”，运营不再只是“守系统”。三者都直接影响体验与价值流。

2、生命周期模型升级：八个活动覆盖从发现到支持
后半段的三项活动被拆开，意味着组织需要更清楚的责任与协作边界，而不是用一个“运维部”兜住所有事。

3、人工智能进入方法论核心
生成式 AI、自动化编排、智能服务台的引入，会重塑支持与运营的工作方式。边界不清时，AI 最容易变成噪声制造机。

4、指导原则更强调取舍：尤其是优化和自动化
自动化应该优先用在重复劳动与可控动作上，而不是让一线人员疲于应付。要做到这一点，必须区分运营的控制点、交付的承诺点、支持的触点。

5、实践从清单走向组件库：强调适用性与可裁剪
运营、交付、支持需要组合不同实践组件。你如果不拆开，就很难裁剪，也很难明确优先级与度量。

6、持续改进的对象扩大
改进不只是改一个流程，而是改整个管理系统。运营、交付、支持的反馈回路不同，输入输出不同，必须拆开才能形成闭环。

你会发现，拆开不是为了复杂化，而是为了让目标更清楚、协作更顺畅、度量更真实。



二、Operate（运营）：目标是稳定与可预期，关键触点在“系统行为”

运营的核心对象是运行中的系统：基础架构、平台、服务、容量、性能、可用性与安全。运营工作的成功，不是“今天没出事”，而是“即使出事也能快速恢复，并且系统越来越可预期”。

1、运营的目标

• 稳定：可用性、可靠性、性能稳定
• 可预期：容量趋势可预测，风险可控
• 可恢复：出现中断或重大事件时恢复路径明确
  
  

2、运营的关键触点

• 告警与事件触发：监控系统、日志、追踪、仪表板
• 重大事件处置：协调、恢复、沟通与复盘
• 风险控制点：变更冻结、容量红线、关键依赖监控
  
  

3、运营的关键指标

• 可用性与可靠性相关指标
• 平均恢复时间与重大事件数量
• 告警质量：噪声比例、误报率、漏报率
• 资源利用率与容量趋势
  
  

运营的一个典型误区，是被动救火，把运维做成事故处理工厂。ITIL 第5版强调持续改进，就是希望你把运营从“救火”拉回“工程化可预期”：用可观测性与数据治理，减少意外，缩短恢复。


三、Deliver（交付）：目标是把价值按承诺送达，关键触点在“承诺与验收”


交付的核心对象是承诺：承诺给业务团队、承诺给客户组织、承诺给内部用户。交付做得好，靠的不是加班，而是节奏、质量门禁与端到端协作。

1、交付的目标

• 按承诺交付：范围、时间、质量符合预期
• 把价值送达：用户能用、体验能感知
• 风险可控：上线节奏与变更冲突可管理
  
  

2、交付的关键触点

• 发布节奏与变更日程：避免风险叠加
• 验收准则：成果型而不是活动型
• 稳定期验证：上线后指标收敛，风险曲线回落
  
  

3、交付的关键指标

• 交付周期与周期时间
• 发布成功率、回滚率
• 返工率与缺陷泄漏率
• 关键触点体验指标的变化
  
  

交付最怕被支持打断、被运营卡住。拆开 Deliver 的意义，是让交付有清晰节奏与门禁，而不是在告警与用户申告的缝隙里挤时间。


四、Support（支持）：目标是修复体验与信任，关键触点在“人”


支持的核心对象是人：服务用户、业务团队、客户代表。支持做得好，不是“工单关得快”，而是“用户感知被修复，信任被恢复，问题能被定位并转化为改进”。

1、支持的目标

• 快速响应：让用户知道有人在处理
• 快速恢复体验：能解决就解决，不能解决就正确升级
• 把问题变成改进输入：避免同类问题重复出现
  
  

2、支持的关键触点

• 服务台与多渠道入口：电话、门户、聊天机器人
• 分类与分派：优先级排序、正确升级
• 集中会诊 (swar**)：复杂问题快速拉齐专家协作
• 知识管理：可用、可追溯、版本化的知识条目
  
  

3、支持的关键指标

• 首次响应时间与一次解决率
• 升级率与误分派率
• 用户满意度与投诉率
• 知识命中率与知识质量指标
  
  

支持最容易被误解成“接单与分派”。ITIL 第5版强调体验与 AI，是希望支持能成为体验修复的前线与持续改进的入口，而不是信息中转站。


五、为什么一定要拆开：三者的边界一清，协作反而更顺


拆开不是画三条墙，而是划清边界之后更容易协作。你可以这样理解三者的分工：

• 运营负责系统健康：让系统稳定、可观测、可恢复
• 交付负责价值落地：把变更可控地送到用户手里，并验证稳定期
• 支持负责体验修复：接住用户申告，正确升级，修复信任，并把问题回流到改进
  
  

当边界清楚，协作就会自然形成：

• 支持发现高频问题，把数据与案例回流给运营做根因消除
• 运营发现风险趋势，把控制点与告警优化回流给交付调整发布节奏
• 交付把变更内容、已知问题与回滚路径提前交付给支持，减少上线后的混乱
  
  

这就是端到端价值流的协作方式：不是谁背锅，而是谁接住哪段链条。



六、AI 与自动化在三者之间怎么放：别让“智能支持”变成“智能噪声”


很多组织最先在 Support 上引入生成式 AI：聊天机器人、智能检索、自动回复。方向没错，但如果运营与交付不配合，AI 会很快制造噪声。

我建议你把 AI 与自动化按三者边界放好位置：
1、支持侧：AI 优先做“检索、摘要、初步分类”，谨慎做“对外承诺”

• AI 可以辅助检索知识、汇总工单历史
• AI 可以做初步分类与分派建议
• 对外回复与关键承诺必须人工审核，避免误导
  
  

2、运营侧：自动化优先做“可回滚的补救动作”，并强化可观测性

• 自动补救要有阈值、暂停权与回滚机制
• 关键在证据链：执行轨迹可追溯，失败可恢复
  
  

3、交付侧：自动化优先做“门禁后的部署执行”，AI 辅助风险评估

• AI 可以提示依赖冲突与风险模式
• 批准必须由变更授权人承担责任
• 门禁与稳定期验证必须保留
  
  

这样放置，你会得到真正的效率，而不是更快的混乱。


七、把三者做成一个闭环：支持输入、运营修复、交付固化

最后我想给你一个一线非常实用的闭环模型：

• 支持负责收集：高频用户申告、错误模式、体验断点
• 运营负责修复：根因消除、可观测性增强、自动化补救
• 交付负责固化：把修复变成可复制的发布规范、门禁、验收准则与知识
  
  

当这个闭环跑起来，你会发现三者不再互相消耗，反而互相补位。支持不再只是接单，运营不再只是救火，交付不再只是赶工。组织速度会上升，稳定性也会上升，这是 ITIL 第5版更想看到的状态。


ITIL 第5版把 Operate、Deliver、Support 拆开讲，是为了让目标更清楚、边界更明确、协作更顺畅：运营守系统健康，交付守承诺与稳定期，支持守体验与信任。你只要把三者各自的触点与指标抓牢，再用数据与证据链把协作闭环跑起来，后半段生命周期就会从“混乱现场”变成“可持续运营能力”。


我是AI+ITIL教练长河achotsao，欢迎添加长河老师微信 achotsao 深入交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。