大家好，我是李哥。

进阿里以来一直听说一句话：“没有经过双11峰值验证过的技术都是玩具”。虽然有些夸张，但是不可否认的是，一年一度的双11，是技术最好的孵化器，也是技术同学最向往的阅兵场。

我很荣幸，担任今年年中大促的技术一号位，也就是技术负责人。今天就来跟大家聊一聊我们作为一名技术在大促中要去做哪些技术保障，以及如何去做。也希望大家看完，就像身临其境的感受了一次大促。

我将故事分为三大部分：事前、事中、事后，最后我们再总结。

首先在事前，我们第一件事就是参加KO会议(Kick Off Meeting，项目启动会)。

它主要会传达以下几个信息：

1. 大促的背景与意义
2. 大促的目的与目标
3. 业务的具体玩法以及具体时间
4. 大促的人员组织架构

也就是说，在这里，我们技术需要从中获取如下信息：

1. 业务预期DAU
2. 业务预期DAT
3. 具体有哪些活动玩法
4. 活动玩法的具体时间段
5. 哪些商品参与大促，是否有第三方商品
6. 这些商品的库存分别是多少

KO大会上，可能会是一个全局的，整体的，对于一些细节，下来我们需要与业务进行沟通，比如活动粒度是多少？宣传力度是多少？业务的预期DAU与DAT如何评估的？是否准确？等。

这一步的目的是确认你的信息是无误的，以及了解一些细节。

你需要清晰的知道，当前阶段每天的流量、DAU、DAT是多少，业务评估是多少，技术侧评估又是多少，当前阶段的性能是否能支撑即将来临的大促，如果不能，需要做出什么调整。

1. 优化？怎么优化？优化哪些业务？现在优化还来得及吗？
2. 扩容？扩容哪些服务？扩容到多少？为什么要扩容到这么多机器？
3. 降级？什么业务降级？业务是否支持降级？什么时候降级？

这么多问题，看起来现在就需要对业务进行一次梳理了。

我们需要梳理出哪些业务是核心业务，哪些业务是非核心业务，哪些业务是可降级业务，这类数据大致可以从上一次大促获取。

再加上上次大促到本次大促期间所产生的新项目(业务项目或技术项目)进行梳理，是否影响核心链路？是否进行了压测？压测结果如何？这些项目可能存在什么技术风险？

你的服务依赖哪些下游服务，这些下游服务又是如何依赖的，这是个很麻烦的事情，因为随着业务变大，依赖关系会变得非常复杂，很难判断与梳理。尽管很难，但是这个依赖关系仍然要梳理清楚，只有梳理清楚了，才有全链路。

有了业务梳理和业务指标，那么就在技术上要能够支撑到这个业务级别，那就是压测了。

到目前为止有两种压测方式：

1. 不扩容压测
2. 扩容后压测

不扩容压测一般不推荐，这种方式需要对业务指标打折作为目标来进行压测，最后在扩容的时候还是需要压测一次，因为局部压测不能完完全全代表整体压测，如果整体压测出现问题，那么所有的局部压测都是白费苦工。

扩容压测，就是指容量扩容到大促支撑位，然后进行压测。

值得注意的是，压测一定是针对生产！

有些同学对开发环境、测试环境、预发环境、灰度环境、仿真环境进行压测，从而推断出生产环境的性能。这是万万不可取的，因为环境不同，服务器的性能不一样，生产环境和其他环境的DB性能也不一样，还有一些中间件性能也不一样。所以，压测一定要在生产环境压测，但是有一个缺点，就是会对线上的正常流量产生影响，这也是不可避免的，所以压测的时候，一般都会选择流量不大的时候进行，尽量减少对正常流量的影响，一旦产生影响，请立即停止压测。

还有就是压测需要流量爬坡，切记不可一步到位，按照一定比例逐渐施压，每一个坡度都观察几分钟，没问题继续施压，达到目标后观察几分钟没问题直接停止压测，不可恋战！

为什么不恋战？因为大促的流量趋势就是那几分钟，长久的施压对服务器的性能有一定影响，比如CPU飙高啊，频繁GC啊等，所以在在压测过程中还需要不断观察系统整体性能，还有就是也会影响到正常的用户访问。举个例子，奥运会举重，明明只需要保证举起来三秒即可，你训练的时候难道要举起来三分钟吗？

对于压测，我们后面再单独拎一篇文章出来，这里就不过多讲述了，敬请期待！

压测完了后，我们需要输出一份压测报告，比如商详支持多少qps，下单页支持多少qps，下单支持多少tps等。

这些数据说明了，我们的系统，有多少实例，哪个接口能承受的最大峰值是多少。那么我们就需要对这个接口或这些接口做限流。

这里我们说一下单机限流与集群限流，单机限流指的是每台机器自身的限流，集群限流指的是整个服务集群的限流。

单机限流的目的是保护服务本身，保证自身服务不被流量击垮。

