最近参加了一些沙龙，沙龙的议题大多是聊全链路性能测试方案流程以及技术等等，线上的全链路压测可以说是目前测试圈最热门的topic之一，话题几乎都是围绕如何落地全链路压测，如何做流量隔离、清理，在大促如何降低风险，但从提问环节中可以看出，虽然讲师精心准备了大量工程化平台经验，而实际更多困扰大家的问题不是一些“高大上”的技术，相反是一些“基础”问题；后来我也思考过，真正做到全链路压测的公司，一般来说技术体系和人员配置亦或是服务商都是相对完善的，绝大说的问题也就是一些技术细节和组织方式，解决方式基本都有对应的方案，block的难题较少；而真正一些头痛的问题比较多的在性能测试起步不久的公司，因为这方面的意识、组织或者技术起步比较晚，所以问题显得更接“地气”和实际，而这些问题反而会让一些基于成熟平台实践的大师一时语塞，找不到切入点。比如如何制定压测目标，这个我在《说透性能测试》一栏中第7章专门写过这个问题，后来我又翻了下自己的专栏留言区，关于这个问题的热度依然很高，于是根据提问特性，我打算继续写一篇文章聊聊我的想法。
我先总结下我认为的几个我认为极具误导性的回答，比如“二八原则”，按照80%人群在20%的时间段访问，比如根据竞争对手产品去分析，这些答案说到底太泛化，基本上是拍脑袋，在性能测试圈中缺乏具体有效的方法论和实践证明，或者说大部分案例都不太符合这个情况，我相信绝大部分做过压测尤其是为结果负责的同学应该不会直接套用这些普适规则。从我的视角来看，如何制定压测指标这个问题一直没有得到很好的解答根本原因是，看上去这是一个指标量化的问题，但其实是性能指标认知统一性和性能测试数据建设的多个问题，能够回答到这个层面的不多，绝大多数答案都是围绕在表层回答，所以这篇文章我讲围绕认识统一性和指标数据建设这两个维度。
一.认知统一性
先来说说性能指标的认知统一性问题，我专栏里也有同学问过300w并发怎么做？我第一感觉就是很吃惊，如果你能解释下你所说的并发是什么可能更好，因为并发目前在行业里用词是相对模糊的，每个人都可以有自己的理解，如果是我们通用的计量tps，根据支付宝披露的2020的双11数据，支付宝高峰tps应该是在58w左右，按照这样的逻辑，我想问我300w并发的同学所在公司的体量可能已经是支付宝的5～6倍，不过我也没有去问他是什么公司，能够达到支付宝双11数倍的量我想目前应该还没有，而如果真正能到达这个体量相应的技术和配套应该也是超一线级别，也不会问我如何去做性能测试，所以说，我先排除他们老板多点了一份花生米喝大了，我想这个同学的问题点就在于衡量性能测试的指标有没有统一认知，我也遇到一个团队，每次开会讨论制定压测指标场面很热烈，但最终实施下来又很难对齐，后来我去沟通后发现，他们都在聊并发，看上去衡量指标很统一，但是在实施过程中发现，测试同学说的并发是测试工具中的线程数，开发说的并发是活动中的活跃用户数，他们实际的做法就是拿这两个数据在强行匹配，但又迷在各自的认知范围内而不知道问题所在，这些也是性能测试刚起步的公司通病，就像插座和插头匹配不上一样，我在《说透性能测试》一栏中也提过:
衡量性能测试的指标，很多人会说是并发。并发指同一时间节点发生的事情，但这个同一时间并不是一个标准的度量，也不是我们性能测试直接测量出来的指标。在性能测试中往往是通过在工具中增加虚拟用户数得到的接口每秒的调用量去衡量。 在实际生产中，无论是网关还是服务通常都是记录一定时间内的访问请求次数，所以在业内，性能测试往往以 TPS（Transactions Per Second）作为最重要的度量指标，因为它具备可度量和通用性的特质，可度量指 TPS 是真实客观且明确的衡量指标；通用性指无论在运维角度还是测试角度，TPS 都可以达成一致的定义。
所以说我们往往以最终的tps作为标准度量，该方式也是互联网最常用的度量方式，这种方式无论是性能工具统计还是运维同学或开发做的实际监控，都是能够完全可以匹配上的，比如这个接口几时几分几秒被调用了，可以通过这样的监控数据得出实际每秒的调用量，而你通过性能测试得到也是直接接口每秒的调用量（即tps），这个是可以直接用来匹配的，也就是说插头与插座是完全能匹配上的，对于一些性能测试刚起步的公司，我不建议你们直接用并发这个指标，在实际落地开展性能测试过程中，这个并不是明确能够直接衡量或者测出的指标，所以这也是我说的第一点，制定目标的前提是你们团队对性能的度量指标已经具备了共识，否则其他无从谈起或者没有任何意义。
二.数据建设
当你们团队能够对度量指标形成共识后，也就解决了第一个问题，在大家都知道了tps是通用指标的情况下，那如何去确认tps具体的量级呢？关于这个问题我想从新老项目维度上去说。
老项目：
我说的老项目是指有数据监控沉淀的项目，如果你们公司这一块数据建设没做或者没做好呢那个新项目也差不多，如何去统计以及统计策略，我专栏里描述过，这篇文章里我主要谈一谈在我的认知里什么是做好呢？关键词我认为是细致，比如基于微服务架构，你的统计是否从网关、服务、接口级别都归档全面；第二个体现在时间颗粒度，有的同学只能按小时甚至按天给出相关的访问量，这样的颗粒度实际上太粗，一些网站的大促最高峰时间往往也就持续几分钟，如果你按照一小时去统计访问量在换算成目标tps，这样的tps会被平均拉低很多，所以说统计颗粒度一定要够细，这样我们的目标值才会更精准。
很多人有另外一个问题，那们统计的数值往往是根据以前的数据来的，下次大促我应该怎么制定呢？第一点是基于原来的老项目迭代是有一定的基准线，低于基准线是不能通过上线的。第二点对于峰值的目标，我认为可以基于每年的数据分析去考量，这些数据分析有哪些必备要素呢，我画一个简单的表格1，做一些数据沉淀，我们可以时间维度根据大促规则看每次的增量，通过系数来计算本次活动的峰值，也有公司会按照业务的增长目标去对应技术增长目标，我们做数据模型沉淀也是为了把这样的系数做到更具体。
不少同学跟我说我们是没有监控数据咋办？这个实际上也分几种情况。
新项目：
1.数据是有的，但你认知里是没有的。
我认为绝大多数项目是能获取到数据，像Nginx这样代理层就详细记录了每笔请求发起的时间，接口路径等，这样的数据绝大多数公司都会存在，而你可能不知道原来通过这样的方式就能获取，所以你就理所当然的觉得这个数据是没有的。
2.数据是有的，但你还提炼不出来有效数据。
这个也分两方面去说，首先是技术问题，专栏里写过一些，本文不去赘述，第二种是权限或者是协作问题，这个本质上还是体系意识问题，性能测试成熟的公司绝不是靠单个的测试工程师去支撑，一定是体系化的协作，对于这样的问题你应当在勇于提出，说清楚方法，价值，相信在一个健康的团队内一定能够得到相应的解决，而且我说的权限问题只是表象中的一个点，其他相类似的原因应该很多。
3.崭新的项目，确实没有历史数据。
也有同学说了，我这边新项目确实没有数据，应该怎么办？我认为可以这样做，第一确认接口基线是否都可以达标，未达标的接口进行优化；第二点，一般来说新项目上线不会一下子进行大促活动，都是有试运行阶段，在这个试运行阶段可以逐步看注册数据，模块访问量等等，先把数据积累起来看访问趋势。第三，在试运行阶段，关于数据这块主要关心统计的维度和颗粒度是否已经达到使用标准，从一个项目发展过程看，监控数据丰富度也是逐渐建设出来的，最重要的是项目用户达到一定体量后相关数据能不能充分的提取分析，还是迟迟连这方面意识都没有一直等到生产事故频繁。
老板不关心Tps怎么办？
有同学说我知道老师你说的对，我们技术部门指标也能对齐，可问题是老板往往业务出身，你跟他说tps他不懂呀？他只会问这次能承受多少人访问，活动有没有风险，这个应该怎么办？我们已经测出来了接口tps，我看了网上有关于在线用户数，并发用户数的推导公式，可以利用这些公式去给老板解释吗？关于能不能这样做，你可以从先从这两个维度去问自己；
第一：这样的公式你有没有去充分的了解并且能够解释清楚推导过程？
第二：公式具体产生的背景和夹带的经验值是否对符合你们公司的情况？有没有充分确认？
如果对于这两点你都说不清，我想你是不能对结论负责的，通过这些公式也很难说服老板，而且老板本意是想从一个更通用直观的角度能理解这个问题，通过他不懂得数据用晦涩的公式推导是得不到通俗的答案，说到底老板也并不关心你的在线用户还是并发用户，他也懒得去理解，他只想知道我当前系统的注册用户进来有没有问题，这次活动能不能承受，对于这样的问题我认为并不是完全靠技术手段去解决，我的做法还是通过数据建模，以业务数据和技术数据相结合的手段达到项目数据的度量关系，我可以在图1表格下扩充如下，这样的表单我也是为了方便大家理解，实际上有的栏目继续拆分有很多内容，比如接口tps，你还需要做各类接口的排序整理。这样的表格数据往往也是需要多次的积累总结，才可能得到相对靠谱的数据分析。
