7D性能项目日记4：做性能可不可以是一种信仰？

这个标题一写出来，应该就会有人说这是走火入魔了，一个职业有啥可成为信仰的？难道不要工资就为了干这个行业吗？当然不是，听我徐徐道来。

前几天在上海跟几个同行吃饭。其间谈到，有些人不愿意做性能（这里的性能包括性能测试、分析调优、容量规划等工作），其原因是太难了，其他的工作可能要轻松一点，并且从薪水上说似乎也差别不是很大。

由此我想到性能这个行业也确实是在这么一种状态：本该很有价值，但在实际工作中却因为技术、管理、流程等原因很难体现出价值来。这就导致了市场上对性能工程师的薪水定位一直都处于不太高的状态，比功能测试人员要高一点，但和架构工程师、开发工程师相比，还是偏低的。

但在实际的工作中，如果一个完整的性能团队，需要的技术栈是什么样的呢？

总结下来就是一句话：完整的性能团队的技术栈应该覆盖一个系统优化所需要的所有技术细节。这样的要求对一个人来说可能是过高了的（当然如果一个人可以做到，那也是非常好的），所以这里我写的是性能团队。这个团队可以是临时的、虚拟的团队，总之，目标是解决一个系统的性能瓶颈，达成指标。

从这个角度来思考性能项目的价值，那就是要做到满足线上运行的性能指标。而实现性能指标的过程所需要的能力，就应该是性能工程师修炼的能力，而修炼成这种能力就应该是一个性能工程师的信仰。 就像教徒修炼到无我相无人相无众生相无寿者相的境界。

可能有人觉得我在描述的是分析优化的能力，而不是性能测试的能力。其实不然，一个性能测试工程师对性能工具的功能使用熟练这一点基本上都能做到，但是会产生什么样的结果却不一定是非常清楚的。

前几天在项目上遇到的一个细节是，一个系统用50个压力线程递增，TPS只有20左右。我过去看了一下，TPS趋势图是一开始就到了20左右。而测试工程师对这样的趋势图没有反应。

这里其实就涉及到一个细节。在性能行业中，太多性能测试工程师把压力线程的配置当成最最重要的一个功能点，而不是关注TPS的趋势如何走向才是正确的。在以前的专栏中，其实这一点我也反复反复强调，一定要关注压力数据的趋势！趋势！这里所强调的趋势，在一个正常的场景中，其实也就是两个图的趋势：TPS图和响应时间图。

（这里为什么我不强调压力线程图呢？留个疑问在评论区讨论吧。）

于是我说把递增时间拉长，10秒上一个压力线程，结果上到5个线程就已经到100左右的TPS了。 为什么会出现这种情况？显然是响应时间很快，而压力线程增加太快的话，其实已经超过了服务器能承受的上线，于是tps下降了。当然这里还可以看到一个性能瓶颈就是服务器没有维持最高tps的能力。

在性能的行业中，将各技术栈融会贯通才能真正面对各种陌生的问题，而不是守着测试工具、监控工具那一点东西。现在的工具产品的设计，也不应该仅在测试、监控那点事上下功夫，而应该设计一些真正合理的性能工程级的产品。

再回到本文的开头。做性能行业的人，也要知道，在这个市场上什么样的能力值什么样的价位。想赚钱没有问题，先看看行业的能力要求，如果从1-100的能力要求，你能达到多少，再谈赚钱会更容易一些。

在每个项目中（这个项目也不例外），我会专门安置做性能分析的岗位，注意，这个和性能测试工程师不同，而是专职性能分析，给出具体的优化建议，包括架构级的、代码级的、SQL级的、配置级的等等。

所以真的喜欢这个行业的话，将修炼自己的技术深度、宽度做为信仰，可以让你更值钱，也更受尊重。