ITIL 4中的“产品”是什么？从服务价值系统看懂产品化运维逻辑

一搜“ITIL第5版”，搜出来的结果十有八九都在讲ITIL 4。而ITIL 4里最让人琢磨不透的新概念之一，就是“产品”。很多运维老手第一次看到“产品”这个词，第一反应是：我们IT部门又不造东西，哪来的产品？这不是产品经理该操心的事吗？我最初也这么想，但后来把ITIL 4的服务价值系统（SVS）和四维模型读进去以后，才发现“产品”这个名词背后，其实是一整套管理逻辑的切换。它不再让你只盯着“流程有没有走通”“工单有没有闭环”，而是逼着你回答一个更本质的问题：你手上到底沉淀了哪些可以反复使用、能支撑多个服务的能力资产？这篇内容适合IT运维、服务管理、DevOps和ITIL落地实践者，我会从“产品”这个概念切入，把这套逻辑拆开讲清楚。

1. 先搞清楚：市面上流传的“ITIL第5版”到底是什么

1.1 版本谱系与“第5版”称呼的来龙去脉

严格来说，ITIL到目前为止并没有官方定义的“第5版”。大家熟知的版本脉络大概是这样的：ITIL v2以“服务支持”和“服务交付”两大块为核心，ITIL v3在2007年发布、2011年修订，提出了服务生命周期模型，分成服务战略、服务设计、服务转换、服务运营、持续服务改进五个阶段，配套26个流程，这也是国内大多数IT部门落地ITIL时的主要参照系。到了2019年，ITIL 4正式发布，它做了几个比较大的动作：不再强调生命周期，而是引入四维模型（组织和人员、信息与技术、合作伙伴与供应商、价值流与流程），用服务价值系统把Guiding Principles、治理、服务价值链、实践、持续改进串起来，并且把原来的“流程”改叫“实践”。

那“第5版”这个说法从哪来的？我个人的判断有两层原因。第一层，是信息传播的简化现象。很多培训机构和文章习惯把v3叫“第三版”，把ITIL 4叫“第四版”，但如果把ITIL 4也看成一次大版本代际更替，有些人顺口就叫成了“第五版”。这个说法其实是把“4”当成“第四代框架”，再把后续的小版本调整或者官方发布路线图里的某些更新当成了“第5版”的依据。第二层，是大家真的在等一个“更新更适应云原生和DevOps的版本”，于是网络上会出现一些推测性内容，把ITIL 4的后续演进叫成“第5版”。

对我们实际做管理的人来说，版本号不是重点。重点是ITIL 4这个代际变化里，有一个词被反复提到，但很多文章一句话就带过了，这个词就是“产品”。

1.2 “产品”概念在ITIL 4中的位置

在ITIL 4的官方词汇表里，“产品”被定义为一个组织所拥有的资源的一种配置，这种配置是为了向消费者提供价值。听起来很绕，我换句话解释：产品就是你把人员、技术、流程、伙伴关系等资源，按某种方式打包成一个可以被重复使用、可被多个服务引用的“能力单元”。

为什么要在这个版本里突然把“产品”提出来？因为ITIL 4的底层逻辑已经从“管理流程”转向“创造价值”。流程是从“做事”的角度看问题，产品是从“资产复用”的角度看问题。以前我们说“设计一个服务”，脑子里想的是这个服务怎么响应请求、怎么收费、怎么交付；现在ITIL 4要求你先想清楚：这个服务依赖哪些产品？这些产品是只服务这一个客户，还是可以组合出更多服务？如果产品能被多个服务复用，你的交付效率和一致性都会明显提升。

所以说，“产品”在ITIL 4里不是传统意义上“卖出去的实物商品”，也不是软件产品经理口中的“App或平台”，而是一个服务管理视角下的资源配置单元。它处在“资源”和“服务”之间：底层是各种资源，上层是客户能感知到的服务，而产品就是把这些资源编排成的中间层。

2. 产品与服务：差一个字，管理逻辑变了什么

2.1 产品是“可复用的服务底座”

