前言

在这个项目的初期，合同流程都还没有走完的时候，我就已经开始介入需求分析的沟通工作了。

性能需求指标的细化

在性能项目中，需求分析是非常重要的一个环节，而真正能拿到非常细节的需求的可能性不大。

从我的理解上来说，性能项目的需求指标有几个层面。

1. 领导层
2. 业务层
3. 技术层

我们平时说的TPS、响应时间、错误率等都属于技术层。如果把TPS中的‘T’设定为有业务含义的话，那就可以把技术层和业务层链接起来。

而如果我们在定义TPS的时候，将‘T’定在请求级别，那显然就失去了与业务层的链接，就变成了一些企业中经常提到的QPS、RPS的概念。而这样做在技术团队中尚能很好的沟通，但无法支撑业务层的需求指标，还要进行换算才可以。

领导层的需求指标更为宽泛：像支撑1000万人在线；支撑业务容量峰值而不死；当业务容量超出能力时可以自动快速扩展等这种笼统的描述。

而性能团队要做的是对这样的宽泛描述在业务层和技术层细化。

我遇到的性能测试人员有些人觉得领导的指标是一句空话，我该怎么干还是怎么干，如果这个领导层的需求确实是瞎拍脑袋的，这样想也无可厚非。但是根据我的工作经历，瞎拍脑袋的领导还真是不多，能在那个位子，除了一些背景关系、欺下瞒上上位的，其他实干型的领导没有几个瞎拍脑袋的。

像我们这个项目中，目标是支撑历史业务峰值的3倍以上，历史峰值是在2023年过年前的某一天。由于从技术转型的计划周期来看，这个系统还需要支撑5年左右，同时从前几年的业务增长量来看每年有30%业务容量的增加，所以这个3倍的需求也是有理有据的，并且还不算高要求。 所以我觉得这个客户的领导层是理智并且务实的，这一点在工作的几次沟通中也得到了证实。

从这个逻辑来说，领导层、业务层、技术层的需求指标其实并不会独立存在成为拍脑袋的数据，而是真正的有递进关系。这样在做容量场景的时候，如果达到了技术层的需求指标，也就达到了业务层和领导层的需求指标。

具体来说：假设历史峰值总TPS是500，根据峰值当天的业务比例。举例如下：

（以上数据仅为示例）

对于银行核心这样的交易型系统来说，一个交易对一个请求的情况是比较常见的，所以技术层的TPS和业务层的需求指标是可以直接对等的，如果出现不直接对等的情况，就要在设计场景时加入业务级事务"T"。

与此同时，再从生产上统计出响应时间、标准方差等相应数据，场景的需求就完整了。

在这个项目中，因为核心是最重要的也是最有问题的一个系统，所以在核心系统的业务调研时，根据历史峰值场景的数据，我选择了近百支交易。做过银行核心系统性能项目的人应该有概念，在很多项目中都不会选择这么多的交易，通常就是根据历史数据，选择top二三十支交易就已经挺多的了。

但是这个系统我看过历史数据，再对照客户的描述，我觉得业务量增加到3倍后是非常有风险的，在选择的时候，我选择了百支交易。既然是根据数据来的，我觉得没有必要为了项目周期而缩减。

性能环境

有了需求指标，自然开始了后续的工作。根据我一直依赖的RESAR性能方法论，下面就是分析环境了。环境中，我主要分为三类：硬件、软件、数据、架构。

硬件环境

硬件比较容量理解，再分三大类：计算资源、存储资源、网络资源。计算和存储相对容易理解，网络资源这里要说细一点。网络资源应该包括的是：交换机、路由器、防火墙、负载均衡（如F5）等设备。我们不一定会遇到网络设备上的问题，但是了解了网络设备之后，才真正的了解了部署架构，接着才能真正画出架构图，对后续分析响应时间长的问题会很有帮助。就算是抓包分析响应时间也能知道在哪个层面抓。

还有一点，知道硬件的配置也是为了最后写报告时给出建议配置，比如说，这个项目中有一个网联系统，数据库96C756G的配置，有两台。而在压力过程中发现资源从来没有上过10%，而这时候TPS已经达到1200了。根据统计的生产历史数据，这个网联系统的TPS也就50左右。在这种情况下，即便是把这个系统调到资源都能用得起来，也没有什么实际的意义。

所以对这样硬件配置的系统，我们就会在报告中建议降配置。这让我想起来七、八年前做过的一个项目，生产系统的配置基本都是几十C几百G的硬件主机，使用率也是从来没上过10%，而电费一年可能就有几十上百万，再加上硬件损耗、维护成本，导致他们的领导层觉得必须得降配置了，不然一年IT部门花的都是冤枉钱。 最后通过性能项目评估了一遍，降到了原来的十分之一，并且性能还比原来的提高了40倍。

在这个项目中，并没有因为生产环境和测试环境硬件不同而需要进行建模换算的过程，因为当前用的就是未来的生产环境。

软件环境

软件环境是比较容易理解的，除了版本之类的常规信息，性能参数是最满目疮痍的角落之一。我看到的情况是，很多的生产系统因为业务量一开始并不大，急着上线，最后就一直用默认配置。

在这个项目中有hpunix操作系统，在上面运行着数据库，我看了一些应该调整的参数都还在默认值上，比如说信号量相关的一些参数semmns、semmni、semmnu、semmsl、semume、semvmx，有些不是没调，而是没根据系统资源和业务容量目标来调。这里不止系统级别的参数，还有java应用的、数据库的、中间件的等等，都得一一梳理。

对于参数的调整，并不是说默认值就一定得调，关键是看对需求指标有没有影响，像这个系统在测试过程中就出现了SEM等待事件，那就显然是应该调的。

数据环境

数据的部分比较容量理解。仍然需要强调的是：1. 铺底数据要和生产量级一级，如果硬件达不到，那就要进行细化评估，评估的手段就是看SQL运行效率；2. 参数化数据一定要合理，一定一定要合理！

系统架构

系统架构是我在每个性能项目中几乎都会遇到的一个沟通难点。在这个项目中也不例外。一开始说要架构图的时候，就看到几个框框勾画了一下的那种看起来就很草稿的图。而我希望得到的架构图是有细节的，比如说部署架构图，应该把计算资源、存储资源、网络资源都体现在上面的，细到可以把IP标识上。这样在分析业务路径的时候就能对得上，不然就得自己一层层去找了。

在这个项目中的实际情况是，我们确实自己一层层去找了。然后画出系统中的交易路径来。简单示例一下：

在这样的图上，我还标出了所有节点的IP地址和端口。有了这个，我才觉得分析有了依据。

如果你是云原生的微服务分布式架构的技术栈，有链路跟踪工具也可以使用。但是！所有现在市面上的链路跟踪工具都具有着天生的短板，你知道吗？可以留言讨论一下。

对性能项目来说，每个环节都是会决定结果成败的。所以细节一定要做到。