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