睿见安言 第五版的ITIL是不是真的越来越像DevOps？

1、ITIL第五版的he心演进

初读ITIL第五版的时候，我有一个很明显的感受：它的“产品和服务生命周期模型”，看起来和DevOps的八字环有点像。

DevOps的八字环，很多人都熟悉：计划、编码、构建、测试、发布、部署、运营、监测。

ITIL第五版的产品和服务生命周期模型，则是：发现、设计、获取、构建、转换、运营、交付、支持。

如果只是把两个模型并排摆在一起，确实很容易产生一种直觉：这是不是ITIL版的DevOps八字环？忽然觉得这个问题值得认真讲一讲，因为它背后反映的不是一个图形相似的问题，而是ITIL从4到第五版的一次重要变化。

过去我们谈ITIL4，顶顶he心的模型是服务价值系统、服务价值链、四维模型、指导原则和管理实践。ITIL4已经不再是传统意义上的流程手册，它开始强调价值、协作、反馈、敏捷和端到端思维。

但到了ITIL第五版，它又往前走了一步。第五版把关注点进一步扩展到“数字化产品和服务管理”。也就是说，它不再只是讨论服务如何被管理，也不只是讨论IT部门如何支撑业务，而是开始正面回答一个更现实的问题：

在today的数字化组织里，一个产品和服务，如何从想法、设计、资源准备、构建、上线、运营、交付、支持，一直持续创造价值？这就是产品和服务生命周期模型出现的背景。

这也解释了为什么它会让人联想到DevOps。因为DevOps本身就是对传统割裂式IT管理的一种反应。过去开发管开发，运维管运维，测试管测试，发布管发布，每个团队都在自己的专业领域里努力，但finally价值并不一定顺畅流向用户。DevOps想解决的，就是这条从需求到上线、从上线到反馈的端到端链路问题。

2、ITIL第五版与DevOps的本质区别

ITIL第五版需要面对上述现实。只是它站的位置和DevOps不完全一样。DevOps更关心的是工程交付闭环：如何让代码和变更更快、更可靠、更自动化地从计划走到生产环境，并通过运营和监测反馈持续改进。

ITIL第五版的生命周期模型，更关心的是产品和服务价值闭环：一个数字化产品和服务为什么要存在，如何被设计，如何获得资源，如何构建，如何转换到运营环境，如何稳定运行，如何交付给用户，如何在支持和反馈中持续改进。

所以两者确实相似，但相似的不是表面图形，而是它们都在回应同一个时代问题：

组织不能再用部门墙管理数字化价值。从这个角度看，ITIL第五版像DevOps，并不是坏事。

恰恰相反，这说明ITIL正在从传统服务管理框架，继续向数字化产品和服务的端到端管理框架演进。

但这也带来一个值得警惕的问题：如果我们只是看到“相似”，就很容易误解ITIL第五版的生命周期模型。它不是DevOps八字环的替代品，也不是DevOps的重新包装。

DevOps的八字环，重点在工程链路。它关心从计划、编码、构建、测试、发布、部署，到运营和监测的连续流动。它强调自动化、持续集成、持续交付、快速反馈、开发与运营协作。

而ITIL第五版的生命周期模型，重点在管理链路。它把数字化产品和服务放在一起看，强调发现、设计、获取、构建、转换、运营、交付、支持这些活动如何共同作用，如何被价值流组织起来，如何在不同运营模型下由不同团队或组织承担责任。

这就是两者的本质差别。

DevOps问的是：我们如何更快、更稳定地把变更交付到生产环境？

ITIL第五版问的是：我们如何端到端管理数字化产品和服务，让它持续为消费者和组织创造价值？

3、从实践场景了解差异

让我们从一些具体的实践场景找到两者之间的差异。

例如：一家企业要做一个新的移动客户端。DevOps会非常关心这件事如何进入工程交付链路：代码如何管理，构建如何自动化，测试如何前移，发布如何控制风险，部署如何自动化，监测如何反馈。

这些都非常重要，但ITIL第五版会进一步追问：

这个应用为什么要做？用户的问题是否被真实验证过？它对应的服务供给是什么？哪些能力需要内部构建，哪些能力需要外部获取？云服务、供应商、数据、人员是否准备好？上线后谁运营？谁交付服务？谁支持用户？发生事件时谁恢复？反馈如何回到产品发现和设计？

这些问题，不是DevOps不关心，而是DevOps不是专门为回答这些管理问题而设计的。

