银行业压力测试报告范文

导语：如何才能写好一篇银行业压力测试报告，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。

篇1

关键词：压力测试流动性风险政策建议

一、压力测试与流动性风险管理的关系

20世纪90年代初，一些全球性银行开始引入压力测试来评估其资产组合在极端情景下的表现。随着世界上发达国家和地区银行体系的不断发展与完善，加之压力测试能估计到非正常市场条件下的经济损失优势而在金融机构中得到广泛应用，成为风险管理的重要方法之一。在美国次贷危机之后，金融机构和监管当局进一步认识到压力测试在管理极端风险中的重要性。商业银行也逐渐将压力测试应用在分析极端条件下的信用风险、流动性风险以及操作风险等领域可能造成的损失。长期以来，银行业在识别和应对极端风险方面相对落后，主要原因：一是对极端事件发生的可能性估计不充分。具体而言，就是对极端事件发生概率认识模糊不清。二是存在侥幸心理。一些银行管理者认为，既然极端事件发生的可能性很小，不太可能就撞上，这种侥幸心理是最危险的。三是未能做到对极端风险的科学认识和评估。

二、压力测试在我国商业银行流动性风险中的应用

近年来，根据国内银行业的实际情况与自身业务的发展需要，也开始运用压力测试的方法来预防与管理流动性方面的极端风险。

1、相关理论分析

流动性压力测试的定义：流动性风险压力测试是在特定的时间段中，设置多种属于流动性风险极端不利的情景，对其引起银行流动性风险造成的损失进行预测评估，并以定量分析为主的风险分析方法。

流动性压力测试的目的：商业银行进行压力测试都有明确的目的，一般是针对近期可能会给银行带来风险的变化进行测试。通过分析特定情境下银行流动性风险，来判断银行抵御风险的能力，及时采取措施减少极端事件对银行带来的冲击。

流动性风险压力测试情景设计：主要分析造成流动性风险的事件及其主要因素，针对主要因素设定情景中国银行业监督管理委员会《流动性风险管理指引》指出商业银行应针对单个机构和整个市场设定不同的压力情景。

2、压力测试的分析方法

依据压力情境中所蕴含的风险因素的多少将压力测试方法分为两种基本类型：敏感性分析和情景分析。

（1）、敏感性分析

敏感性分析方法是指在不考虑其他风险要素影响的条件下，评估单一风险要素对商I银行资产组合的的冲击程度，所以又被称为单要素评估法。

敏感性分析法最大的优点是操作简单，易于上手，运用广泛。它完全忽略了其他风险要素的影响，所以可以清楚的看出单一风险要素对商业银行资产组合的冲压强度。在该方法运用时，要求能够准确的把握风险因素的冲击幅度，以确保压力测试结果的可靠性。敏感性分析法的缺点也是显而易见的，由于各个风险因素并非孤立存在，在一定条件下甚至会相互转化。风险因素之间的互通性要求综合考虑其对商业银行资产组合的影响，所以该方法不可避免的具有片面性。

（2）、情景分析

情景分析方法又被称为多要素评估法，主要是指情景构建，在多个风险要素共同冲击的极端情形下，探讨极端情形对金融资产组合的影响程度。

第一，历史模拟情景法。该方法是指对历史上曾经发生过的重大事件进行情景再现，复制这些历史事件中的风险因素，用于衡量对当今商业银行资产组合价格的影响。第二，假设情景法。该方法首先人为的假设了若干种重大冲击事件，如政治危机、战争、恐怖事件、地质灾害、股市崩盘、楼市跳水等，然后分析这些重大冲击事件对商业银行的影响。这些假设事件虽然发生的概率不大，但是危害却不小。因此，有必要召集具有丰富经验的风险管理专家集思广益，探讨如何客观高效的情景构造。

三、提高流动性风险压力测试的对策

为提升我国商业银行的风险管理水平，满足自身风险识别、评估、衡量、控制的需要，推动自身资产结构调整优化，增加市场竞争力，对于我国商业银行的压力测试工作建议如下：

1、建设与我国实际情况相吻合的流动性压力测试体系

流动性压力测试最初起源于西方发达资本主义国家，后来逐步扩散到世界各地，但是由于各国经济发展程度，金融市场的完善程度，商业银行经营体制，管理方式都千差万别，如果直接照搬他国的压力测试模式，难免会使本国商业银行的流动性压力测试结果的精准性大打折扣，降低压力测试报告的可信度，这样压力测试也失去了意义。因此在从国外引进流动性压力测试模型的同时，要积极地根据自身的业务情况加以改进，使之符合自身发展的需要。既要吸收国外流动性压力测试的有益经验，又要规避它在压力测试中暴露出的缺陷，形成我国银行业特色的流动性压力测试体系。

2、建设全行范围的压力测试框架体系，明确部门职责

为满足2011年巴塞尔新资本协议达标要求，确保相关工作落地实施，银行需建立一个全面风险管理部门，牵头压力测试工作，初步建立全行性的压力测试框架体系，制定包括全行压力测试的目标、程序、方法、频度、报告线路以及相关应急处理措施等内容的统一压力测试政策，规范压力测试工作流程，将压力测试作为常规性的风险管理工具，制度化、定期化。分风险类别制定压力测试政策，明确压力测试情景建立、执行压力测试、内部分析及报告、风险缓释与应急措施、重新评估压力测试、特殊压力测试等各项工作开展的流程，确保董事会和管理层对重要风险的压力测试的流程控制，同时责任到局部机构（部门）。

3、加强数据积累，改善数据质量

流动性压力测试无论是从数据收集，还是从量化冲击，建立模型都对数据的质量和数量提出了挑战。商业银行应按照银行业监管部门要求的规范格式，参考行业内惯例做法，强调日常性，突出特殊性。在保证相关数据质量的前提下，尽可能的全面收集所需要的数据。在日常活动中，数据的收集不仅仅局限于各种财务报表数据，还要辅之于非财务方面数据，以备日后的流动性压力测试之需。除此之外，银行同业之间加强协作，做到数据资源实时互享，优势互补，提高数据利用的效率。

4、建立专门的压力测试机构，完善公司治理结构

要改革相应的压力测试组织架构和运行方式，从而将危机意识深入到企业文化的骨髓。建立专门的压力测试机构，不仅可以提高压力测试的效率，保证压力测试结果的准确性，而且提升了压力测试在风险管理的管理层级和管理地位，这样有利于减少压力测试结果传递给高级管理层的时间和距离，可以有效的纠正压力测试结果信息传递偏差。高级管理层收到压力测试报告后，可以及时的作出回应，这就加快了高层决策反馈给下级的传递速度，有效缩短了风险应对措施的实施时间，激活了决策的实施效率，避免了传递不及时带来的决策失效，达到指导银行风险管理工作的目的。

参考文献：

篇2

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

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

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

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

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

作者单位