7D性能项目日记8：​性能项目的目标/进度/深度/费用管理

一、前言

在性能项目中，目标、进度、深度、费用这几个之间是有矛盾的。

二、目标

这里的目标就是指性能需求指标。像之前文章中提到的响应时间、TPS等。注意，我在文章中写性能需求指标时，都不包括资源相关的指标。因为资源指标是被动的，是在达到业务的性能需求指标之后用于衡量系统运行状态的。

当性能项目的目标已经明确了之后，如本项目中的目标是当前生产环境峰值容量的3倍（8个系统的单系统容量）。

下面要考虑的就是目标要达到的话，需要做的事情是什么。因为有8个系统并行测试，最后还要做全链路（全链路场景没有3倍的要求，只要测试出最大TPS）。按常规的性能项目阶段，大概如下：

（注：执行阶段和分析阶段是并行的）

前三个阶段都是常规操作。这些常规操作的进度都是可控的。

如果执行阶段的容量场景跑起来之后就达到了目标，那显然不需要做什么分析优化的动作，甚至瓶颈的定位也不是高优先级的事情了。

这里的问题就来了，如果达不到目标呢？比如得到的结果是这样的：

这时候，由于目标没有达到，分析优化就成了必然要做的事情。而分析优化的进度就成了项目的最大难点。

有性能项目经验的同学们会知道，当一个性能瓶颈没有精准定位出来的时候，一个项目上的厂商还那么多，这时候就容易产生推诿扯皮的情况。在这个项目中也不例外。

有一个系统确实没有达到目标，其实性能瓶颈已经定位出来了，只是解决方案上有多种。因为这个系统的瓶颈需要更改业务代码来解决，改业务代码需要不少时间，而系统又比较重要，改了业务代码之后要进行大量的回归测试。所以我建议数据库层面和操作系统层面做一些尝试优化的动作，以减轻当前生产环境中可能出现的容量峰值压力。但是数据库厂商支持人员连本职的分析支持的工作都配合度很差，再别说做尝试优化的动作了。

在性能项目中，这时候能体现出来的就是多方的配合度。配合度好，才能更快达成目标。

请注意，这里我强调的是达成目标。达成目标是最重要的，而不是去解决某个具体的性能瓶颈。

有人说，这不是废话吗？不解决瓶颈怎么达成目标呢？

年轻人，不要急，仔细想想。某个瓶颈不解决，也不一定是没有办法达成目标的。比如说一个节点TPS只有100，而现在希望能达到1000TPS，那是不是加节点就可以了？理论上是可以的，实际上大部分企业也是这么干的。只是这种方式，我不推荐。因为这种方式会导致大量的资源浪费，所以只有在生产环境出现性能问题，需要立刻解决时才做为应急手段。

三、进度

当配合度差的时候，进度就非常受影响了。 这时候靠什么来保证进度呢？那就是计划了。

计划不应该只列几个里程碑，而应该是详细的列出所有任务和对应的人，以及任务之间的依赖关系和冲突。

一个人没有完成任务，就应该让他看到对整体计划的影响。

计划管理的也不只是团队内的人，还有团队外的人。需要决策的也要把领导加进去。

四、深度

当一切都按计划进行的时候，应该有足够的分析深度。技术做到细节上的深度就容易沟通，什么是细节上的深度呢。

比如说，跟起来一个场景，你给出一个这样的图。

随着压力的增加，CPU使用率接近100%，网络进出都达到200Mbps左右，内存没有变化。

把此图发给开发说，CPU使用率太高，你们优化去吧。

这时候开发团队怎么干活呢？他一看这里面us cpu在50%左右，sy cpu在40%左右，其他类型的cpu计数器也有一些消耗。估计要拉负责操作系统的人了，运维或者什么角色的，反正这个是sy cpu占的，那就是系统级的cpu消耗，和我开发的代码没啥关系。

这时候运维来一看，确实sy cpu使用率不低，但是进一步看进程，是业务进程占用的sy cpu，所以还是这个业务进程有问题，还是该开发团队来负责，至少不是操作系统的问题。

这一套沟通下来，几个循环之后，即使是所有团队的人都是立即可以给出回复的，那时间成本也不低。

所以这时候做为性能分析工程师的价值就要体现出来了，不能让这样的问题在不同的角色里转来转去，要把问题分析到一个具体的技术细节点上，这个细节点是可以明确指向是某个角色的，不给甩锅扯蛋的机会，是谁的问题谁就要处理。

