基于商业银行信息系统的性能容量管理方法

通过监控、跟踪、分析信息系统的资源使用状况，对信息系统资源进行调整、分配、优化，确保业务处理的顺利开展，对于保障信息系统的稳定运行具有至关重要的作用。本文基于商业银行信息系统的性能、容量管理领域，旨在建立合理的信息系统性能容量测量和评估方法，通过实践分析结合根据不同方面的容量研究结果，对信息系统的容量状态进行判断，建立合理的信息系统性能容量评估模型。

【关键词】容量管理 容量测量 容量评估 容量监控 运维实践

人类社会进入信息化时代，日益激烈的社会活动对商业银行业务连续运营、健康发展提出了至高的要求，商业银行的信息系统基础设施必须具备极高的安全性、稳定性。信息系统的容量管理对于保障系统的稳定、安全、高效运行，保障信息系统的能够提供及时、快捷的信息处理能力至关重要。容量不足有可能由于促销活动、硬件故障等原因引起的信息软件系统不足以支撑业务运行的风险，可能导致业务的终止或交易缓慢，影响正常的业务开展；容量超配会造成资源浪费。

容量管理致力于根据业务发展需求，在恰当的时间（在需要的时候）以恰当的成本协调地提供所需的信息系统资源。通过不同层面、不同手段的容量管理方法的研究已成为国内外研究的热点，而信息系统性能容量管理是其中重要一部分，其在确保信息系统容量经济合理、服务可用性、业务可满足性等方面有重要作用。精细化的容量管理可以合理的对基础设施资源进行评估，满足当前及可预期时间的业务需求，避免由于业务增长、促销活动等原因引起的信息系统不足以支撑业务运行，进而出现业务缓慢或终止的风险。

制定适合的信息系统性能容量管理策略，对有效监控、管理信息系统资源有重要现实意义。对此，从信息系统的角度对容量管理进行讨论和研究，从数据中心现有的运维环境出发，建立适合的信息系统容量管理策略，实现有效的容量分析、测量和风险识别，提高日常容量管理工作的合理性和有效性，确保能够经济、合理地满足商业银行生产系统在容量方面的各项需求。

1 引言

信息系统容量是指信息系统以及支持其运行的信息系统基础设施可以提供的最大能力、空间或吞吐量。对于信息系统来说，业内常使用单位时间处理事务数、响应时间和并发量这些指标来衡量其容量。

容量管理通过监控分析信息系统资源的使用状况，进行必要的优化调整，制定容量计划，保障信息系统正常运行，支持业务发展。也就是说，对于信息系统，通过一定的手段对其依赖的信息系统资源的使用情况进行监控，如CPU利用率情况，结合信息系统容量来判断目前运行所用资源是否合理，并给出管理计划。

因此在信息系统性能容量管理的研究中，涉及到如下关键概念：

事务处理能力（TPM）：每分钟事务处理量。交易类系统中常代表“每分钟系统处理完成的交易量”，批量类系统中常代表“每分钟系统处理完成的任务数”，或其他可适用于代表信息系统处理能力的指标。通常在习惯上业内以“交易”代称“事务”。

响应时间：信息系统从接收一个事物到处理完成该事物的耗时，通常以单位时间或指定事物处理总量的总响应时间来计算平均响应时间。

并发量：信息系统单位时间处理的事物量，一般以同时点TPM、响应时间、时间长度计算平均并发量。

CPU利用率：信息系统所在逻辑服务器的CPU资源使用率，对于集群部署的信息系统，会通过一定算法得出集群逻辑服务器的整体CPU利用率。

2 信息系统容量测量

商业银行信息系统在开发阶段做性能测试、压力测试，分别从投产前和投产后两个角度对信息系统性能容量测量方法进行介绍，目的是为了解决“如何获取投产前的信息系统性能容量基线”和“如何对已投产的信息系统性能容量进行测量”。

2.1 信息系统的性能测试

信息系统在投产上线前，需要尽可能准确地进行容量测量。通过非功能测试和孤岛环境测试，为建立信息系统容量基线提供测试数据。

测试环境通常按一定比例分配相应系统资源进行测试，然后按照线性比例对容量进行评估。通过测试验证信息系统是否满足容量需求、发现性能拐点，形成上线参数、测试报告，指导信息系统建设容量管理基线。

孤岛环境测试又称为准生产测试，是在信息系统正式投产前，通过网络隔离等手段预防生产影响，在其实际投产使用的系统资源中进行测试，以得到更加准确的信息系统性能容量指标。

测试过程采用负载发起机和挡板程序模拟交易的渠道端与服务端，测试场景采用联机交易模型进行配比，每组场景单独测试，按照并发用户数梯度等差设置；按照设置的场景逐步增加压力，直到满足测试出口条件（满足资源阈值、达到性能拐点或其它约束条件），结束测试。通过这种方式，可得出如下容量指标：事务处理能力（TPM）、响应时间、业务成功率、系统资源使用率等。

