很多组织一遇到性能波动，第一反应就是加资源：
加实例、加节点、扩容数据库、提高配额。短期看确实有效，问题像是被压住了，可过一段时间又会反复出现：高峰期还是卡、关键流程还是慢、发布后还是抖、用户体验还是投诉。更糟的是，成本一路上升，团队却越来越焦虑，因为心里清楚：这不是一台机器的问题，是系统性瓶颈。


数字产品与数字服务时代，容量和性能管理实践如果还停在“资源够不够”，就会越来越吃力。真正决定体验的，是端到端吞吐量、关键路径瓶颈、交付节奏下的波动、依赖链路的连锁反应。ITIL 第5版把全生命周期、体验、治理、可审计性放到更核心的位置，就是在提醒：容量和性能管理不只是运维算账，它要服务价值流的顺畅交付，服务体验的稳定兑现。


一、为什么第5版会让容量管理更像“价值流管理”

ITIL 第5版相对 ITIL 4 的核心升级要点包括：

• 管理对象从服务扩展到数字产品与数字服务
• 八个阶段活动贯穿全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
• 体验被写入价值定义，稳定与可预测本身就是体验
• 治理强调授权、问责与可审计性
• 自动化与人工智能纳入体系，变化更快、依赖更深
  

当交付更快、变化更频繁，容量问题不再是“偶尔发生”，而更像“持续伴随”。更重要的是，容量与性能波动会直接影响体验与信任。一旦用户在关键旅程里卡住，哪怕系统没有完全中断，也足以造成真实的业务损失。第5版把体验放到价值定义里，就是在逼团队把容量管理做成稳定能力。


二、容量不只是算资源：真正要管的是吞吐量、瓶颈与波动

传统容量管理容易把注意力放在资源利用率上：CPU、内存、磁盘、连接数。指标当然重要，但它们更多是“症状”，不是“原因”。真正决定体验的是三件事：
吞吐量
系统在单位时间里能处理多少业务请求，是否能支撑峰值。
瓶颈
端到端链路里最慢的那一段是谁，是数据库锁、队列积压、外部依赖、还是某个同步调用。
波动
性能是不是稳定，是否会在发布后、峰值时、某类请求出现时突然变差。


如果只盯资源利用率，很容易把问题误判为“资源不足”，于是用扩容掩盖瓶颈，成本上去，问题还在。


三、把容量管理拉回价值流：卡在哪里，就改哪里

ITIL 第5版强调价值流与全生命周期，对容量管理最大的启发是：不要从资源出发，而要从关键旅程和关键路径出发。
更务实的做法是：

• 先识别关键旅程：哪些接触点最影响业务结果
• 再识别关键路径：这条旅程依赖哪些组件、哪些外部能力
• 找到瓶颈：在哪一步出现积压、超时或锁等待
• 定义验收标准：上线前必须达到什么吞吐量与响应稳定性
• 持续验证：发布后是否稳定，是否存在回退方案
  

这样容量管理就从“算资源”变成“保交付”，对组织的价值会大很多。


四、把容量和性能前置到设计：别等到上线后才发现“撑不住”

很多性能问题是设计阶段埋下的：同步调用太多、缓存策略不清、数据模型不适配、依赖链路过长、缺乏降级。上线后再补救，往往只能扩容，修架构已经来不及。


设计阶段必须把几个关键问题问清楚：

• 峰值场景是什么，波峰在哪里
• 哪些环节必须同步，哪些可以异步
• 哪些依赖一旦变慢会拖垮整条链路
• 降级与绕行方案是什么
• 可观测性如何设计，后续如何定位瓶颈
  

容量管理前置后，发布会更稳，夜战会少很多。


五、转换阶段是性能“可运营”的门槛

性能和容量不是上线后一周再观察的事情，而应该在转换阶段就完成关键验证。否则上线后发现撑不住，只能在生产环境里边跑边修，风险和影响都会被放大。

转换阶段的关键检查至少包括：

• 基准测试是否覆盖关键旅程
• 峰值与突发场景是否验证过
• 告警阈值是否合理，能否及时发现积压
• 降级与回滚是否演练过
• 支持团队是否知道“性能异常”的判断与处理路径
  

把这些作为就绪度检查的一部分，容量管理才会真正进入治理体系。


六、需求预测与资源池管理：别让容量规划靠拍脑袋

容量规划如果靠“感觉”，一定会失真。更成熟的方式是用需求预测结合资源池管理：

• 看历史趋势：高峰是什么时候出现的
• 看业务节奏：活动、促销、结算、月底关账是否会拉峰值
• 看发布节奏：发布后是否会引入新的负载模式
• 看外部依赖：供应商侧是否存在维护窗口或限流策略
  