性能分析的深度是直接影响着项目的进度的，有人说分析太深了影响项目进度，根据我的经验，说这样话的人或团队是没有能力做到，才会说分析影响进度。

如果有能力分析的话，一个性能瓶颈应该很快就能分析到原因才对，如果问题不复杂，监控也齐全，也就是场景跑起来之后，几分钟就可以找到瓶颈在哪。技术栈再复杂一点的，也就一两个小时。如果能碰到那种找了几天都找不出来的问题，是非常非常少的。

在分析中，我一直强调一句话，如果你知道下一步做什么，就说明还能分析得下去，如果连下一步都不知道做什么，那就放弃吧，这个不是你能处理得了的问题。在这个项目中，我设置的专职性能分析工程师，每天被虐的一个问题就是：知不知道下一步做什么？图片

另外，在项目中我也强调，每个场景都应该对应着一个性能瓶颈（系统或产品迭代验证型的场景不在此列），因为不存在没有瓶颈的系统，即便分析到最后说是已经达到了硬件的极限，也是找到了瓶颈点，但是要有明确的证据，因为硬件的极限是可以通过基准测试得到的。

五、费用

对于一个性能项目来说，时间的消耗意味着费用的流失。项目上10个人左右，按一个人平均一天1000块来算，那一天就是一万，项目周期是两个月，一个月如果加班不算，按22天来算，那就是44万。再加上公司税点，销售成本，公司利润，至少还要加60万以上了。但是如果有人成本高，一天不止1000呢，所以项目为什么要紧赶慢赶地干呢，主要就是成本其实消耗的很快。

有些企业接到性能项目之后，就做个脚本、参数化，压起来给个简单的数据，写个报告这事情就结束了，其实这个时间成本主要是脚本开发、参数准备、场景执行三个方面，这是不需要做性能分析的项目，这样的项目其实可以做的很快。

像前天我接触的一个系统，从打电话沟通到做完，从晚上7点左右到凌晨6点左右，总共不到12个小时，一个系统的测试就做完了。这里总共做了5个接口，还包括了参数化的部分。

在我们做的这个正式的项目上，总共是120个业务左右，我们假设所有的接口都很简单，那其实也才需要288个小时，按一天8小时工作算才36天呀，就算有些接口复杂一些，需要做些插件什么的，那就一天工作10小时，总时间再加88小时，多轻松的一个事情。

可是如果加上分析呢？我们先不说调不调优，先说能不能分析出瓶颈来。这个时间就不可控了，因为有的问题，可能一两天都分析不出来。再加上技术上又有些缺失，那时间周期就更长了。

有一次，我有一个星期没在项目上，两个性能分析工程师居然一个星期都没有产出，因为我要求的是每个瓶颈的分析过程都要记录下来，没产出就意味着没有分析出瓶颈在哪，所以不知道记什么。

那这星期的成本怎么办？人不可能不发工资，技术能力不足导致项目周期变长，利润变低了，企业核算的时候会觉得这样的项目根本不挣钱，以后还是别接这种项目了。

但是不做分析优化，按大部分性能测试团队那样跑个场景给个没有瓶颈分析的结果，是不是可以呢？这显然不是客户想要的呀，客户就是要找到瓶颈在哪，以便做下一步优化策略，提高生产容量的。

所以当项目目标是提高系统的容量，而不是验证一下系统当前的容量是多少的时候，那分析优化就是必须要做的事情，即便是分析出瓶颈点之后，优化需要更长的时间，但也可以考虑临时的应急策略。

而分析的技能不足就会直接导致项目周期变长，而项目周期变长直接导致费用成本的流失。性能团队应该做什么也应该有明确的界线，瓶颈的分析定位是性能团队应该做的，这一点不能推脱。

六、总结

所以今天所提到的目标-进度-深度-费用之间是有直接的关系的。做为一个关心项目整体过程的角色一定要看清楚性能项目的逻辑，性能项目不像开发项目，我能把一个需求实现成一个系统，那是明确的结果。

性能项目中给出一个CPU使用率100%是不是个明确的瓶颈结论呢？这时候就要有判断能力了，这取决于我们的项目目标。

如果性能项目目标是提升系统容量，那给你一个CPU使用率 100%这个瓶颈结论，能不能帮助你提升系统容量呢？显然不能够，那它就不是瓶颈的结果，而只是分析过程中的一个数据，完全不可以做为结论存在。

在性能市场服务能力参差不齐的情况下，项目大家都在做，看似都可以交差，但是有没有作用，就要有评判的标准，这个标准就是目标能不能达到。