应用系统容量管理是构建 IT 服务的重要过程，是 ITIL 框架和 ISO/IEC20000 标准中的标
准过程之一，应用系统容量体现了该应用系统的处理能力，特别是最大处理能力，对于系
统的正常运行、业务的产能规划保障、市场活动的冲击等都有着非常重要的意义，而随着
目前应用复杂度和系统架构复杂度的不断增加，对于容量的判断和管理是非常困难又非常
必要的，这是 ITSM 体系中对于系统可用性、可靠性和健壮性的集中体现，同时，容量管
理也决定了投入成本的最优化， 随着业务地快速增长、对客户体验的关注度上升、对系统
投入成本的管理等，都使得应用系统容量管理成为一个非常现实的需求和重要的管理目标。
应用系统容量管理作为打基础的项目， 需要优先完成以下目标：
1、 建立标准化的容量管理程序，从流程制度上规范各系统容量管理的目标和方法；
2、分批次对重要应用系统进行业务容量分析， 完成关键容量指标（KCI） 的制定；
3、结合业务产能规划，根据关键容量指标进行数据分析， 建立关键容量指标的监控
和预警体系，为下一步进行容量模型的分析建立基础。
一、 容量管理目标
根据项目目标进行分解，分为管理办法发布、关键容量指标库制定以及关键容量指标
监控三个子目标分别进行实现。
1、 管理流程和规范制定：《业务系统容量管理办法》
该办法需明确业务系统容量管理的范围、涉及容量管理的一系列管理过程和环节，明
确各参与方的工作内容和职责，制定容量管理程序，主要包括以下内容：
（1）关键容量指标的建立、修改、监控、关闭等过程，明确需求、设计、开发、投
产、运行等过程中关键容量指标的管理职责；
（2）业务产能规划中关键容量指标的应用过程，与业务产能管理相关办法相结合，
明确业务产能变化、各类活动影响对于关键容量指标变化的管理过程；
（3）明确在达到系统容量指标阀值的情况下，对系统进行优化、扩容以及业务应对
等活动进行的规范和管理环节，明确容量变化时各系统应采取的措施；
2、 基础数据收集及分析： 关键容量指标（KCI）梳理及入库
分批次对重要应用系统进行业务容量分析，完成关键容量指标的制定：按照各业务系
统（或独立业务模块），根据应用系统对整体业务的影响程度，分批次建立各系统的关键
容量指标，并对关键容量指标进行数据采集，为监控和分析建立基础，总体上分为 6 批次
进行：
（1）运营类系统： 根据目前的系统分布、影响程度，结合相关各系统的建设项目，
分批次进行实施。具体而言， 目前运营系统的关键业务指标和运行监控基本比较成熟，因
此可直接运用目前的关键指标进行监控， 且运营系统做为业务运营的关键性系统，产能影
响明显， 因此运营系统作为第一批关键容量指标系统纳入管理，运营类系统的容量指标重
点是能够通过这些指标反应出系统对于业务产能的支持程度；
（2）互联网系统： 从 2013 年开始，互联网类应用开始越来越重要，由于互联网应用
系统具有周期短、变更频、社会影响大等特点，该批次的应用系统关键容量指标梳理作为
年度容量管理项目的重点来进行，互联网类应用系统包括现有网站、 商城、微信等应用系
统，互联网系统容量指标应考虑能够承受的用户访问、客户端响应速度、集中的用户访问
程度等；
（3） 渠道类应用系统：渠道类应用系统是与客户直接交互的通道，其容量关系到对
外通道的稳定性，是实现客户沟通的重要手段， 对于容量的要求尤其重要， 因此需对该类
系统尽快完成关键容量指标的梳理和监控，渠道类系统关注的容量指标主要考虑一段时间
内该系统的交易通过量；
（4） 其他生产类系统：其他生产类系统按计划纳入第四批、第五批进行，主要包括
基础架构类系统、风险控制类系统和其他辅助生产类系统；
（5） 办公类管理系统：办公类管理系统也纳入容量管理计划；
应用系统关键容量指标的制定采用 PDCA 模式进行，即先根据最表面的业务应用场景
为系统制定关键业务指标，再逐步深化分析影响业务指标的系统容量指标，逐步完成对该
系统的容量数据的采集，为后期的模型建立数据基础，关键容量指标的完成标准为关键容
量指标容量库的建立和管理状况，为系统建立容量阀值，定期发布系统容量报告。
3、 监控管理系统建设： 关键容量指标的监控与发布
建立重要系统关键容量指标的监控机制，应用系统关键容量指标库建立后，需要建立
常规性的容量监控机制，否则系统容量管理无法有效落实。
本着实用、高效的原则，经过若干软件产品的调研、评估和试用，我们觉得目前市面
上并没有合适的软件可供试用，主要原因是：应用系统容量管理与实际的业务应用场景联
系紧密，有其特定的要求，而一般软件产品为追求通用性，要么在功能上比较粗，为了适
应某些场合需要进行大量的定制化开发，要么在功能上会有大量冗余，大部分功能根本不
会用到，反而可能影响应用的效率，同时考虑到价格因素，我们觉得通过自建系统更容易
贴合目前各系统容量管理的实际需要。
常规性的容量监控机制，主要包括以下几个方面：
（1）关键容量指标库数据采集：通过从各个系统或软件定期收集相应的数据，导入
数据库，根据不同容量指标反应的容量状况，数据采集的频率有所差别，对于性能影响较
大的数据，需要采取实时或准实时的方式进行，对于容量影响不明显的数据，则可将频率
放宽，如天、周、月等；
（2）实时监控页面：对于变化频繁的关键指标，以实时的方式收集数据，经过计算
后可直接反应到界面上，提供给值班人员、监控人员进行监控，同时具备报警功能，满足
报警策略后即进行邮件、短信等报警；
（3）预测报告：根据运营产能规划，定期自动生成容量报告，具备一定的预测功能，
即输入业务量预估后，自动进行容量影响分析，提供给容量管理人员进行分析，更好的对
各类活动、扩容需求等进行数据支撑；
二、 容量管理内容
不同的应用系统容量管理内容不尽相同，随着系统复杂程度的上升，容量管理的复杂
度也几何上升，系统间存在的各种联系，进一步加剧了容量管理的难度，因此，我们对应
用系统容量进行层次划分，以便更好地进行分类、分层次、有目标的实施。
系统容量管理代表了该系统的处理能力，即一段时间内系统能够承受或处理的最大负
载，所谓负载，就是业务处理能力或者服务能力，不同的应用系统所表现的会因其功能不
同而不同，比如信用卡审批系统中的审批处理量、客服中心的人工处理电话量等。 容量管
理包括动态和静态两种类型，静态类型的容量管理一般指相对固定的容器可装载量，比如
存储空间、数据库表空间等，这部分空间事先分配，满了就溢出，一般设定阀值，达到阀
值即报警、处理，清理空间或扩大空间等；动态类型的容量管理则比较困难，一般指负载
能力，造成负载能力变化的因素较多，影响的容量指标也较多，比如交易并发处理到一定
并发量后，会占用大量 CPU 资源、 IO 资源或内存资源，造成服务器资源调节困难，互相等
待，服务响应缓慢等，从而造成服务能力下降，如果系统没有负载控制调整的机制，就很
容易形成容量和性能问题。
1、应用系统容量分析
下图为一个简单的系统架构示意，大部分的复杂系统，基本上都是在这样一个简单的
架构上进行的扩展，我们以该架构对容量管理内容进行分析：

