引言

双11已过，看了很多电商的战报，惊叹于技术的发展与软件抗造的能力。但是在阅读的过程中也发现了一些问题：很多技术博文会告诉你他们用了什么样的技术实现了什么样的业务，解决了什么样的问题（就像某云宣传，58.3W笔/秒+全面云原生化，强有力的打了一波广告）。

但是如何通过压力测试来保障大促活动，压测应该如何做？并没有相关文章去分享经验。虽然保险并不想柴米油盐一样说买就买，没有那么大的交易量，但是测试之道基本是相通的，一样都需要通过压测来做保障的。

本攻城狮有幸参与及主导过保险开门红，双11等业务活动，对压力测试略有经验，通过此平台来分享一下，也算是对自己知识的一次梳理。里面有自己做过的事，有想做确做不了的事，也有踩过的一些坑，干货满满，一起来看。

了解业务活动的必要性

一般情况下压测人员不会与业务人员打交道，对业务也不会有太强的敏感性，所以通常拿到的测试指标都是开发人员提供的。这很容易会陷入一个误区，如果开发人员对整体业务活动和压测不熟悉，提供的指标可能会与业务活动的压力有较大的差异甚至无法提供。这时就需要专业的性能测试工程师介入熟悉业务活动，评估压力指标。

当然，性能测试工程师并不仅仅只是完成压测，到达既定的压力指标就可以了，还要针对一些特殊的活动制定特殊的压测场景来检验系统是否满足业务需求，举两个栗子：

场景一：抢单模式

A保险产品计划在X月X日的早8点开启销售，全国范围前1W单有优惠，返利30%

那这种场景会有至少3个压力点：

第一个就是大家通常会考虑到的，业务系统每秒或者每分最多可以出多少单。

第二个就比较容易忽略了，那就是销售员会在7点50分~55分之间大量涌入，这对账号管理登录系统及业务系统首页加载有一定的考验。

另一个是最容易忽略也是非常关键的一点：A产品在8点开始销售，那在7点59分之后到8点零几秒的时间内，已经登录进来的销售员会一直不停地刷新产品列表直到A产品开售为止。假定全国有80W销售员，那这80W人一齐连续刷新产品列表，如果这部分测试场景缺失，性能隐患未发现，导致生产服务器宕机，系统挂掉，那后果就不多说了。

场景二：预付模式

B产品就像某宝一样可以预售，出单流程基本走完，单子暂存至待付款保单模块，到某天的早8点开始付款生效，限售100W单

那这种场景也至少有3个压力点：

前两个压力机基本与场景一一样，区别就是关注最后一两个步骤的性能极限而不是整个出单流程的出单能力里。

第三个点就是当成功缴费之后，保单会存至已售保单。按照正常的思维逻辑与一般行为性，销售员会在保单缴费成功之后去已售保单里面查看。所以这时，对查看已售保单业务的压力会比以往大个好几倍甚至几十倍，这对Redis或者数据库都是非常大的一个考验（面对C端的APP同理）。

所以说只有在充分了解业务活动的情况下，性能测试工程师才能制定完整的压测场景来保障业务，这也是一个优秀的性能质量管理工程师所必备的素质之一。

全链路压测的必要性

现在压测场景已经根据业务活动设计好了，那我们现在继续往下走，聊一聊全链路压测这个话题。

性能测试成长阶段简述

阶段一：互联网发展初期，各系统规模较小，业务量也不大，一般情况下都是开发自行测试，没有专业的测试团队。

阶段二：后来衍生出了性能测试团队，由项目/需求来驱动测试。

阶段三：在成长到一定阶段之后就形成了性能测试统一的规范及标准，由被动测试变为主动测试。

阶段四：再往后就是性能评测能力的体系化、平台化，与研发、运维高效合作及赋能。

阶段五：devops开发测试运维一体化。

压测能力进化路线简述

做不了线上压测，也一定要做到线下的全链路！！！