反过来，ITIL如果只讲生命周期、价值流、治理和服务关系，却不能落到工程交付、自动化、监测、反馈和协作实践上，也会变成一套漂亮但空泛的管理语言。

所以真正成熟的理解，不是把ITIL和DevOps对立起来，也不是把它们混成一回事，而是看清它们各自负责的层次。

DevOps给ITIL带来了速度、反馈和工程现实。

ITIL给DevOps补上了服务关系、价值共创、责任边界、治理结构和持续服务管理。

一个偏工程交付，一个偏服务价值。

一个让组织跑得更快，一个提醒组织不要只顾着跑。

一个强调从代码到生产，一个强调从产品和服务到价值。

这也是为什么ITIL第五版要引入产品和服务生命周期模型。

4、第五版的ITIL与DevOps如何互补

让我们回到主题，在ITIL4里的服务价值链已经强调价值创造，但它的表达仍然更像一个服务管理框架中的活动系统。第五版的生命周期模型，则让“数字化产品”和“数字化服务”的关系变得更加清楚：产品不是孤立存在的技术资产，服务也不是上线之后才出现的运维对象。它们从发现开始就彼此交织，finally通过服务关系和消费过程实现价值。

这也是today很多企业真正遇到的问题。

很多企业做数字化转型，不缺项目，不缺系统，不缺工具，也不缺开发能力。真正缺的是端到端的价值管理能力。

• 一个功能上线了，但用户不爱用。

• 一个系统建成了，但服务体验没有改善。

• 一个平台采购了，但供应商责任不清。

• 一个应用运行了，但事件、支持、反馈没有进入产品改进闭环。

这些问题单靠DevOps解决不了，单靠传统ITIL也解决不了。它们需要的是一种更完整的管理视角：既要看工程效率，也要看产品价值；既要看服务稳定，也要看用户体验；既要看内部团队，也要看供应商和合作伙伴；既要看流程是否规范，也要看价值是否真正流动。

这正是ITIL第五版想表达的方向。

所以，当我们说ITIL第五版的生命周期模型像DevOps八字环时，不能停留在“像不像”的层面。真正值得关注的是，它说明当下数字化产品的管理正在从几个方向汇合：

• 从流程管理走向价值流管理。

• 从服务运营走向产品和服务全生命周期管理。

• 从部门分工走向端到端责任。

• 从技术交付走向持续价值。

• 从人工操作走向自动化和AI使能。

• 从单一框架走向多种方法的整合。

这才是ITIL第五版真正的变化。

当然，这种变化也有风险。当一个框架试图整合太多现代管理思想时，很容易变得概念密集、术语繁多、边界模糊。读者可能会觉得：这不是DevOps讲过的吗？这不是产品管理讲过的吗？这不是敏捷讲过的吗？

作为ITIL的实践者和推动者，我个人认为这种质疑是合理的。但如果换一个角度看，ITIL的价值并不在于发明每一个概念，而在于把这些概念放进一个统一的数字化产品和服务管理框架中，让不同角色之间有一套共同语言。

产品团队、开发团队、运维团队、服务团队、安全团队、供应商、管理层，过去各说各话。ITIL第五版想做的，是让这些人能围绕同一个生命周期、同一个价值流、同一组责任和同一个价值目标展开协作。

其实现实中这件事很难，但又非常的有必要。所以，我对ITIL第五版生命周期模型的判断是：它看起来像DevOps，这是正常的感受。而且它必须像DevOps，因为today的数字化产品的管理不可能脱离持续交付、自动化、反馈和工程协作。

但它不能只是DevOps，因为数字化产品和服务管理还需要战略、价值、服务关系、供应商治理、运营模型、用户体验和持续支持。

如果说DevOps八字环解决的是“如何让变更持续、安全、快速地流向生产”，那么ITIL第五版生命周期模型解决的是“如何让数字化产品和服务持续、稳定、可治理地创造价值”。

这两个模型的关系，不是替代关系，而是互补关系。

DevOps是工程闭环。ITIL第五版生命周期模型是产品和服务价值闭环。

真正you秀的组织，不会在二者之间选边站。它会用DevOps提升交付和反馈能力，用ITIL建立服务价值和管理体系，用价值流把不同团队、工具、供应商和用户体验连接起来。

因为today的数字化管理，已经不是“有没有流程”的问题，也不是“上线快不快”的问题，而是组织是否具备一种能力：

能够持续发现价值、设计价值、构建价值、交付价值、运营价值，并在反馈中不断修正价值。

这才是ITIL第五版生命周期模型真正想告诉我们的事情。

数字安全 关注安言