（1） 对外服务能力：对外服务能力包括请求接入和响应返回，对于用户而言，实际
上是一个层面，即用户发出请求后等待系统响应结果，正常情况下，服务能力体现在单个
客户的响应速度上，即多长时间返回客户，反映在“服务响应时间”这一关键指标上，这
个指标确定了对外服务的标准，也是对内部处理能力的要求，影响“服务响应时间”指标
的因素主要包括：内部处理能力、对外服务接口的“最大并发”能力，期中“最大并发”
体现了接口层面自身的服务能力，即在满足客户“服务响应时间”基础上，接口所提供的
“最大并发”能力，这两个指标能够反应出接口部分的容量；
（2） 内部处理能力： 内部处理能力是系统接收到服务接口端送来的请求后进行处理
的过程，也是这个系统提供业务功能的核心，内部处理能力涉及内容较为复杂，为了满足
对外“服务响应时间”的要求，必须低于“服务响应时间”这一数据指标，影响内部处理
能力的因素主要包括：处理程序自身的逻辑处理速度、处理的数据量大小、数据库读写速
度、调用其他系统接口的响应、硬件环境的处理能力（CPU、 IO）；
（3） 数据库处理能力： 大部分系统应用均和数据库相关，数据库的访问速度和并发
能力是影响内部处理的重要因素之一，因此在容量管理中，数据库容量及性能是重要的一
个关键指标；
（4） 其他系统影响： 主要指其他系统提供的服务能力（响应速度、并发）；
（5） 软件产品容量：如果应用系统使用了含有 lisence（或类似）的软件产品，则会
受许可证的限制，这部分也需要作为整体系统容量管理的内容；
（6） 硬件网络环境影响： 硬件、网络等硬设备的处理能力，最终影响系统的处理能
力和装载能力，主要硬件容量指标包括： CPU、内存、 IO 吞吐量、磁盘空间、存储空间、
逻辑卷、文件系统、网络带宽、交换机背板带宽、端口数等。
复杂的系统架构，以最短板部分的容量为系统的整体容量，如集群环境下，以该集群
中最低容量的部件为集群整体容量进行计算。
2、系统容量分类
按上节分析，评估一个应用系统的整体容量需要从多方面多维度进行，由于容量管理
是一个静态与动态结合的过程， 可分为：
（1） 业务处理量： 反映在对外接口部分，主要评估响应时间要求内的最大并发能力，
由于对外接口可能提供的服务是多个，按实际场景分析最大和最小容量；典型的服务接入
如 WEB 集群、 Web service（集群）、 socket 等；服务接入后一般交后台程序进行处理，处
理结果最终返回服务接入端，因此可以每个服务（交易）的响应时间作为容量评估的一个
参数，其反映的是后台程序的处理能力，表现的是一段时间内的服务通过量；
处理量相关部分容量指标：
系统最大并发量：
系统服务响应时间：
……
（2） 业务承载量： 承载能力相对静态，表示该应用系统能够容纳的数据量，在交易
型系统中，存量数据多少会影响服务处理的效率，进而影响处理能力，为了保障对外能力，
存量数据必然有所限制，比如数据库中存放的历史交易信息一定不能是无限制的；大部分
系统都有批处理，批处理大部分会读写文件或数据库，作为整体处理能力的一部分，批处
理也需要纳入容量管理范围，允许的批处理时间窗口内，能够处理的数据量就是容量管理
的一部分指标；
承载量相关部分容量指标：
最大用户数：
数据保留周期：
活动数量：
账单日卡量：
申请件停留量：
……
3、 业务容量指标对应的系统性能容量参数
无论业务承载量还是业务处理量，最终在系统上反映的，都是系统的软硬件配置、参
数等实际对应值，从业务容量指标到系统容量指标的翻译非常困难，与各应用系统的复杂
程度相关，主要的系统容量或性能指标包括：
（1）网络性能及容量：带宽、网速；
（2）网络设备：端口数、背板带宽等；
（3）服务器：网卡、光纤卡、 CPU、内存、磁盘；
（4）存储： IO、容量；
（5）数据库：最大连接数、表空间；
（6）文件系统：空间、类型；
（7）应用服务器（APP）：连接池数量、 JVM 大小、端口连接数；
（8） Web 服务器：端口数
（9）消息中间件（MQ）：队列深度
（10）应用程序：处理速度
（11）批处理：作业的窗口
……
三、 关键容量指标实现
应用系统容量管理是一个循序渐进、不断优化的过程，戴明环（PDCA）的模式很容易
应用在容量管理上：计划、实施、检查、改进。 按批次有计划进行、实施关键容量指标库
的建设、在生产运行中检查指标库中的数据、不断地改进、优化指标库中的关键指标。
1、管理覆盖度
容量管理覆盖的目的是从管理上将主要系统纳入管理范围。
现有系统或模块有 80 多个，按计划的批次进行管理的覆盖，建立容量指标库，部分
公共性的指标（如数据库、中间件等）尽快纳入指标库管理范围， 2014 年实现 90％以上
生产系统的容量管理覆盖。
2、 两个层次细化指标数据
通过两个层次进行指标的优化：
（1）公共指标：如数据库、中间件、批处理、实时交易等，目前由专人或专门的系
统进行管理，这部分的数据可通过已有的机制统一收集和优化；
（2）逐个细化：分类别，按计划中的 6 个批次逐个系统进行细化，在这个过程中，
容量管理人员需要弄清楚各个系统的物理架构、逻辑架构、数据架构，逐步深化、摸索影
响业务容量指标的系统指标，根据已有数据进行分析，找出最关键的系统容量指标；
3、与业务产能的结合
业务产能、活动开展、外部活动都会对相关应用系统的容量产生影响， 要利用容量指
标库，厘清各种活动对于系统的影响程度，提前做好应对；
4、容量指标的监控
容量指标库的建立，为下一步进行容量指标监控奠定基础。
四、 系统化实现
1、系统架构要求
容量管理监控系统是运维管理平台的一部分，因此在架构上需符合一定的条件：
（1）采用 B/S 架构，展示部分需采用 B/S 架构，避免客户端安装；
（2）在设计及实现时可考虑一些新技术、新框架，模块化管理，后续增加其他模块
时可以
2、功能要求
（1）展现：各系统关键容量指标、关键容量指标数据（周期）在系统中的展示，一
段时间内的曲线和图形；
（2）数据采集：各种数据的采集汇总，在系统后台实现数据的导入；
（3）报表：
（4）预测：按活动的类型，输入业务指标后，自动反映出哪些系统受影响；输入业
务指标估算出系统指标的预测变化；
（5）监控与报警：根据预定的策略，对关键指标进行实时分析，满足策略的条件即
进行报警处理。