如果说公司还没有达到线上压测的能力，无法开展，但是线下全链路一定要做！虽然说从硬件资源到压测数据与线上差别较大，但也应该想尽办法去贴近生产环境。

硬件资源：虽然说测试环境的硬件和生产应用无法比拟，但是一定要保证压测环境有一部分性能较优的机器及存储资源供参与活动的系统使用，实在没有也要找领导协调其他环境资源临时使用，否则压测结果毫无参考意义。

系统资源配比：活动条线各系统的资源配置一定要统一，与生产等配或者半配。尤其忌讳A系统等配，B系统四分之一配，C系统半配，这种情况下压测过程中会因为资源问题相互推诿导致压测进度缓慢。

存量数据：通常存量数据也是线下压测的硬伤之一，压测前也是需要通过生产数据脱敏或者造数使得各系统压测数据库存量数据与生产存量数据保持一致或达到同一数量级。

正式压测前的准备工作

目前为止，压测场景和压测基础资源已到位，是否可以开始正式压测？是不是感觉还缺少一些东西？

参数配置检查

执行压测前要对所有系统的中间件、数据库等的参数配置检查。因为有很多开发老师只做研发工作，对JVM，nginx，redis，mysql等相关配置并不熟悉。在环境搭建阶段使用的是各工具的默认值或者公司统一配置的默认值，因为参数配置和业务压力与机器配置息息相关，某些配置又非常影响性能，所以压测前一定要地毯式地排查一遍。避免因为一些基本参数设置不合理导致压测成本上升与人力物力资源浪费。

服务器资源监控

压测前也要做好对每一台服务器的资源监控及告警设置，这样在压测过程中，如果某个系统或者某个集群因负载较高导致性能下降可以快速定位并且及时解决，提高压测效率。

日志管理

因为压测数据量较大，各系统业务日志输出较多，对于每个系统的日志一定要做好准备工作。例如制作定时清理日志脚本或者在压测场景执行之前执行日志清理脚本等，避免因日志占满磁盘导致服务异常造成压测无效性。

预留资源

现在一般系统都已经是docker容器化部署，准备一些预备资源可以在集群扩容，或者有新业务模块需要临时压测等情况下有效减少服务器准备时间以提高压测效率。

各项目组压测接口人

指定的各系统接口人可以协助测试人员在压测中及时响应，快速解决问题，如果有条件最好能集中到一起进行办公，这样的压测效率提升是非常明显的。

达到压测指标是否可以结束测试

当测试结果可以达到目标时，恭喜你，已经完成了整个测试的三分之一。也许你现在会有疑问，为啥才三分之一？

那我现在问：

每个系统的每个服务，单节点可以支撑多少业务量？
如果活动期间突然有超预期的流量访问时，系统能够承受住多少并发，进不来的流量怎么办，会不会对正在销售的产品有影响？
如果要扩容，要扩多少，需要多久？
如果业务流程中，XX关键业务服务突然异常，重启服务需要多久才能恢复正常？
调用第三方接口时，如果响应较慢或者无响应，是否有应急机制？

这一系列的问题牵涉到了服务限流设计，服务熔断设计，服务降级设计，应急预案设计及演练等问题，都需要压力测试来做验证及演练。所以说测试结果可以达到目标也许只是走完了一小步，后面线性测试，极限测试，破坏性测试，稳定性测试，应急预案演练等场景都在等着你。

参与活动保障

压力结束，终于等到了活动这一天，要开始休息了吗？不！

如果有机会，一定要到活动保障现场，不仅仅是在人群中露个脸，你要关注活动压力有没有按照预期到来，压力有多大。各系统性能表现以及业务量。

通过观察记录活动数据来确认压测场景有否符合预期，有没有遗漏的压测点。这样后面再制定测试方案时就会更加全面与完整。

复盘的重要性

不要质疑复盘的重要性，团队与个人的成长可以在复盘的过程中极速提升。