7D性能项目日记9：​性能项目最终是要按目标交付，而不是按过程交付

在性能项目中，按目标交付是关键。而那些做个脚本跑一下，给个tps、响应时间、资源使用率的性能项目只能看做是按过程在交付，而不是按目标在交付。

在这个项目中，一开始的目标是明确的。就是要达到现在线上峰值的三倍。这时候要定目标也是明确的。

在项目初期，我就发了这样的一个调研表给客户。

让他们把每个系统按业务一行行根据生产环境的数据统计填进去，然后根据三倍的目标，就有了测试的目标。

这一步就已经非常不容易了，有兴趣可以回头看一下这篇文章。《7D性能项目日记1：你的性能项目真的有需求指标吗？》

其实这个形式不是固定的，只要有这些内容就可以。

在这个项目中根据这个需求，要做的事情还是不少的。同样还是根据我做性能的逻辑来的。

这个逻辑真的帮助我在项目中无往不利。根据这个逻辑，我的每个项目都有这样的结构。

这个阶段划分也可以根据客户要求的来定，只是里面的细节不能变。

根据每个阶段做的事情，将性能工程中的各个细节落实下去，最终给的结果就是这样的了。

通过这里的历史峰值TPS、最大TPS、目标TPS，就将过去、现在、未来联系到一起了。

这样的比对也是为了回答一开始定的项目目标。

要做这个图很容易，其中的关键是这个图中的数据是不是精准。

要想精准，那就要需求指标、性能环境、性能场景、性能分析几个细节上做到连贯，做到极致。

在这个项目中，因为环境用的就是生产环境，数据也是用的生产数据，架构也是生产的架构，所以这几点上都不需要做差异分析。

需求指标是明确的，所以也不存在理解上的偏差。上到领导，下到干活的，大家脑子里的东西至少在我看来做到了统一了，平时在工作的时候，我也一直跟大家说，我们要做到什么样子，这个项目才算是结束。

当然每个项目从一开始我就已经想好了如何结束，也许是做得多了，这个过程倒是不难把握。

这里还有一个关键就是“性能分析”，其他的工作都不算是太难做，但是分析我是担心的，因为没有分析就可能没有明确的系统优化方向，没有明确的优化方向，也就丢掉了一开始对客户的承诺。

所以在这个项目中，我一直强调分析过程要明确记录下来。记录了两个瓶颈分析报告。页数如下：

加在一起332页，当然这中间可能存在多记了的情况，但是也足以说明这个过程中，我们的努力工作。

在项目的结束，也有一个测试过程报告。页数如下：

还有一个45页的PPT汇报材料。

有了这些产出，再把过程中的脚本、场景、执行结果都归档下来移交给客户，就非常完整了。

在这个项目中，我们就是这样来实现的交付。

不仅有留下来的项目资产，而且最重要的是有结论。

这才是完整的项目。