7D性能项目日记6：在性能工作中痛苦挣扎的人呀

一、前言

前阵子在项目上跟大家一起吃饭的时候，问到每个人的性能工作经历都是什么样的。为啥会聊到这个话题呢，因为这个项目是一个临时从各项目组抽调过来的人组成的团队。大家都在这个项目中第一次遇见，彼此都不了解做事风格。

聊聊各自的工作经历有助于了解他们的想法和做事的风格。同时从这些人的经历上也能反应映出现在性能市场是个什么样子。

二、各自的性能工作经历

成员1：从参加性能工作起，也有七八年的时间，就一个人做性能项目，主要的工作内容就是做脚本、参数化等，跑起来给一个结果。因为一直一个人，没有人可以讨论，上网看了各种教程，东拼西凑地学习一些性能知识。没有系统的学习，没有性能体系的思路，没有性能分析的经验。

成员2 ：工作近十年，从参加性能工作起，在不大的团队中，四五个人。性能项目也主要是迭代中的验证工作，没有性能分析经验，在工作中倒是有一些性能流程的概念。

成员3：刚毕业没多久，进入项目也是迭代中的性能验证，工作一段时间也就知道如何做脚本、参数化，但对性能整体没有概念。工作内容单调，养老类的工作内容，技术提升慢。

成员4：参加过性能培训，但是教的也只是工具使用，没有性能分析和性能体系的内容。工作也有七八年，有主动提升的欲望，但苦于没有环境，网上的知识点过于散乱。

成员5：在大行外包项目中，体系看似完整、流程看似完善，性能需求、场景、报告也都有要求，但是没有分析的机会。因为权限、管理等原因，只能跟着项目输出，个人能力得不到提升。

成员6：工作八年左右，简历中写的有很好的性能分析经验。市场上对这样技能的人需求量是比较大的。但是简历归简历，在实际的工作中，技术栈的完整性和关联分析能力、底层基础知识点在有些复杂的问题中仍然达不到明确一些复杂瓶颈方向的程度。

…

我做性能工作也有近二十年的时间了，经历过的项目和项目中的人，在这些年中仍然还是看到同样的问题。

三、性能实施在思维逻辑能统一的前提下才能更顺畅

但是也有明显的变化，随着时间的推移，性能工具的使用已经不再是讨论的重点。从上面的成员经历上来看，性能分析能力和体系化思维成了关键。

比如：在这个项目中，遇到了一个问题就是：性能场景中压力线程数应该如何配置？尽管所有人在每个性能项目中都会操作工具加压，但是加压的策略却是五花八门。我在方案中写到了场景应该连续递增，以及判断最大压力线程数的两种方法：探测法、二分法。但在实际的操作中，仍然发现了想法上的不一致。像这样：

在这个场景中，显然在压力线程到20左右的时候，TPS已经达到了上限。它对应的响应时间图是这样：

在tps达到上限时，响应时间在300ms左右，现在问题就来了，要不要再接着增加压力线程呢？

在很多“压力线程就是并发用户”的人的概念中，那自然是接着加呀！加到超时报错为止！这种“压不死就往死压”的思维逻辑，是性能场景执行过程中的大问题之一。

首先，我们要判断的是，生产上在这种已经达到tps上限的时候，有没有限流、熔断、降级的架构设计，如果有，再接着压没有任何意义，因为压力大到会触发这样的架构设计，后续的请求都进不去了。

其次，运维在这种达到tps上限的时候，有没有告警配置及应急手段。如果有，再接着压也没有任何意义，因为已经采取 了应急手段，后续的场景也就不会出现了。

那，假设，以上两种情况都没有，也就是说系统没有任何保护和应急策略，生产上也确实会出现超过上限TPS的请求。那么这个场景才有了存在的意义。

注意：

1. 这时候这个场景的目标已经改变了，并不是要知道支持的并发用户数是多少了，因为支持的最大并发用户数在最大TPS的时候已经固定了，不会再增加。

2. 再往上增加线程是要知道，根据队列和超时的设计，这个系统能存住多少用户的请求。这时候是拿所有用户的响应时间来换取保存用户请求的上限，这个风险就是投诉可能会多起来。

3. 如果有些企业把没有超时报错前的压力线程数当成是系统的“并发用户”，那其实我们可以让这个“并发用户”的值无限增加。因为这里可操作的技术细节还是非常多的，像增加脚本中的停顿时间、增加后端队列长度、增加后端超时时长等等。但是这些操作都没有提升系统的TPS容量上限，只是hold住了更多的请求，但并未真正处理。对于业务或老板的视角来说，这样的动作可能是有意义的，所以在项目中，我们要先沟通清楚，再判断是否有必要做这样的场景。

如果加压到了这样的程度，这时关注的重点是什么呢？就是超时策略了。 根据前大后小的超时设计的基本常识，就看哪里先报超时的错了。

所以，从判断超时时系统能容纳多少用户的目标上来说，这样的压力场景是可以接着增加的。

在这个项目中，我们的目标其实是要知道最大的处理能力（TPS），所以在达到最大TPS之后，再增加压力线程的必要性就不大了。

这只是项目中的一个需要达成共识的细节，因为这个细节会直接影响场景的执行时间、执行结果、报告内容等。所以还是非常重要的。

四、性能项目中的挣扎

在性能项目中，有很多这样的细节，由于不同成员的背景不同，就会出现争论。而这些争论都来自于各自的理解。

当性能团队成员的意识不同的时候，能看到意识的不同，并平衡这些意识，就成了沟通的重点，也成了性能项目成员思维挣扎的重点。

大部分人面对一个和自己不同的思维逻辑时，第一本能反应应该是抗拒。这里的出现不同思维逻辑的不止是性能团队内部，还有客户方、第三方等等相关的人，不同的角色、不同的岗位、不同的领导等。要想把这些人的思维逻辑都统一，自然是非常困难的事情。但是不统一，又会出现沟通上的问题。

所以性能项目中的挣扎点就因此而变得多了起来。而这里面涉及的人，有些放弃自己的想法，躺平摆烂的说法就是：“客户要咋做就咋做呗，反正我们做完这个项目收钱走人就行了”，这是对自己专业能力的不尊重。有些是强迫各方接受自己的想法：“按我说的做，我就做，不按我说的做，我大不了不干了”。这是沟通能力的不足。等等等。

不管是什么原因，有很多做性能的人，在项目中慢慢地挣扎，然后就要么不再挣扎被磨平，也就没有了对职业的希望，只是赚生存资本的一份工作；要么倔强地保持自己认为的专业性，而团队配合度很差，慢慢被放弃。

如果想在性能职业中保持自己，又保持专业性，那就必须想明白性能项目和性能职业存在的价值和目的是什么，你在这个项目和职业中的价值和目的是什么。如果能贴合，那就没有那么多挣扎的痛苦，更多的是理解和期待了。