集群限流的目的是保护下游服务，保证下游服务不被当前服务击垮。

比如A->B->C，每个服务三台实例，整个B集群最大能支持150qps，C集群最大能支持100qps，那也就是说B服务需要设置集群限流100qps用来保证C，B的三个实例需要设置单机限流50qps用来保证自身不被击垮。

所以如果流量不倾斜的话，B服务每个实例会有33qps，如果倾斜的话，最大50qps。

我们回到大促限流，所以，我们需要拿着我们的压测报告，针对我们的服务做单机限流与集群限流。

限流后，我们能够保证服务本身不被击垮，保证下游不被击垮，但是，这不是我们的目标，我们的目标是要保证大促期间商详没问题，下单支付没问题呀！

所以，我们要降级，一些比较耗性能的业务降级，一些边缘业务降级，给核心业务让路。

然后就需要梳理这些业务，有哪些需要降级的业务？什么时候降级？由谁来降级？什么时候恢复等。

应急预案与演练

当我们保证了核心链路的正常后，我们还需要考虑异常的情况。对于电商系统来说，要考虑到整个生命周期异常的可能性，比如：打开商详页失败、打开订单渲染页失败、下单失败、履约失败等。说的都比较概括，我们当时准备了上千个预案！

淘系双11大促，为了安全起见，是不会有任何依赖外部系统的，因为第三方系统都无法承受住淘系大促期间的流量波。

如果你的电商系统有依赖外部系统的，那么你还要梳理出哪些渠道哪些商品会参与本次大促，这块也需要针对渠道做压测与限流，有可能渠道由于体系较小不支持压测，这时候你可能要考虑到在履约的时候做蓄洪与泄洪，使用真实流量来冲击渠道，用于检验渠道的性能。另外在有第三方参与的情况下一定要有每个渠道的应急预案，对应给用户展示的文案是什么都是不一样的。

最重要的是要与合作伙伴共同制定一份SLA(Service Level Agreement)：服务级别协议，服务提供商和客户之间的协议，用于确定所需的服务和预期的服务水平，对互联网公司来说是网站服务可用性的保证。

在这里SLA约定了客户对于合作伙伴的线上运维、计划运维、业务连续性以及故障处理能⼒的要求。

做完预案后，要通过预案平台进行演练，或者人工演练，要当做到熟能生巧，大促出问题后才会显得临危不乱。

大促出问题？你怎么知道这块出了问题？这时候需要监控，需要告警。

大促大盘监控、全链路监控、核心链路监控、压测监控、限流监控、资源监控、网关监控、渠道履约监控......

大促期间是需要制定很多规矩，比如发布红线、红线问责、预案执行规范、紧急扩容规范、紧急发布规范......，我们这里统称大促变更规范吧。

无以规矩不成方圆，制定这些规范的目的是能让我们明确问题发生后我们应该按照什么流程去应急。

还有很多其他的一些杂七杂八的，比如大促前每周周会、大促值班人员排班、大促作战室、问题的上升制度等。

到这里，我们万事俱备，只欠东风了。

事中是整个环节最简单的，跨度最短的阶段，但是简单不代表不重要。主要是关注以下几件事情：

1. 大促的关键节行为节点记录
2. 大促问题记录
3. 重点关注告警与监控
4. 出现问题按照预案与预案规范执行，按照问题升级规范升级
5. 大促期间严格控制发布变更与数据变更，避免影响大促

最重要的就是要持续关注告警与监控，一旦出现问题需要及时响应与止血，严格按照预案执行。另外就是关注大促每个场次的峰值情况，通过自动记录或人工记录的方式进行记录峰值，方便作为下次流量评估的依据。

事后我们最重要的就是要做大促复盘，盘点大促期间的一些好的点和不好的点，对于好的点如何延续到下次大促甚至更好，不好的点如何进行调整。业务上关注哪些商品在哪些区域更好卖一些，哪些玩法更能让用户接受一些；产品侧需要关注配合业务对于现有的产品模型做出一些调整与优化；技术侧重点关注性能，本次大促是否存在性能瓶颈，瓶颈在哪里，如何优化，架构上是否需要调整，下次大促如何去支撑等。

其次是降级恢复，在大促前做的降级，在大促后需要对其恢复。

我们还需要对于系统存在的性能问题进行持续优化改进，然后进行压测，得出结论，再优化，再压测，优化，压测，......。

总结&展望

大促前：KO大会、大促周会、细节沟通、流量评估、业务梳理、压测、限流、降级、预案、演练、监控、规范。

大促中：值班、记录、关注告警与监控、执行预案、执行规范、日会。

大促后：复盘、降级恢复、持续优化、持续压测、持续发布。

每到大促，如何保障系统高峰扛得住、长期平稳是每个大促人必须面对的问题。大促期间发生的每一个问题都可能被无限放大，所以我们需要谨慎对待，这开不得玩笑。