本文主要是介绍7D性能项目日记1：你的性能项目真的有需求指标吗？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- 一、前言
- 二、大行和小行的性能项目区别
- 三、项目指标
一、前言
这阵子在一个性能项目中。都忘记了写项目日记。
根据之前的项目习惯，每次做一个项目我都会尽量记录一些东西。
之前我也不清楚为什么写这些，只是觉得要记一下。现在更清楚一点，写日记不仅是以后看了之后还能想起项目上的人和事；也同时可以给同行们一些启示，这个启示就是真实的性能项目是如何执行的。
二、大行和小行的性能项目区别
这是个商业银行项目，资产规模在千亿级别，和四大行的万亿级别差别还远。为啥写这个呢？有人说一个性能项目跟资产规模有什么关系呢？真是操着卖白粉的心。
前一两年在四大行之一里面工作了挺长时间，接触到的人、事和这样的规模的商业银行相比，差别还是很明显的。
首先，大行的IT组织结构、职责划分等会更为明细。 而商业银行相对简单。这一点在实际的工作中会有很明显的影响。比如说你要想拉个会，在小行中可能随手就拉了，但是大行中，很难做到这一点。这就事事在大行要做在前面，会议也要提前定好。这会影响一些进度，但也更规范。
其次，由于组织结构的不同，权限也自然不同。 这会体现在具体的工作中，大行的性能项目中，有分析权限的用户通常都不会到性能团队的人手中，而是由专职环境管理或运维团队负责，这就导致了性能团队中有分析能力的人无法心到手到地分析，只有协调有权限的人配合。而小行就相对宽松，测试环境的权限也可以给到性能分析人员，这样工作效率自然也就高一些。
还有，在实施工艺和实施规范上，大行相对全面，而小行有些是缺失的。 但也正因为这样，大行在实施过程中消耗在非技术层面的时间就要更多一些，而小行就少得多，这个多少可能是翻倍的区别。
其他还有很多细微的区别，这里就不一一列举了。 而这些区别的产生，和资产的级别是有关系的。可能你觉得小行也可以做到像大行那样，如果你是科技部的老大，可能想像一下，你能控制的团队规模和要做的事情有多少，一个企业的IT投入是有比例的，所以有些事情是做不到的。但是这个做不到不是无奈的做不到，有些是不需要那么做。
三、项目指标
回到这个项目上，在这个项目中，我一开始的职责是需求分析和技术支持。需求分析是现场的、技术支持是远程的。 所以我的工作周期是现场两周。
这个项目的容量目标是历史生产峰值的3倍。项目范围是8个最重要的系统（包括银行核心、支付等），再加上全链路场景（测试环境）。
前期我对几个系统进行了调研，看到大家对性能的反应是有很大区别的。在调查表中，有这样的内容：
对交易类的系统来说，没有用户概念，所以可以不用填写用户列。
而这里面的标准方差让有些人不明白，统计这个有什么意义呢？我就举了个例子，也是我之前项目中实际的事情：一个系统上线后，达到40万人使用的时候，大概会有200个人操作超时导致业务做不了，而这200个人中有部分人会打电话投诉到客服，当时为了应对用户的问题设置了8个客服，而这8个客服那几天其他的业务咨询都没干，就听这200个人报怨了。而这是明显的性能问题导致的。
这样解释过了之后，他们觉得这个值也是必要的，并且要在指标中确定的。
在上表中，要统计的是每个交易的，这里强调每个交易是因为有很多项目中给不了这么细的数据，从而导致容量场景的业务模型一顿乱配，
其结果可想而知，就是：我测我的，上线后你死你的，两不相干。
让我觉得可悲的是，在这个项目中的性能测试人员居然没几个人知道是如何把业务模型配置到性能场景中并且要在运行中保持模型比例的。可能在性能市场上也没有多少人这么做。
我在每一期的线上培训班、在以往的技术分享中都再三强调这个技术点，不管你是用什么工具实现的业务模型，但一定一定一定要在场景执行过程中保持比例关系，不然就是没意义的场景。
而指标对我们来说就是通过不通过的红线，这个红线可以高，也可以低，对性能项目来说都可以接受，关键是指标的高低会产生的成本是否可控。
**时间成本、人员成本、环境成本，**如果都可控的话，指标高一点也没关系。这让我想起来好几年前跟一个朋友的聊天中说到，一个企业的架构师要求TPS达到2000，结果性能团队一顿猛如虎的分析优化，最后也给出了生产配置建议，于是生产上就按这个目标去配了软硬件。结果这个系统在线上从来没有超过20TPS。
可笑吧？可笑吗？真不可笑。这就是性能市场的现状，提指标的拍脑袋，做性能实施的拍胸脯，结果却是人员成本、环境成本、时间成本的浪费。
现在有多少企业拿着超过生产TPS 百倍的硬件环境，运行着少得可怜的业务量。我记得之前看一个大家都认识的互联网企业的生产资源数据，从未超过15%的使用率。有人说那都是为业务峰值准备的，行，也说得通，但是在业务峰值的时候，资源使用率就真用得上去了吗？在系统死的时候，有多少的资源其实使用率并不高？有运维经验的可以想想自己的工作经验，有几个系统是因为资源使用率达到100%而死的？
所以，性能项目如果不为真实的生产容量目标服务，那就失去了存在的价值。
前阵子，我去了一趟长沙，跟一个企业的性能团队聊了两三个小时。他们买了工具、买了服务、做了项目，钱花了不老少，结果给出的报告却没有生产是否可以支撑业务容量的结论，而是当前系统的TPS是多少、拐点在哪里、CPU资源使用率在测试环境中是多高这样的描述性报告。
这就是项目目标和结论在真实性能市场中的样子。卖性能工具的企业已经挺多了，而做性能项目的企业却大部分停留在卖人头赚月钱的层面。
真正的性能项目的需求指标是线上不死，由此延伸出的指标细化才是有意义的。而性能项目的结论是如何能不死，对指标的细化一一评估，这样才对得上，不然性能实施中的苦劳都没有意义。
今天先唠这么多，我去看性能参数列表去了，那也是满目疮痍的角落。
这篇关于7D性能项目日记1：你的性能项目真的有需求指标吗？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