我先用一个类比来帮大家建立感觉。你去餐厅吃饭，你点的“宫保鸡丁”是一道菜，但后厨里其实有备好的“鸡丁半成品”“调好的宫保汁”，这些就是产品。同一份宫保汁，既能做宫保鸡丁，也能做宫保虾球。客户只关心菜好不好吃，但后厨管理关心的是半成品够不够、调料的配方稳不稳定、能不能一批次准备出来给多个菜共用。

IT服务也一样。业务部门要的是一个服务，比如“身份认证服务”“应用发布服务”“监控告警服务”。你去看这个服务背后，支撑它的往往不是一堆乱糟糟的脚本和工具，而是可以抽象出来的“产品”：身份管理产品可能包括统一目录、权限模型、API网关、认证策略；应用发布产品可能包括代码仓库、制品库、流水线、部署脚本。这些产品被定义清楚以后，它们就可以被多个服务复用。客户看的永远是服务，但IT部门自己要清楚：我们维护的不是一个个孤立的服务，而是一组可以组合的产品。

2.2 从“流程走通”到“资产沉淀”

ITIL v3时代，我们考核一个运维团队，看的指标往往是事件响应时长、变更成功率、问题解决率。这些指标背后有一套流程：事件管理流程、问题管理流程、变更管理流程。流程有没有打通，成了很多ITIL落地方案的核心。这没有错，但它有一个隐含问题：流程走通，不不等于能力沉淀。张三会配置这个系统，如果张三休假了，其他人接手就要重新看文档、猜配置；这个系统接了一个新需求，另一套系统要用同样能力的时候，又要再重新搭一遍。

ITIL 4把“产品”放到显眼位置，本质上是逼着团队回答一个灵魂拷问：你今天做过的这件事，能不能变成明天可以重复使用的东西？如果能，那它就应该被产品化；如果不能，那你要想想为什么每次都在“发明轮子”。我在实际项目里见过很多“流程规范，但成本极高”的团队，问题就出在他们把ITIL当成了流程合规工具，没有把关键能力沉淀为资产。而“产品”这个概念的引入，恰好是把管理焦点从“流程是否走通”拉回“资产是否沉淀”。

2.3 对服务设计流程的直接影响

以往设计一个新服务，我们通常先评审业务需求，再设计服务目录里的服务项，然后定义服务级别、收费模式、支持流程。ITIL 4引入了产品概念后，服务设计的起点变了：你不再是“从零画一个新服务”，而是先看产品目录里有什么产品可以组合，缺什么产品就补什么产品。这有点像中台思路：你搭了一个用户中心，后续所有需要用户能力的服务都不用再单独立项建系统，而是直接接入用户中心产品。产品和服务之间形成了一种映射关系，服务是客户端，产品是供给端。

这也带来一个很实际的变更管理影响。假如某个底层产品要升级，比如统一认证网关要切换协议，在ITIL v3逻辑下，你可能只把它当一个“变更请求”去审批，但有了产品概念以后，你的变更影响分析就必须同时列出“这个产品支撑了哪些服务”，任何产品级变更都要评估对这些服务的连带影响。反过来说，某条服务做的配置调整，反过来也会写回到产品配置项里。产品和服务的关联关系，变成变更管理、事件管理、可用性管理最基础的数据来源。这个变化，管理颗粒度更细了，但对很多传统运维团队来说，也是真正开始“数据驱动运维”的起点。

3. 产品化给运维团队带来的四个管理转向

3.1 从“项目思维”转向“产品思维”

很多IT团队做的事情都有项目属性：业务提需求，IT排期，上线，验收，解散。项目思维关心的是“这个事什么时候做完”，产品思维关心的是“这个能力怎么样能长期活下去并越用越顺”。我在帮一个金融客户梳理运维团队职责时发现，他们最累的不是开发，而是运维——每次上线一个新系统，运维就要从头开始写监控脚本、配告警规则、写应急预案；一个系统一个样，没有任何沉淀。后来我们换了个思路：不按“系统”来管理，而是按“产品能力”来管理，比如监控产品、日志产品、备份产品。每个新系统上线，不再是“单独配一套监控”，而是“接入公司统一的监控产品”，配置效率提升很明显，交付周期从以前的几个星期压缩到一到两天。