资源池管理的意义是让资源调度更灵活：关键时刻有资源可用，平时不过度浪费。规划的目标不是永远足够，而是能提前知道什么时候会紧张，并提前做选择。


七、度量指标要能指导行动：别只盯利用率

容量和性能管理要选能指导行动的指标，尤其要覆盖端到端体验：

• 关键旅程的响应稳定性与波动
• 吞吐量与队列积压趋势
• 错误率与超时率
• 外部依赖的延迟与失败趋势
• 发布后性能回归是否发生
  

指标不是为了展示仪表盘，而是为了触发决策：扩容、优化、降级、限流、调整发布节奏，或者推动架构改造。


八、变更实施与发布节奏：性能波动往往是“变化引起的”

性能问题很多时候不是自然发生的，而是被变化引起的：

• 新版本引入更重的查询
• 配置调整导致缓存失效
• 外部依赖升级引入新的延迟
• 数据量增长触发临界点
  

因此容量和性能管理必须和变更实施、发布管理联动：

• 高风险变更要有更强的性能验收标准
• 发布窗口要考虑容量风险，避免在高峰期做高风险动作
• 性能回归必须可追溯，能定位到具体变更
• 必要时要有回退与纠偏机制
  

把性能风险纳入变更治理，组织就会稳得多。

九、自动化与人工智能：帮忙看见趋势，但不能替代取舍

自动化和人工智能可以在容量管理里发挥很大作用：

• 自动采集与关联关键指标，形成端到端视图
• 识别异常模式与瓶颈信号，提前预警
• 辅助预测峰值与资源紧张窗口
• 自动化扩缩容，但必须有边界与保护策略
  

但最终的取舍仍需要治理：哪些业务优先、哪些功能降级、哪些发布延期、哪些架构必须改造。这些选择不能靠算法替代问责。


最后，我给出我的建议：选一条最关键旅程，把容量管理做成“可验证能力”，最有效的改造路径通常是：

• 选一条业务关键旅程，画出端到端依赖
• 建立性能基线与验收标准
• 在转换阶段固化性能就绪度检查
• 把发布后回归监控做成固定动作
• 用持续改进把瓶颈优化变成可验证的改进举措
  

当一条旅程跑顺，团队会清楚看到：容量管理不是“加机器”，而是“让价值流更顺畅”。这种认知一旦建立，后续推广会轻很多。


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

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

很多组织一遇到性能波动，第一反应就是加资源：
加实例、加节点、扩容数据库、提高配额。短期看确实有效，问题像是被压住了，可过一段时间又会反复出现：高峰期还是卡、关键流程还是慢、发布后还是抖、用户体验还是投诉。更糟的是，成本一路上升，团队却越来越焦虑，因为心里清楚：这不是一台机器的问题，是系统性瓶颈。


数字产品与数字服务时代，容量和性能管理实践如果还停在“资源够不够”，就会越来越吃力。真正决定体验的，是端到端吞吐量、关键路径瓶颈、交付节奏下的波动、依赖链路的连锁反应。ITIL 第5版把全生命周期、体验、治理、可审计性放到更核心的位置，就是在提醒：容量和性能管理不只是运维算账，它要服务价值流的顺畅交付，服务体验的稳定兑现。


一、为什么第5版会让容量管理更像“价值流管理”

ITIL 第5版相对 ITIL 4 的核心升级要点包括：

• 管理对象从服务扩展到数字产品与数字服务
• 八个阶段活动贯穿全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
• 体验被写入价值定义，稳定与可预测本身就是体验
• 治理强调授权、问责与可审计性
• 自动化与人工智能纳入体系，变化更快、依赖更深
  

当交付更快、变化更频繁，容量问题不再是“偶尔发生”，而更像“持续伴随”。更重要的是，容量与性能波动会直接影响体验与信任。一旦用户在关键旅程里卡住，哪怕系统没有完全中断，也足以造成真实的业务损失。第5版把体验放到价值定义里，就是在逼团队把容量管理做成稳定能力。


二、容量不只是算资源：真正要管的是吞吐量、瓶颈与波动

传统容量管理容易把注意力放在资源利用率上：CPU、内存、磁盘、连接数。指标当然重要，但它们更多是“症状”，不是“原因”。真正决定体验的是三件事：
吞吐量
系统在单位时间里能处理多少业务请求，是否能支撑峰值。
瓶颈
端到端链路里最慢的那一段是谁，是数据库锁、队列积压、外部依赖、还是某个同步调用。
波动
性能是不是稳定，是否会在发布后、峰值时、某类请求出现时突然变差。


如果只盯资源利用率，很容易把问题误判为“资源不足”，于是用扩容掩盖瓶颈，成本上去，问题还在。