为了尽可能准确的测试出信息系统性能容量，在进行环境准备、案例设计和测试过程中总结出以下需要注重的环节：

2.1.1 测试环境

（1）测试环境的部署方式应与生产环境的部署方式一致，如同为集群方式部署；

（2）测试环境应与生产环境服务器品牌保持一致。生产环境若为物理服务器/虚拟服务器，测试环境应与生产环境保持一致；

（3）测试环境软件配置应与生产环境或目标投产环境相同，如测试环境的操作系统、数据库、中间件等版本与补丁应与投产要求的主推版本一致；

（4）应提前分析测试环境与生产环境的基础设施差异，包括网络带宽、存储性能等；

（5）对于重要信息系统，当服务器配置无法与生产环境保持一致时，需保证测试结果达到设计要求。

2.1.2 测试案例设计

（1）涉及客户端的测试应尽量模拟完整的客户行为；

（2）测试环境数据库中的数据量、数据分布应与生产环境保持一致；

（3）设计单交易测试场景时，应选取对响应时间要求苛刻的交易和典型交易；设计组合交易测试场景时，应尽量模拟生产环境中的交易配比。

2.1.3 测试过程

（1）性能测试应能验证软件性能是否满足设计中的相关需求、能识别系统瓶颈，必须测到信息系统性能拐点；

（2）性能测试开始的必要条件是信息系统已处于一个比较稳定的状态，系统架构、主要代码、中间件、数据库等都不再有较大变化；

（3）性能测试应尽量包含所有交易路径应，并避免前/后端信息系统对测试结果产生影响。

2.2 信息系统的压力测试

压力测试在本文中专指实际生产环境中，通过一定手段对信息系统服务器进行加压，收集服务器在大压力情况下的操作系统、中间件、应用等的运行数据并进行分析，以验证服务器容量、性能拐点、资源瓶颈等是否与预期相符，提供系统优化、资源调整的依据。与上面性能测试不同，压力测试使用已投产的生产环境，真实交易数据，因此通过压力测试得到的容量指标更加准确。

压力测试方法：测试时间应选在交易量相对较低并平稳的时段，且应通过预估判断交易量可达到测试目的；在进行压力测试的过程中，逐步减少目标部署单元的服务器数量，将压力逐步引向少数服务器；当系统容量接近理论临界值时，应以最小粒度减少系统容量，以便于测试结果分析。

为了尽可能准确的测试出信息系统性能容量，在进行案例设计和测试过程中应关注以下各个环节：

（1）在设计压力测试时，应明确测试的目标信息系统、模块、部署单元，避免前后端信息系统、模块、部署单元对测试结果产生影响。

（2）在设计生产环境压力测试场景前，应全面评估可能对性能、容量产生明显影响的软硬件配置，在测试场景设计过程中设计不同配置的测试场景。

（3）若在生产环境中同时存在软、硬件配置不同的服务器，应优先设计低配服务器的测试场景，避免系统在大压力的情况下出现木桶效应。

（4）设计的测试场景应充分利用测试时间窗口。在每个场景中，应至少保证10分钟以上的系统稳定运行时间。

（5）应针对每个测试场景设计应急预案及应急预案的触发条件，避免测试影响安全生产。

（6）一旦测试人员发现系统异常或出现系统告警，数据记录员记录异常情况内容及时间点，测试指挥员应根据异常和告警内容判断是否继续进行测试或是否进入系统应急流程。

3 信息系统容量评估

从计算资源和并发能力两个方面对信息系统性能容量的日常监控和评估进行介绍，解决“如何分析信息系统的容量是否合理”。

3.1 数据收集

数据是研究的基础。对性能容量管理实践验证主要在三个方面的数据进行收集与分析，上线前的容量数据主要是非功能测试的结果，通过测试报告方便的获取；压力测试通过实验对数据进行收集整理；日常运行数据通过监控平台采集数据收集整理。

3.2 信息系统计算资源

信息系统的计算资源是信息系统处理业务的基础，通常用CPU利用率代表。通过对信息系统数据的观察，可以判定TPM与CPU利用率之间存在关系，尤其对于一个依赖于计算资源的业务系统，在一定的边界限制内，TMP与CPU应基本保持相同的比例关系，当实际数据符合这个比例关系时，可以依此推测预期TMP与CPU相互的对照值，当实际数据脱离比例关系一定范围时，认为测试数据已失去参考意义。为直观观测他们之间的关系，通过TMP与CPU观测值进行容量监测及预警，本文提出收集TPM与CPU对应数据，设计绘制TPM-CPU关系图，示意图如图1所示。