项目思维还有一个附属问题：团队跟着项目走，人员流动性大，知识沉淀差。产品思维则强制要求回答“这个产品的负责人是谁”“产品的长期演进路径是什么”“产品的下一版本应该优化什么”。这不是说项目不重要，而是说交付完项目以后，你要有一个持续运维和优化的对象，这个对象就是产品。

3.2 从“成本分配”转向“投资组合管理”

传统IT部门对自己花的钱，往往只能按科目记账：硬件采购、外包人力、软件授权。当要压缩预算时，大家只能在科目上做取舍，说不清楚哪个产品值钱、哪个产品在烧钱。产品化之后，每个产品都能单独核算成本：人员投入、工具费用、基础设施资源、合作伙伴成本，都可以分摊到产品上。这样就能像投资组合一样，对产品做分类：核心高value产品、需要优化产品、逐步淘汰产品。IT预算讨论就从“今年我们要买多少服务器”，变成“我们准备继续加大哪个产品的投入、缩减哪个产品的支出”。

我理解很多中小型运维团队会觉得做产品级成本核算太重了。确实，如果你们的IT部门就三五个人，没必要上一套完整的产品投资组合管理系统。但哪怕用一张Excel表格做产品清单，把大致的人工成本和工具成本摊进去，都会带来不一样的视角。你可能会突然发现，有些用了很多年的系统，维护成本和它实际创造的价值完全不成比例。

3.3 从“服务可用性”转向“产品健康度与复用率”

以前我们衡量IT运维效果，最常用的是服务可用性百分比。这个指标没毛病，但它反映的是结果，不是原因。一个业务系统今天没宕机，可能是因为运维团队天天救火，也可能是因为系统本身很稳。你很难从这个指标里知道“哪块底层能力最脆弱”。一旦引入产品视角，就有了产品健康度这个更前置的指标：产品的代码质量、版本老化程度、缺陷率、文档完善度、支持团队能力，都可以量化。产品健康度不是凭空设计出来的，它来自你对产品生命周期状态的评估：一个产品如果还是“引进期”，可能不稳定；如果长期没有版本更新、人员都不熟悉它，它就是“衰退期”，即便现在服务还能正常运行，你也该着手规划替换了。

复用率同样重要。一个产品如果只被一个服务引用，那它就还处于“半产品化”状态，和以前那种“专门为某系统定制开发的模块”区别不大。真正的产品化能力，体现在它能支撑几个服务、被几条价值流引用。我建议团队在建立产品目录时，顺手给每个产品记上“被哪些服务引用”这个字段，这就是最基础的产品复用率。

3.4 从“职能竖井”转向“跨职能价值流协同”

ITIL 4最明显的变化之一，是把“价值流”这个概念提到了核心位置。价值流是一个端到端的视角，比如“新员工入职”“用户自主注册”“业务系统上线”，这些价值流通常要穿过好几个职能团队。以前运维、网络、安全、开发各管一段，每个人只关心自己那一段有没有完成，结果整体效率很差。产品在其中扮演的角色，是价值流中的“标准化环节”：每条价值流由若干产品能力参与，产品之间通过接口衔接。你在价值流活动里看到的不再是“张三找网络组开端口”“李四找安全组审批”，而是“接入身份管理产品”“调用统一网关产品”。

我特别认同ITIL 4把“合作伙伴与供应商”作为四维模型之一，这背后其实也是产品化思维：外部供应商提供的产品，和内部自建的产品，都可以作为服务价值流中的一个组件。你不需要关心外包团队内部的流程，你只关心他们交付的产品能不能符合你定义的接口和SLA。这大幅降低了供应商管理的复杂度。

4. 实际落地：怎么把现有IT服务拆成产品来管

4.1 第一步：盘点服务，反向识别产品

你不需要一开始就设计一套理想的“产品架构”，更务实的方法是自下而上盘点。先把公司已有的服务清单拉出来，包括IT服务目录里登记的所有服务项，然后逐个服务问三个问题：这个服务依赖哪些核心系统或工具？这些系统和工具能不能被其他服务复用？如果可以，给它起一个稳定的产品名。举个例子，你们现在有“外部客户门户运维”服务，背后用到统一登录平台。那“统一登录平台”就是一个潜在产品，它可以同时支撑客户门户、内部OA、合作伙伴系统等多个服务。把这个识别过程做一遍，你会得到一张服务与产品的映射关系表。

