7D性能咨询项目日记1：客户要什么就要给什么，不是你会什么给什么

从培训需求到咨询需求

在7月底的时候，接到了一个培训需求，目标是能通过培训指导公司内部的性能测试人员进行性能场景执行和性能瓶颈分析。客户有一个系统，已经上线，但不知道系统中有什么性能问题。

从这个描述来看，既然是要解决实际的项目中的问题，那培训的形式可能就解决不了问题。

于是我就说过去现场看一下，先直接把当前的问题投屏出来看看，如果能立即分析解决，那就先解决当前的问题，再说培训或咨询的事情。

从我的经验上来说，有些客户虽然有紧急的问题，但是可能问题也只有一两个，不复杂的话，一会就分析解决完了。后续也不需要做培训或咨询，就当是技术交流。

有些客户是系统问题比较多，需要做一个完整的性能项目咨询，那才推进后续的咨询工作。

我到现场看了一下，现象是压力起来之后，服务端的CPU使用率太低，感觉没有压上去。现场分析解决了三个问题，CPU使用率达到了100%了。 然后这个项目就进入了咨询的阶段。

性能测试的交付物是不是只罗列结果数据

有的性能项目做完了之后，就是给一个这样罗列数据的报告。比如下面这样的数据：

• 平均响应时间（毫秒）
  

• TPS
  

• 服务器CPU使用率
  

这是别人给我看的报告中的一部分（已脱敏），并且别人给我看这个报告的时候，还特意说了，这个报告写的非常好。我看了一下，这个在执行上确实是挺好的。可能有几点是和我的逻辑不同的，这里也描述一下供讨论。

其中场景执行的截图大概是这样的：

从场景上看就是压力线程直接从一个梯度开始，然后运行30分钟。这显然不符合真实的生产场景，这里应该换成连续递增的加压方式。

因为是断开运行的场景，数据不连贯，所以上表中的数据只能手工填写。我们根据上面的数据做几个图看一下。



从趋势图上看，响应时间、TPS、资源使用率都在随着压力的增加而增加，所以瓶颈已经是非常明显的了。如果数据是满足业务指标的，这样的数据也可以结束了。

所以这里有个特别重要的结论要说明：满足业务指标。

注意，这里说的是要满足业务指标，而不是技术指标。如果对于无用户概念的交易类系统，给出交易对应的TPS、RT就可以回答，但对于有用户概念的系统，就要回答在线用户、并发用户这样的业务指标。

然后要说明当前性能瓶颈在哪里，后续还要做什么样的优化，以及对生产的配置建议和运维动作建议。而这一点在报告中没有体现。

从我接触到的性能项目的客户来看，大部分客户管理层的人，都更关心的是结论能不能满足业务指标，如果不满足有什么优化建议。

所以，客户想要的是这个系统上线后能不能稳定运行的答案。在做性能实施项目的时候，这个答案一定要给。

性能咨询是做什么呢？就是要告诉客户，当前的容量是否能达到业务要求，如果可以达到，可不可以推算未来可以支持的上限。如果达不到，当前的瓶颈在哪里，优化的具体方式是什么。 把这个过程中要做的事情一一列出来。也就是把一个完整的性能逻辑应用到项目中去。

上面是性能咨询中的具体技术工作的目标，还有一件事情要做的，就是要客户的性能团队能快速成长，最终实现的是独立完成性能项目。