很多研发同学对ITIL天然有点抵触，我理解。过去不少组织把ITIL落地成了“流程很多、审批很重、发版很慢”，研发被卡得喘不过气。于是大家形成了一个条件反射：听到ITIL就想到“拖慢交付”。

但我想说的是，如果你把ITIL 第5版认真看一遍，会发现它这次的主线并不是“加流程”，而是“把链路打通”。它不靠多填字段来提升质量，而是靠全生命周期的对齐、治理边界的清晰、以及体验与支持回流的机制，去减少你们最讨厌的东西：返工、救火、被动加班、以及莫名其妙的锅。

我写这篇文章，就是想用研发的语言把这件事讲清楚：ITIL 第5版对研发到底有什么用，它会不会把你拖慢，哪些点能帮你更快更稳。


一、ITIL第5版不是给运维看的，是给整个交付链路看的


ITIL 第5版相对ITIL 4的核心升级，可以用几句话说清楚：

• 管理对象从以服务为中心，进一步扩展到数字产品与数字服务一起管
• 工作方式从价值链进一步落到全生命周期，用八个阶段活动把端到端拆得更具体
• 体验被更明确地纳入价值交付，强调可感知的结果，不只是内部达标
• 价值系统里的治理更强调可操作性与可选型，强调责任、监督与纠偏
• AI与自动化被纳入体系，强调能力分层与治理边界，避免“黑箱提效”带来风险
  

八个阶段活动是：发现、设计、获取、构建、转换、运营、交付、支持。你把它翻译成研发人话，就是：
需求对齐、方案设计、资源准备、实现与验证、上线准备与风险控制、稳定运行、持续交付价值、支持反馈回流。

这条链路里，研发最容易被坑的地方，恰恰在“转换”和“支持回流”上：上线前准备不足导致夜战；支持回流缺失导致同样的坑反复踩。

二、研发为什么会觉得“流程拖慢我”：因为很多组织只做了控制，没做能力提升


这里我得讲得直一点：流程让人讨厌，通常不是因为“有规则”，而是因为规则只做了控制，没有帮你把能力提升。审批流最典型：它能告诉你“你可不可以发”，但它不帮你解决“你发了会不会炸”。结果就是发版前大家忙着过审批，真正该准备的监控、演练、回滚、支持口径反而没做扎实。最后上线一炸，所有人都输。

ITIL 第5版把“转换”提出来，本质是在纠正这个偏差：控制当然要有，但更重要的是能力提升。能力提升做到了，控制可以变轻；能力提升做不到，控制越重越慢还越不安全。


三、把八个阶段活动对齐到研发链路：你会发现它更像“端到端工程实践”的框架


我们把八个阶段活动逐段对齐到研发工作，你就明白它到底在解决什么问题。

发现：别让研发替业务做决策，也别让研发背“需求没讲清”的锅研发最怕的是什么？需求不清、优先级乱、范围边界不明。发现阶段的意义，就是把价值、边界、风险讲清楚：到底解决谁的问题，为什么现在做，做到什么程度算成功，不做会有什么风险。你把这些讲清楚，研发评估才会更准，后面返工才会少。

设计：设计不是画架构图，而是把可验证、可运维、可支持写进去很多设计评审只盯架构正确性，忽略了上线后怎么跑：监控点位、日志策略、限流降级、容量评估、回滚方案、常见问题应对。这些如果不在设计阶段想清楚，你就等着上线后补洞。补洞不是不行，但补洞永远最贵，而且会把研发拉回“救火模式”。

获取：资源与依赖提前对齐，别等到上线前一周才发现缺权限、缺环境、缺供应商配合研发交付经常被“外部依赖”拖死：数据接口、权限审批、第三方组件、云资源配额、供应商响应。获取阶段做得好，研发的节奏会更稳定；做不好，研发就会在各种临时协调里被掏空。

构建：把“可验证、可回滚、可度量”当成交付的一部分构建不只是把功能做完，还要把它做成可以验证、可以回滚、可以观察的交付。测试通过不等于上线可控。你要能回答：上线后怎么看健康度？关键指标是什么？出事怎么回滚？这些不是运维的事，是工程交付质量的一部分。

转换：研发最该关心的不是“审批通过”，而是“上线准备是否完整”这是ITIL 第5版对研发帮助最大的地方之一。转换阶段要做的事很具体：发布演练、变更影响评估、监控告警接入、配置核验、支持知识与话术准备、公告与沟通节奏、应急预案与责任人到位。如果转换做得扎实，研发的收益是什么？上线夜战会少很多，事故爆炸半径会小很多，第二天不用写一堆“为什么上线后才发现”的复盘。研发不用被动拉进群里救火，更能把精力放在迭代上。

运营：研发要参与稳定性，不是为了背锅，而是为了让交付更可持续今天的工程实践早就不再是“写完交付就走”。运营阶段的稳定性数据、性能趋势、错误分布，都是下一轮设计与构建的输入。研发如果完全不看运营数据，你的迭代会越来越像蒙眼开车。相反，研发适度参与运营指标和可观测性设计，后面会越来越省力。

