在讨论大促质量保障可以做些什么之前，我们先了解一下为什么要做大促质量保障。

一般而言，平台大促即意味着流量暴涨和优惠力度暴增，特别是每年的618、双11和双12等大促更是一场电商圈的狂欢；暴涨的流量对系统稳定性的冲击，高额优惠对业务资损防控的考验，都比平常要高出数倍，出现了问题也会被放大数倍；这是一场没有硝烟的战争，宁可准备充足但毫无用武之地，也不能出现问题束手无策。

既然大促保障如此重要，那么我们要准备点什么来确保大促活动的稳定性，是我们要重点思考的问题。在得出答案之前，我们首先分析下大促活动我们主要面临的挑战点到底有哪些，再针对性的一条条去准备，去解决，便是当下我们比较有效的方案。

在GMV增长的欣喜之余，暴涨的流量的对系统的稳定性冲击，是首要面临的一个挑战点。

由上图可看出，在有活动的20:00和00:00点，都会有一波瞬时的流量高峰，0点的高峰相对于20:00点前的日常流量有至少3倍以上的增长。那么这里有两个不同类型的挑战点：

与此同时，增加的请求量对服务器和中间件的考验等都是我们需要面临的挑战点。

刨除流量暴增对系统层面的影响之外，另一个需要我们重点关注的点就是业务资损问题。

流量的增长对应的就是我们订单量的增长，此时如果发生资损问题，那么对应的资损金额也会因为单量增加而被放大；再加上大促的节点一般优惠的力度都会比平时要更大一些，就会更进一步放大资损的金额。

首先从系统层面来说，对于一些核心的节点而言，最重要的是保障系统的高可用；在Google SRE中有一个层级模型来描述系统可靠性基础和高层次需求，由下图可见，金字塔最底层的基座就是监控（Monitoring），再往上的层次是应急响应(Incident Response)和事后总结以及根因分析(Postmortem&Root Caue Analysis)，也就是我们的复盘。

稳定性金字塔的底座是监控(Monitoring)，这是一个系统对于稳定性最基础的要求；缺少监控的系统，如同蒙上眼睛狂奔的野马，无从谈及可控性，更遑论稳定性。所以在针对于大促类的活动，前置就需要梳理出可能的系统及业务异常点，做好监控和告警。

在进行大促稳定性监控梳理时，要先脱离现有监控，先从核心、资损链路开始，按照业务、应用（中间件、JVM、DB）、系统三个层次梳理需要哪些监控，再从根据这些索引找到对应的监控告警，如果不存在，则相应补上；如果存在还要考虑阈值、时间、告警人是否合理。

另外针对一些可能的资损场景，我们也可以增加一些资损或数据核对，做一个双重的保障。

发生了问题不可怕，可怕的是短时间内不能恢复导致业务受损程度加大；这里就需要从另一层面来考量，这样来进行应急响应，快速定位并解决问题。这里我们可以从以下几点入手：

每一个系统或者应用的承载能力都是有限的，如果有超出保障目标之外的流量过来，风险就很高，限流能力是必须要有的。所以在大促类的活动中，需要我们评估核心接口的承载能力，增加接口限流配置，防止突增的QPS把系统打挂。也需要增加降级配置，对链路中位置的异常进行降级处理。

预案就是对于突发情况的应对处理，所谓有备无患，执行时机和执行动作一定要清晰明确并记录在文档中，发生紧急情况时，按照预案执行步骤来操作。针对大促活动的功能或系统预案前期一定要梳理并完善，大促期间封网无法执行线上变更发布操作，预案是进行线上操作的唯一入口。

有了预案，那么这个预案是否能解决相应的问题，就需要我们对预案的有效性进行验证，也就是我们的预案验证与演练，在我们的测试环境一定要完整的走一遍预案的流程。对于生产环境，我们可以视具体情况进行相应的演练验证。

大促时所用到的业务能力，不一定是我们新增的业务功能，还有一部分是历史沉淀的功能，对于这些能力则需要我们进行一次有效的功能预演，确保我们的功能能够稳定运行。

像是我们每一次的大促活动，基本的都会有一些新增的功能提供，对于这些功能，在正式开放对外之前，需要我们进行一次内部小范围灰测，确保核心能力运行正常。

