前言
本周六受邀，参加了由数列科技主办的线下沙龙——高可用&性能质量保障分享会。
分享过程中，参与沙龙的同学们提了很多问题，碍于手机打字确实不太方便，因此写了这篇文章，对这些同学提出的问题做一个解答。
当然，回答仅限于我个人的角度，仅供参考。
课程回放：高可用&性能质量保障分享会
Question
1、技术团队好与不好，怎么区分？@Jeffery
2、压测工具和方案应该如何选择？@一二
3、全链路压测为什么要在生产环境进行？脏数据如何处理？支付场景如何处理？@馒头大王-Manju
4、全链路压测，如果没有产品性能的baseline，如何设置并发量？@梧桐
5、生产全链路压测，如何保证生产环境可用，如何解决脏数据？@守正出奇
6、性能需求的准入规则如何理解？@不沾
7、流量模型建立的思路、前期准备、依赖的技术和工具如何了解？@不沾
8、热点数据预热怎么做？@大美丽与小旺仔
9、仿真环境如何搭建？相较于生产环境有哪些不足？生产压测如何保证不影响正常的业务？@泉眼无声
10、性能测试结果如何分析？没有满足业务需求如何处理？@久留
11、大促时候为什么不建议扩容？@暗夜
12、小公司如何落地自己的全链路压测平台？@Mike.liu
13、测试人员做全链路压测需要什么代码功底？@郑阳洋
14、如果压测没有覆盖到安全水位，如何借助已经压测的模型预测剩余的容量？@James-东方
15、证券交易所或者期货交易所这种金融行业是否适合全链路压测？@郑阳洋
16、影子表压测结束后还会在生产保留么？对生产的数据库是否会有影响？@虎魄2
17、如何根据自己公司的情况探索并建立适合自己公司的性能测试体系？@对方正在讲话...
Answer
PS：由于很多问题的point都很类似，因此我会针对这些点抽取共性来答疑，请各位知悉。
1、技术团队好与不好，怎么区分？
这是个因人而异的问题，每个人对工作的追求都有差异，对好团队的定义也有不同，我聊聊几个共性，供参考。
1）是否有技术文化？
所谓技术文化，在我看来就是对技术方案的选型&code review&编码风格&质量保障，有没有很好的落地实践。
2）是否有相对透明的绩效考评机制？
大部分人工作为了赚钱，职业规划其实比较虚。绩效考评机制能否做到相对透明和公平，是一个很重要的因素。
3）是否有明确的职位晋升空间和通道？
职级晋升、加薪永远是打工人最关心的一点。
4）你的leader是否能帮你成长？
这点其实很多人忽略了，但其实是最重要的。leader有一点很重要，向上顶住压力，向下争取利益。
2、压测工具和方案应该如何选择？
压测工具的选型，可以从三点来判断：
1）是否能快速便捷的安装部署并且支持分布式；
2）学习成本是否比较低，能让团队成员都能快速入门上手；
3）是否有完善活跃的社区或者团队持续更新优化；
压测方案，需要根据具体需求和实际情况制定，没有具有普适性的方案，基本只能靠经验和不断沟通来完善。
3、全链路压测相关的问题......
1）为什么要在生产环境进行？
- 模拟真实的业务场景；
- 节省环境的硬件成本；
- 节省搭建新环境的人力和时间资源；
- 长期来说，是一种生产巡检，类似于定期对生产环境的稳定性进行全面体检；
2）脏数据如何处理？
- 压测数据存储正式的业务表，通过特殊字段做区分，每次压测结束后进行清理；
- 影子库表方式的话，是通过特殊的标记将压测数据路由到对应的带特殊标识的中间件和DB。
- 影子库一般和生产的业务DB在同一个实例，这种情况下数据预埋是将生产数据同步到影子库，然后进行脱敏处理；
3）支付场景如何处理？
- 调用三方支付的话，采用mock或挡板的方式（mock-server或者本地jar包方式）；
- 如果是自己的支付服务，处理方式类似上述第二个问题，脏数据的处理；
4）如果没有产品性能的baseline，如何设置并发量？
- 业务需求一般都是模糊的，需要通过业务模型和流量模型来评估，然后和业务产品方不断沟通确认，需求都是不断沟通中聊出来的，没有一步到位的需求；
- 并发量的设置，取决于压测场景和策略，刚开始我建议通过梯度递增的方式不断加压，直到性能拐点或者出现资源告警等情况；
5）如何保证生产环境可用？
- 最稳妥的方式，选择流量低峰期（凌晨时间段）进行压测；
- 保证服务可用，需要有很多岗位的同学值班oncall，比如运维DBA研发测试等；
6）热点数据预热怎么做？
- 比如用户登录态的数据，比如用户的优惠券数据，都可以通过提前缓存到Redis，设置合理的过期时间来解决这个问题；
7）仿真环境如何搭建？相较于生产环境有哪些不足？生产压测如何保证不影响正常的业务？
- 仿真环境是全链路压测在生产落地的过渡环境，一般都是按照和生产环境1:1（比较贵）或者等比配置的方式来搭建；
- 不足之处在于没有实际的流量请求，请求需要自己构建，硬件各方面的配置以及参数和生产无法确保一致性。在业务场景复杂度和真实性上，有一定差异；
8）大促时候为什么不建议扩容？
- 一般大促时候，服务的扩容都是已经完成的动作。而且服务保护措施比如限流降级熔断，都配置好了。
- 大促流量峰值时候扩容，会引起一连串的连锁反应，某些服务扩容了，下游如何按照比例扩容，限流阈值、熔断阈值都需要跟着改，但如何改？改多少？都是需要决策且风险巨大的；
9）小公司如何落地自己的全链路压测平台？
- 全链路压测不是银弹，更不是万能。它只适合某些具有特定业务需求的公司，能否实施取决于是否具有合适的组织管理能力和对应的技术架构；
- 一般来说小公司没有特别复杂的业务场景和高并发，全链路压测落地又是个比较复杂的技术工程，因此不是很建议小公司搞全链路压测，特别是自研，我更推荐找成熟的商业产品，比如数列；
- 至于全链路压测平台实际上没有解决技术问题，只是更适合多人协同和规范流程的标准化自动化；
10）测试人员做全链路压测需要什么代码功底？
- 代码能力只是一部分，或者说不是必须项。分下面几项来说：
- 如果机制完善，全链路压测比较成熟，自动化标准化做的比较好，不会代码也可以，只需要点启动按钮看监控即可；
- 如果从零开始自研，性能测试需要的技术广度和深度又有一定要求。
- 比如：要对系统的技术架构、上下游调用、涉及的中间件、缓存、DB有一定的了解。对业务一定是要很熟悉的。还需要较为丰富的性能测试经验，否则有很多坑需要踩；
11）证券交易所或者期货交易所这种金融行业是否适合全链路压测？
- 我对证券或者期货交易业务不太熟悉，我说几点适合做全链路压测的场景，供参考：
- 具有高并发场景；
- 具有较为复杂的业务逻辑；
- 需要自上而下的支持（需要评估风险，是否允许犯错的空间）；
4、性能需求的准入规则如何理解？
不是所有需求（接口、服务等）都需要压测，做功能测试都需要需求评审，性能也需要。一般来说，是否需要做性能测试，有如下几点参考：
1）是否具有并发场景（比如限时抢购-怕超卖）；
2）是否需要写库（写数据一般都会加锁，行锁表锁悲观锁等等，不压测可能会出现锁等待超时）；
3）业务逻辑是否复杂，是否有太多的依赖（分布式微服务架构SOP等很多都有复杂的依赖调用）；
4）评估技术方案，是否有大量的循环、串行并行外部调用；
5）领导是否强要求（这个很奇葩，但真的有）；
5、流量模型建立的思路、前期准备、依赖的技术和工具如何了解？
1）流量模型的建立，一般都是通过链路追踪+监控得到不同调用链路上的QPS及转化率，以及强弱依赖；
2）前期准备的话，完善的监控体系是必不可少的；
3）依赖的技术和工具，现在有很多开源的监控工具，skywalking、cat、pinpoint、Prometheus；
6、性能测试结果如何分析？没有满足业务需求如何处理？
1）压测结果如何分析，这是个很深很大的话题。简单来说，结果是否满足预期指标，是否存在资源不足&资源竞争&耗时太长&服务异常等情况；
2）没有满足业务需求，就想办法满足业务需求，通过扩容&升配&缓存&甚至优化代码的方式，去满足业务需求，并且留有一定冗余空间，做好线上灰度和服务保护（限流熔断降级——这个怎么了解，后面话题再聊）；
7、如果压测没有覆盖到安全水位，如何借助已经压测的模型预测剩余的容量？
无法按照既有的压测结果评估实际的线上容量场景，所有的所谓预测方法论，都存在误差，敬畏生产环境的稳定性，敬畏故障。
8、如何根据自己公司的情况探索并建立适合自己公司的性能测试体系？
这个我其实分享过了，就下面这张图，照着做即可。有个小窍门：保护好自己，优先落地可行的方案。
结语
我只是按照问题回答问题，拆开来说，其中很多点都值得深入讨论，限于时间和篇幅，我们后续再见。
答疑仅供参考，不要照搬，要通过大量实践形成适合自己的方法论。