我用一个简化表格来辅助说明：

这一步做下来，你会有两个很直接的收获。一是服务管理的复杂度下降了，因为你会发现很多服务背后其实是同一个产品；二是变更管理的评估范围清晰了，任何产品变更都能自动关联到它支撑的那些服务。

4.2 第二步：按生命周期管理产品

产品不是建成以后就一劳永逸，它也有引入期、成长期、成熟期和退出期。一个团队开始做产品化时，最容易犯的错是只关注“产品有没有跑起来”，不关心这个产品处在生命周期哪个阶段。

• 引入期产品：刚定义出来，还没有稳定的版本和标准化接口，适合小范围试运行。这个阶段要重点留痕，记录设计决策，避免人走茶凉。
• 成长期产品：被多个服务引用，接口趋于稳定。这个阶段要补文档、补监控、补自动化测试，确保它经得起更多服务接入的压力。
• 成熟期产品：功能稳定，使用范围明确。此时不要把资源全砸在新增功能上，而是关注稳定性和成本优化。
• 退出期产品：有新替代产品出现，或者业务需求已经变化。很多团队不敢做产品退市，原因就是历史服务关联不清。我建议每个季度做一次产品健康度检查，把进入退出期的产品明确列出来，有计划的替换总好过被故障逼着换。

这里有一个实操技巧：给产品定义“健康度评分”，不搞复杂，用5个维度打分即可——版本活跃度、文档完整度、缺陷积压数、引用服务数、维护团队人力是否稳定。每个季度打一次分，分数连续两个季度低于阈值的产品，就应该进入关注名单。

4.3 第三步：建立产品目录和价值流联动

产品目录不是开发团队内部的技术组件列表，它应该以业务语言描述“我能提供什么能力、服务等级是什么、谁来申请、怎么接入”。业务部门不需要知道这个产品底层用了什么技术，但要知道申请接入这个产品之后，我能得到什么：SLA是多少、变更窗口是什么时候、要付多少成本。把产品目录做出来以后，服务目录不用再单独跟底层技术绑定，服务目录直接引用产品目录的能力即可。

价值流则是另一条线：从客户视角把跨团队的活动串起来。拿“新员工入职”举例，这条价值流大概会经历以下环节：接收入职信息、创建账号、开通邮箱、分配系统权限、准备办公设备、完成入职培训。每一个环节如果都有标准产品支撑，整体效率会高很多。比如账号创建，依赖身份管理产品；邮箱开通，依赖邮件服务产品；权限分配，依赖权限治理产品；设备准备，依赖资产管理产品。价值流的价值在于，它让你看到产品之间的依赖关系和瓶颈点。如果入职审批环节因为某个产品处理慢，整体入职周期就会拉长，这时你再优化的时候，不是压着一个产品负责人去改，而是要把整条价值流各端的SLA对齐。

4.4 一个真实场景的复盘

我本人最深刻的一次产品化落地，是帮助一个中型电商团队改造“应用上线支持”服务。最开始他们的流程是：开发提上线申请，运维手工打包、改配置、执行脚本，整个流程大概要半天到一天；而且每个系统部署方式都不一样，运维同学整天被上线任务占满。我们做的第一件事，不是急着引入ITIL 4，而是先把“标准应用部署”抽成一个产品：定义统一的制品仓库、统一的发布流水线、统一的回滚方案。然后让三个新系统先接入试点，跑通后再推广到存量系统。

这个产品上线后的效果非常直接：新系统首次接入标准化部署，从原来的1到2天缩短到大约2小时；发布失败率从原来的15%左右降到3%以内；运维团队从“每个系统都要手工忙活”变成“只在流水线出现异常时才介入”。最关键的收获是，后来一个做数据分析的团队要上线一个新报表服务，直接复用了这套部署产品，几乎没额外增加运维负担。这就是“产品”的价值：它不是你多出来的一个流程，而是把一次性的交付能力沉淀成了可复用的资产。