大促的某些活动往往都是由一个主会场来承载，在大促节点，不仅仅要关注我们的核心大促活动的单个能力，也要关注整个主会场的各模块功能是否正常，体验是否良好等。对于主会场我们可以在上线对外之前由内部产研和业务一起进行一轮人工的走查；不过对于众多的分会场，我们没有那么多的人力，可以借用我们当前的自动化巡检能力来完成C端页面的巡检。

我们还可以进行故障演练，以此来提高系统、流程和人员在面对突发状况的应对能力，真正实现故障快速发现，快速止损，快速恢复，提升系统的整体的稳定性。

我们以营销活动中常见的抽奖功能为例，来看看我们在大促活动中对这些稳定性保障手段的实际应用情况。这里说的抽发奖能力也在我们2022年的周年庆及双十一的大促活动中承受住了考验，主要功能是在指定的时间段内定时去抽取部分参与活动的用户发放优惠券，C端在指定的时间段内连续公示中奖用户。整体的玩法流程如下：

这里的抽发奖流程中，结合我们的业务玩法来看，可以分析出比较重要的是连续的抽奖能力和后续的发奖能力，保障C端能够连续的公示出最近中奖的用户。

以20:00-21:00时间段连续开奖为例，实际上我们服务端会在19:55分即开始了第1轮次的抽奖，抽出20个中奖的用户，供C端在20:00开始每隔15s展示1个中奖人。实际上也是为了留出5分钟的应急响应时间。

首先我们需要在上线前明确下我们活动的运行周期，比如我们这里的活动是10.26-11.1运行一周的时间，其中开奖的时间是每天的10:00-20:00，那么在10.26活动正式对外的时候，需要协调安排人员值班，关注线上会场运行情况，每天的10:00-20:00开奖时间段需要对应研发测试全天候在线值班。

与业务方的沟通中了解到，在其中的某几天会再购买首页的中通位投放活动，那么这首页透出的时间段需要研发同学关注系统水位，关注系统运行情况，适时调整机器进行缩扩容操作。

接着来看看监控告警这一块，上面分析了我们的重点要保障的能力，那么我们业务层面的监控就可以从重点能力来展开；以此我们可以得出以下几个监控点：

同时可以将一些非核心的关联信息打印出来，方便有问题是可以直接获取信息去排查。

接下来重点关注下抽发奖能力相关的预案，假设19:55分开奖异常，那么在这5min的时间里，我们可以做哪些预案呢？下面我们按时间维度来分析一下：

如果满足抽奖资格的人数不足20人或其他原因导致开出的中奖人数不足20人，未完成当前轮次的开奖，则会基于我们的预案，在接下来的19:56及19:57分再补开2次，只至开出足够的数据。

这样可以确保在短时发生了系统或业务异常时依然能够持续开奖，保障C端用户不受影响。

以上关于抽奖这块功能的预案，都属于系统会自动触发的类型，无需人工操作，能有效的避免系统及业务异常带来的负面影响。

预案准备完成，那么我们测试环境就需要针对预案进行验证，确保我们的预案能够正常执行，并实现预期的效果，避免在生产发生问题时无法及时处理。

在活动上线之后，我们和业务方对活动具体配置进行沟通，按生产正式投放标准配置一场测试活动，用于整体功能在生产环境的验证，进行一轮灰测，确保小流量场景下的功能链路能够正常走通。

灰测正常结束后也不代表就已经完事大吉，业务方对于正式活动的配置，也有可能出现差池，所以在正式活动投放出去之前，还需要进行一场功能预演。

前期和业务方沟通达成一致，配置的活动开始时间可以从25日下午开始，产研侧可以一起确保配置数据正常，同时可以通过直接访问H5网页进行业务功能验证及整体用户体验的评估，确保整体体验无误后，活动会在26日0点正式投放对外。

大促相关活动的质量保障压力会更大一些，需要更多的思考业务异常点和对应的解决方案，需要做更多的保障措施来保证业务及系统的稳定性，需要更大范围的去探索和实践质量保障的措施；这不仅仅是质量保障团队需要考虑和落实的措施，也需要研发、产品、运营和业务团队共同参与，相互协同来保障整个业务系统的稳定运行，带来更高的价值产出。