三、把容量管理拉回价值流：卡在哪里，就改哪里

ITIL 第5版强调价值流与全生命周期，对容量管理最大的启发是：不要从资源出发，而要从关键旅程和关键路径出发。
更务实的做法是：

• 先识别关键旅程：哪些接触点最影响业务结果
• 再识别关键路径：这条旅程依赖哪些组件、哪些外部能力
• 找到瓶颈：在哪一步出现积压、超时或锁等待
• 定义验收标准：上线前必须达到什么吞吐量与响应稳定性
• 持续验证：发布后是否稳定，是否存在回退方案
  

这样容量管理就从“算资源”变成“保交付”，对组织的价值会大很多。


四、把容量和性能前置到设计：别等到上线后才发现“撑不住”

很多性能问题是设计阶段埋下的：同步调用太多、缓存策略不清、数据模型不适配、依赖链路过长、缺乏降级。上线后再补救，往往只能扩容，修架构已经来不及。


设计阶段必须把几个关键问题问清楚：

• 峰值场景是什么，波峰在哪里
• 哪些环节必须同步，哪些可以异步
• 哪些依赖一旦变慢会拖垮整条链路
• 降级与绕行方案是什么
• 可观测性如何设计，后续如何定位瓶颈
  

容量管理前置后，发布会更稳，夜战会少很多。


五、转换阶段是性能“可运营”的门槛

性能和容量不是上线后一周再观察的事情，而应该在转换阶段就完成关键验证。否则上线后发现撑不住，只能在生产环境里边跑边修，风险和影响都会被放大。

转换阶段的关键检查至少包括：

• 基准测试是否覆盖关键旅程
• 峰值与突发场景是否验证过
• 告警阈值是否合理，能否及时发现积压
• 降级与回滚是否演练过
• 支持团队是否知道“性能异常”的判断与处理路径
  

把这些作为就绪度检查的一部分，容量管理才会真正进入治理体系。


六、需求预测与资源池管理：别让容量规划靠拍脑袋

容量规划如果靠“感觉”，一定会失真。更成熟的方式是用需求预测结合资源池管理：

• 看历史趋势：高峰是什么时候出现的
• 看业务节奏：活动、促销、结算、月底关账是否会拉峰值
• 看发布节奏：发布后是否会引入新的负载模式
• 看外部依赖：供应商侧是否存在维护窗口或限流策略
  

资源池管理的意义是让资源调度更灵活：关键时刻有资源可用，平时不过度浪费。规划的目标不是永远足够，而是能提前知道什么时候会紧张，并提前做选择。


七、度量指标要能指导行动：别只盯利用率

容量和性能管理要选能指导行动的指标，尤其要覆盖端到端体验：

• 关键旅程的响应稳定性与波动
• 吞吐量与队列积压趋势
• 错误率与超时率
• 外部依赖的延迟与失败趋势
• 发布后性能回归是否发生
  

指标不是为了展示仪表盘，而是为了触发决策：扩容、优化、降级、限流、调整发布节奏，或者推动架构改造。


八、变更实施与发布节奏：性能波动往往是“变化引起的”

性能问题很多时候不是自然发生的，而是被变化引起的：

• 新版本引入更重的查询
• 配置调整导致缓存失效
• 外部依赖升级引入新的延迟
• 数据量增长触发临界点
  

因此容量和性能管理必须和变更实施、发布管理联动：

• 高风险变更要有更强的性能验收标准
• 发布窗口要考虑容量风险，避免在高峰期做高风险动作
• 性能回归必须可追溯，能定位到具体变更
• 必要时要有回退与纠偏机制
  

把性能风险纳入变更治理，组织就会稳得多。

九、自动化与人工智能：帮忙看见趋势，但不能替代取舍

自动化和人工智能可以在容量管理里发挥很大作用：

• 自动采集与关联关键指标，形成端到端视图
• 识别异常模式与瓶颈信号，提前预警
• 辅助预测峰值与资源紧张窗口
• 自动化扩缩容，但必须有边界与保护策略
  

但最终的取舍仍需要治理：哪些业务优先、哪些功能降级、哪些发布延期、哪些架构必须改造。这些选择不能靠算法替代问责。


最后，我给出我的建议：选一条最关键旅程，把容量管理做成“可验证能力”，最有效的改造路径通常是：

• 选一条业务关键旅程，画出端到端依赖
• 建立性能基线与验收标准
• 在转换阶段固化性能就绪度检查
• 把发布后回归监控做成固定动作
• 用持续改进把瓶颈优化变成可验证的改进举措
  

当一条旅程跑顺，团队会清楚看到：容量管理不是“加机器”，而是“让价值流更顺畅”。这种认知一旦建立，后续推广会轻很多。


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

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