交付：交付的不是版本，是价值被使用研发经常被吐槽“发了也没用”，很多时候不是功能没价值，而是用户不知道怎么用、变更影响没解释清、支持没准备好。交付阶段强调的是价值兑现：你做的改动如何被用户感知，如何被验证产生效果。研发越早参与这件事，越能减少“做了却没人用”的浪费。

支持：支持回流是研发效率的加速器，不是负担研发最痛的循环是什么？同样的线上问题反复出现。支持如果只负责关单，不把高频问题回流到设计与构建，你就会一直修同一种Bug。支持回流跑起来，研发才有机会把重复性问题从根上消掉，长期效率会提升。支持回流不是让研发更忙，而是让研发把忙用在更有价值的地方。



四、体验这条线跟研发有什么关系：体验差，最后返工最多的就是研发


很多研发觉得体验是产品或客服的事。现实是，体验一旦崩，返工往往会落到研发：改交互、加提示、补异常处理、加兜底、加灰度、加可回滚。你不在设计与转换阶段把体验与可解释性准备好，后面就会用返工来补体验。

ITIL 第5版把体验放在更核心的位置，研发应该把它理解成：减少返工的前置投入。体验不是让你做UI美化，而是让你把异常路径、沟通与支持准备、回滚与恢复这些“工程体验”做扎实。用户舒服了，研发才舒服。


五、AI与自动化怎么帮助研发：先把底座做干净，再谈更深的自动化


ITIL 第5版谈AI原生与治理，研发团队最该抓住的其实是两点：
第一，AI能帮你把信息整理与一致性做起来，比如变更说明、知识条目、告警归并、问题聚类，这些能减少重复劳动。
第二，AI越靠近决策，治理越要跟上。尤其在转换和运营阶段，AI可以辅助风险识别、异常检测、沟通生成，但上线许可、回滚决策、重大处置必须有人负责，责任链条要清晰。

更稳的推进路径是：先把知识与数据口径整理干净，让AI在整理、计算、沟通上先发挥价值；等底座稳定，再逐步引入更深的认知与协调能力。否则你会得到一个“更快的混乱”，对研发来说就是更快地背锅。

ITIL 第5版并不是来拖慢研发的，它真正想做的是用全生命周期把交付链路拧成一股绳，把转换和支持回流这两个最耗人的断点补上——断点补上了，研发才有可能从救火里解放出来，把时间用在真正的迭代和创新上。



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

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

很多研发同学对ITIL天然有点抵触，我理解。过去不少组织把ITIL落地成了“流程很多、审批很重、发版很慢”，研发被卡得喘不过气。于是大家形成了一个条件反射：听到ITIL就想到“拖慢交付”。

但我想说的是，如果你把ITIL 第5版认真看一遍，会发现它这次的主线并不是“加流程”，而是“把链路打通”。它不靠多填字段来提升质量，而是靠全生命周期的对齐、治理边界的清晰、以及体验与支持回流的机制，去减少你们最讨厌的东西：返工、救火、被动加班、以及莫名其妙的锅。

我写这篇文章，就是想用研发的语言把这件事讲清楚：ITIL 第5版对研发到底有什么用，它会不会把你拖慢，哪些点能帮你更快更稳。


一、ITIL第5版不是给运维看的，是给整个交付链路看的


ITIL 第5版相对ITIL 4的核心升级，可以用几句话说清楚：

• 管理对象从以服务为中心，进一步扩展到数字产品与数字服务一起管
• 工作方式从价值链进一步落到全生命周期，用八个阶段活动把端到端拆得更具体
• 体验被更明确地纳入价值交付，强调可感知的结果，不只是内部达标
• 价值系统里的治理更强调可操作性与可选型，强调责任、监督与纠偏
• AI与自动化被纳入体系，强调能力分层与治理边界，避免“黑箱提效”带来风险
  

八个阶段活动是：发现、设计、获取、构建、转换、运营、交付、支持。你把它翻译成研发人话，就是：
需求对齐、方案设计、资源准备、实现与验证、上线准备与风险控制、稳定运行、持续交付价值、支持反馈回流。

这条链路里，研发最容易被坑的地方，恰恰在“转换”和“支持回流”上：上线前准备不足导致夜战；支持回流缺失导致同样的坑反复踩。

二、研发为什么会觉得“流程拖慢我”：因为很多组织只做了控制，没做能力提升


这里我得讲得直一点：流程让人讨厌，通常不是因为“有规则”，而是因为规则只做了控制，没有帮你把能力提升。审批流最典型：它能告诉你“你可不可以发”，但它不帮你解决“你发了会不会炸”。结果就是发版前大家忙着过审批，真正该准备的监控、演练、回滚、支持口径反而没做扎实。最后上线一炸，所有人都输。

ITIL 第5版把“转换”提出来，本质是在纠正这个偏差：控制当然要有，但更重要的是能力提升。能力提升做到了，控制可以变轻；能力提升做不到，控制越重越慢还越不安全。


