性能分析到底是不是性能测试工程师的能力？

最近觉得很是有点燥。

在我主观的意识中，觉得性能测试工程师个人如果不具备性能分析的能力，那这个团队也应该具备。

如果性能团队不具备，就应该是有一个虚拟的组织具备，而这个虚拟的组织由产品、架构、开发、测试、运维组成。这个组织的的工作需要串起来，而串起来的这个协调沟通的工作，在性能项目中，显然应该是由性能测试工程师完成。

可是在我们实际的工作中，性能测试工程师的职位一直是职低言轻的。从而导致的是，这个协调工作很重的分析过程，根本无法协调下去。

对架构、开发、运维来说，他们觉得这个过程应该是性能测试组的活。

而性能测试工程师本身也觉得似乎这个是自己的活，但是能力上又不具备，所以让其他人来帮忙的。

在这种姿态之下，不管是不是职位言轻，首先，就低了一头。所以工作就像求爷爷告奶奶一样。

这是一种现象。

而另一种现象是，其他人也都非常配合，并且也都觉得这个是自己职责范围内的事情。但是每个人的知识背景有区别，对问题的判断点也不一样。于是就出现了，性能测试工程师，觉得是问题，但架构、研发、运维觉得并不是。

举例来说，你测试了一个系统达到1000tps，这时系统US CPU使用率达到99%。你会觉得这是一个非常严重的性能bug。但是其他人可能都不认为是bug。有几种可能：

1. 上线会用更多的硬件机器；
2. 业务不会达到1000tps；
3. 系统已经积重难返了，现在即使是bug也只能这样挺着。

理由还能举出来一堆，不管怎么说，这个不能称为性能问题。

于是，你会觉得失望，为什么这么明显的问题，都不解决？线上可以用更多机器，但是解决了，不是会省下机器也省钱了吗？.......

失望，性能测试没啥可干的，反正也不被重视。

昨天在我的微信群里，关于这个问题也有些争论。原问题是：

换个角度 说吧。你们觉得做性能的，有没有必要具备定位瓶颈、分析性能根本原因的能力？ 我们不管领导和老板、项目啥的。就是在这个行业中混，有没有必要？

得到的结果是这样的回答：

1. 研发单元阶段就能上性能跟踪了，真的上线还能优化几十倍一般都是业务优化，代码优化也是写的太挫了吧

2.外行看热闹，内行看门道。有几个内行能走上领导岗位？

3. 定位分析能力要有啊，才能知道优化硬件还是软件，不过有了apm能玩的事情很少了。

4.从技术上，性能测试必要具备定位瓶颈、分析性能根本原因的能力。前提 时间和资源宽裕。

5.这些年做项目，深深发现 有些理论和现实 是相悖的。项目要考虑成本，时间，范围。 做学问 对时间 因素 考虑的不太多。

6. 从质量管理的角度，性能在于设计，二不在于优化。

7. 他们说的成本高, 不是指分析成本高，而是指优化成本高，优化的时候风险很高, 导致成本很高。

8. 如果是应用层面和代码级别的bug导致的性能测试，一般还容易发现，优化性价比很高。但是如果是 系统级别的问题，例如：安卓操作系统或者mysql的bug，bug定位都很难，别提优化了。

从这些聊天信息来看，基本上体现出来一个事实。没有人关注我要问的问题本身，就是性能测试人员是不是应该具有性能分析能力。而是关注了一堆，其他杂七杂八的内容，这些内容包括：

1. 项目管理不善，所以性能价值体现不出来；

2. 工具可替代分析能力；

3. 性能在设计阶段就要考虑，所以测试阶段不优化也合理；

4. 定位优化难度大。

实在是不想截更多的聊天内容了。从这些内容，我也更清晰了一点。不管什么话题，只要人一多，就天马行空了。话题散到这种程度，顾左右而言其他，就是不聊话题本身。

它反应出来的是什么呢？社会对性能的认知，也会是这样的天马行空。

在我看来，这才是性能测试行业的悲哀。

而我一直还在坚持着觉得性能测试团队应该做好的事情是：测试、分析。这两件事情。

不用管用什么工具平台（因为现在很多人仍然把性能测试定义在会用工具和选择用什么平台上），到现在为止，我没发现一个工具平台，可以告诉你瓶颈在哪里，别告诉我APM能做到，你见过哪个APM能把系统、网络、链路等结合起来做相关性分析的吗？我看过更为复杂的商业剖析工具、运维工具、APM工具等，但是我从来没有发现这些工具，可以给出一个瓶颈的答案（别说CPU高达90%以上是个瓶颈的答案，说出这话的最多是个初级性能工程师）。

而现在迷信的那些看似高屋建瓴的高端理论，到了落地之时，又有几个人看到了不断缩小的过程？

而那些看似有道理的宏阔总结背后，可能连那系统都没有见过，就可以总结的顺理成章，动则双十一流量，动则12306架构，振振有词的飘在天上。

我和BAT、京东等企业的性能工程师，也都有长久的交流。他们自己每一个人，都不是所有系统全都能cover的。

为什么说性能测试工程师或性能测试团队要有分析的能力？在我的经验当中，我见过很多的场景，有了性能问题，开始扯皮，架构、研发等职位的人拉到一起居然不知道问题是谁的。可能是底层一个包有bug，引用了导致了应用有问题；可能是一个操作系统参数影响了上层应用。而这样的问题，很有可能就会被搁浅。

这里其实需要有可以串起来分析的角色，而这个角色，可能来自于架构、产品、测试、运维，但这个过程中免不了的。

有人说，测试可没那么大能力和权利，那我只能说，你确实职位还不够。

如果一个系统的扩展能力好，既然单点支持tps低，加机器会是一个又快又省心的选择，只是成本高一些。

之前去上海跟一个物流企业的性能团队的人沟通，饭桌间说到一个案例，一个做性能的人（名字没告诉我）给做了一炖（此量词不是错别字，我特意用的）分析之后，最后给出结论：加机器！！ 

我靠，人家一听不乐意了，这资源都没用上，加什么机器？就算资源全都用上了，加机器是不是也得给个证据？最后，这个人被连包请出来公司大门（这个场景是我臆想的）。

虽然可笑，但是也反应出一些现实。

我在很多企业见过，物理硬件非常好，就是性能上不去。最后也是加机器解决，我经常在这样的项目中算一笔帐给他们看。

对于有钱的单位来说，无所谓的，反正钱也不是花我个人的，是企业的，是国家的。我做得好不好又有什么呢？我做那么精致又不涨工资。有这样心态的，我只能说，see you in another life。

不管你是不是性能测试团队的人，只要做性能测试的事，在我看来，分析都是必备的过程。你可以因为项目管理、因为技术现状、因为项目积重难返、因为职位低微、因为薪水不高而失望、堕落、放弃，这也是常见的现象。

别说这样所以就不用去做分析了。

而坚持不应该是最优秀的品质吗？

做性能的人是必须要学着去做分析的。