Mk（xk，yk）：通过性能测试获取不同压力下的相关数据，按照生产配置比例换算后的TPM和对应的CPU利用率，其中Mkm（xkm，ykm）包含测试得出的性能拐点值。

Mi（xi，yi）：为每天信息系统TPM峰值与对应时刻的CPU利用率。

Mj（xj，yj）：为每天信息系统CPU利用率峰值与对应时刻的TPM值，该指标作为参考可用于分析信息系统TPM-CPU是否峰值关系对应，可间接验证信息系统是否属于计算资源消耗型、是否存在其他资源消耗任务（例如批量任务等）。当出现系统故障时，应对噪点数据进行处理。

F1：TPM与CPU利用率存在一定函数关系，从原点出发经过Mk1…Mkm拟合的一条曲线F1作为TPM-CPU的理论关系线（绿线）。

F2：取F1线上每一点的y值±k1，x值不变，拟合一条曲线F2作为关系失效预警线（黄线）。

F3：取F1线上每一点的y值+k2（k2>k1），x值不变，拟合一条曲线F3作为关系失效警告线（红线）。

Fa：CPU利用率生产安全线，根据逻辑服务器的高可用部署方式决定，其中

。

Fb：CPU利用率低效线。如果CPU利用率长期低于Fb，则代表逻辑服务器资源过度分配，应分析资源降配方案。

x=c：为预期时间业务需求的指标值，也是性能测试的目标值。当TPM>c，则代表生产系统业务处理量已超过预期，性能测试存在失效风险，应沟通业务部门重新分析业务需求，分析信息系统架构，并重新进行性能测试。

F11（压测修正）：由于生产环境与测试环境存在着基础设施差异，所以生产压测的数据在反应信息系统性能容量方面更为精准。在进行生产压测后，根据不同压力场景下的数据，对F1进行修正。

监测及预测方法（以Mi（yi

情况1：如果（F1（xi）-k1）

情况2：如果yi

情况3：如果yi>（F1（xi）+k2），则TPM-CPU关系与预期规律出现极大偏差，无法预测的同时，信息系统存在随时突破计算资源使用率限制的风险。

尤其在一些版本上线之后，如果出现了情况2或情况3，此时应当分析关系失效原因，并重新发起性能测试。

3.3 信息系统并发能力

信息系统的并发量代表瞬时的业务处理能力，是其性能容量管理的重要指标。但并发量属于瞬时数据，通常并不会进行统计日志的输出，也很难直观地对并发量进行容量评估，但并发量与TPM和响应时长（RES）之间存在一定关系，根据相关指标设计一种模型估算并发量及其趋势。通过对信息系统并发量估算值进行容量监测、预警及预测，本文提出收集每日并发量对应数据，设计绘制并发量预警观测图，如图2所示。

F1（x）：每个信息系统在设计初期都有拟定的最大并发量，通常由进程数、程序限制、参数配置等决定，绘制一条最大并发量曲线，作为并发量理论峰值线。

F2（x）：取系统容忍的最大并发量的一定比例（k）作为并发容量预警线，其中0

Ci（xi，yi）：为日并发量峰值，xi为对应日期，yi为对应日并发量峰值。

通过TPM值和对应的平均响应时长约算平均并发量，公式如下：

平均并发量：

其中ti代表xi对应的最大TPM，ri代表ti对应的平均响应时长，以毫秒为单位。按照业内经验，对系统最大并发量估值为：

当yi

当k・a

当yi=a，并发量容量已不足以支撑全部业务处理需求，将发生流控或交易堵塞。

可通过简单函数拟合并发量趋势曲线，通过拟合函数初步预测未来信息系统并发量趋势。根据信息系统特性，如周期性波动较大，在预测趋势线时，应对噪点数据进行处理。

4 结论

容量管理对于支撑信息系统的服务水平达到既定目标，保证系统安全稳定运行具有至关重要的作用。信息系统的性能容量管理分为容量测量和容量评估两个方面，容量测量中的性能测试指导上线前对信息系统的性能容量进行测量并建立容量基线，而压力测试则是在信息系统上线之后，通过一定的手段在生产资源环境下对信息系统性能容量进行准确测量并修正容量基线。在容量评估中，本文提出两种对信息系统资源进行监控和评估的模型，通过对生产系统日常运行数据的收集整理和分析，得出容量状态，并给出容量规划建议。

作者简介

信怀义（1975-），男，河北省邢台市人。现为东北财经大学金融学院博士生，中国建设银行北京数据中心高级工程师。研究方向为资本市场理论、大数据金融。

作者单位

1.东北财经大学金融学院 辽宁省大连市 116025

2.中国建设银行北京数据中心 北京市 100068