三、把八个阶段活动对齐到研发链路：你会发现它更像“端到端工程实践”的框架


我们把八个阶段活动逐段对齐到研发工作，你就明白它到底在解决什么问题。

发现：别让研发替业务做决策，也别让研发背“需求没讲清”的锅研发最怕的是什么？需求不清、优先级乱、范围边界不明。发现阶段的意义，就是把价值、边界、风险讲清楚：到底解决谁的问题，为什么现在做，做到什么程度算成功，不做会有什么风险。你把这些讲清楚，研发评估才会更准，后面返工才会少。

设计：设计不是画架构图，而是把可验证、可运维、可支持写进去很多设计评审只盯架构正确性，忽略了上线后怎么跑：监控点位、日志策略、限流降级、容量评估、回滚方案、常见问题应对。这些如果不在设计阶段想清楚，你就等着上线后补洞。补洞不是不行，但补洞永远最贵，而且会把研发拉回“救火模式”。

获取：资源与依赖提前对齐，别等到上线前一周才发现缺权限、缺环境、缺供应商配合研发交付经常被“外部依赖”拖死：数据接口、权限审批、第三方组件、云资源配额、供应商响应。获取阶段做得好，研发的节奏会更稳定；做不好，研发就会在各种临时协调里被掏空。

构建：把“可验证、可回滚、可度量”当成交付的一部分构建不只是把功能做完，还要把它做成可以验证、可以回滚、可以观察的交付。测试通过不等于上线可控。你要能回答：上线后怎么看健康度？关键指标是什么？出事怎么回滚？这些不是运维的事，是工程交付质量的一部分。

转换：研发最该关心的不是“审批通过”，而是“上线准备是否完整”这是ITIL 第5版对研发帮助最大的地方之一。转换阶段要做的事很具体：发布演练、变更影响评估、监控告警接入、配置核验、支持知识与话术准备、公告与沟通节奏、应急预案与责任人到位。如果转换做得扎实，研发的收益是什么？上线夜战会少很多，事故爆炸半径会小很多，第二天不用写一堆“为什么上线后才发现”的复盘。研发不用被动拉进群里救火，更能把精力放在迭代上。

运营：研发要参与稳定性，不是为了背锅，而是为了让交付更可持续今天的工程实践早就不再是“写完交付就走”。运营阶段的稳定性数据、性能趋势、错误分布，都是下一轮设计与构建的输入。研发如果完全不看运营数据，你的迭代会越来越像蒙眼开车。相反，研发适度参与运营指标和可观测性设计，后面会越来越省力。

交付：交付的不是版本，是价值被使用研发经常被吐槽“发了也没用”，很多时候不是功能没价值，而是用户不知道怎么用、变更影响没解释清、支持没准备好。交付阶段强调的是价值兑现：你做的改动如何被用户感知，如何被验证产生效果。研发越早参与这件事，越能减少“做了却没人用”的浪费。

支持：支持回流是研发效率的加速器，不是负担研发最痛的循环是什么？同样的线上问题反复出现。支持如果只负责关单，不把高频问题回流到设计与构建，你就会一直修同一种Bug。支持回流跑起来，研发才有机会把重复性问题从根上消掉，长期效率会提升。支持回流不是让研发更忙，而是让研发把忙用在更有价值的地方。



四、体验这条线跟研发有什么关系：体验差，最后返工最多的就是研发


很多研发觉得体验是产品或客服的事。现实是，体验一旦崩，返工往往会落到研发：改交互、加提示、补异常处理、加兜底、加灰度、加可回滚。你不在设计与转换阶段把体验与可解释性准备好，后面就会用返工来补体验。

ITIL 第5版把体验放在更核心的位置，研发应该把它理解成：减少返工的前置投入。体验不是让你做UI美化，而是让你把异常路径、沟通与支持准备、回滚与恢复这些“工程体验”做扎实。用户舒服了，研发才舒服。


五、AI与自动化怎么帮助研发：先把底座做干净，再谈更深的自动化


ITIL 第5版谈AI原生与治理，研发团队最该抓住的其实是两点：
第一，AI能帮你把信息整理与一致性做起来，比如变更说明、知识条目、告警归并、问题聚类，这些能减少重复劳动。
第二，AI越靠近决策，治理越要跟上。尤其在转换和运营阶段，AI可以辅助风险识别、异常检测、沟通生成，但上线许可、回滚决策、重大处置必须有人负责，责任链条要清晰。

更稳的推进路径是：先把知识与数据口径整理干净，让AI在整理、计算、沟通上先发挥价值；等底座稳定，再逐步引入更深的认知与协调能力。否则你会得到一个“更快的混乱”，对研发来说就是更快地背锅。

ITIL 第5版并不是来拖慢研发的，它真正想做的是用全生命周期把交付链路拧成一股绳，把转换和支持回流这两个最耗人的断点补上——断点补上了，研发才有可能从救火里解放出来，把时间用在真正的迭代和创新上。



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

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