5. 常见问题、踩坑与速查表

5.1 五个常见误区

第一个误区，是把所有配置项都叫产品。配置项是CMDB里记录的一个个对象，比如一台服务器、一个数据库实例；产品是这些配置项之上的能力封装。服务器不是产品，但“统一计算资源池”可以是一个产品。如果产品颗粒度划得太细，产品目录就退化成CMDB视图，反而会增加管理负担。

第二个误区，是把产品目录做成了纯技术组件清单。产品目录应该面向内部“客户”和管理者，说明能力、SLA、成本、接入方式。如果产品叫“Kafka集群”，业务部门看不懂，运维领导也觉得这东西离价值太远，那就起不到统一语言的作用。你可以内部保留技术组件的叫法，但在产品目录里给它一个业务化的能力名称，比如“实时消息通道服务”。

第三个误区，是让服务经理兼任产品负责人，但不给任何权限。产品负责人要能对产品的生命周期做决策，包括版本规划、标准制定、资源协调。如果只挂着“产品负责人”的头衔却什么都拍不了板，最后产品文档照样没人更新，产品接口照样混乱。这里给个建议：可以先从一个技术负责人主要精力去管理一两个核心产品开始，不要一开始就铺开很多产品负责人。

第四个误区，是忽略产品退役。做产品化建设时，团队很容易兴奋地不断定义新产品，但没人负责把老化、重复的产品清掉。结果产品目录越来越臃肿，引用关系越来越复杂。产品组合管理要像大扫除一样，定期清理“僵尸产品”，否则产品化最终会变成另一种形式的技术债。

第五个误区，是把产品做成一次性方案。产品不是项目交付物，交付完了还要持续演进。比如部署产品上线后，还要跟进它每年是否能跟上新的技术栈、是否覆盖新的场景、是否能支撑新的合规要求。没有一个一劳永逸的产品，只有持续维护的产品。

5.2 踩坑实录

我之前在一个客户那里见过这样的场景：他们很认真地按照ITIL 4建了产品目录，定义了两百多个“产品”，每个产品都指定了负责人，但推行半年后，大家基本上都不维护了，产品目录变成了摆设。事后复盘，问题出在“过度设计”：他们的产品都按技术组件划分，有数据库产品、Kafka产品、网关产品，但没有任何一个对应到业务价值上，管理层觉得这东西不能直接回答问题——那产品目录到底帮我们提升了什么？后来他们重新划分产品，先围绕几条核心价值流识别能力单元，把产品数量从两百多个压缩到不到三十个，再按季度做健康度评审，才算真正用起来。

另外一个真实教训是，产品整合时没有同步做好服务影响分析。我们曾经把两个能力相近的产品合并，结果因为梳理覆盖关系时漏掉了一个边缘服务，导致该服务在合并后无法正常调用底层能力，对业务造成了几十分钟的中断。从那次以后，任何产品变更，我们都会先导出“产品-服务”影响矩阵图，没有完成影响评估，不允许进入变更窗口。这个习惯也让我体会到，ITIL 4强调“产品-服务”关联关系、强调变更前的价值风险分析，不是纸上谈兵，是在真实事故中得出的经验。

5.3 问题速查表

从工具选型角度说，我不建议一上来就为了“产品化”去买一个重型ITSM平台。Excel或轻量配置管理数据库完全够起步，等产品数量到了几十个以上再考虑上专业平台。产品化的核心不是工具，而是团队愿不愿意用“资产复用”的视角去看待每天的工作。

最后再分享一个我个人的判断：ITIL 4里的“产品”概念，真正的价值不在定义本身，而是它迫使管理者和工程师换了一套思考方式。以前我们谈IT管理，答案往往是谁的体系做得全、谁的流程画得美；现在再看，真正拉开差距的，是你把多少能力沉淀成了可复用的产品、你用什么样的机制保证这些产品持续健康。这套逻辑不依赖你是不是叫它ITIL第5版，也不依赖你用的是不是最新框架——它是服务管理走向成熟度的必经之路。