浅聊电商系统如何备战618

作者：DearNicole，原文：https://www.jianshu.com/p/98332878b132

最近临时618，各大电商平台又开始新一轮的年中大促，可以说618是电商平台上半年力度、影响最大的一次促销活动，也是上半年对系统最大的一次挑战。

做电商系统的同学都戏称一年有两次大考，一次上半年的618，一次下半年的双11。这两次大考出了问题，那么基本这一年的绩效就是不合格的，年终奖一定会大打折扣。所以对这两次大促尤其重视。经历过这么多年大促的考验，各个公司也形成了一套适合自己的大促备战的策略。今天来给大家分享一二。

笔者所在公司也是电商行业，规模中等，一年的GMV（交易流水）也在几百亿。大促峰值的订单一天也是百万单左右，所以压力还是有的，并且挑战还很大。如何保障大促期间系统的稳定性是我们近2个月重中之重的事情。

这里来跟大家分享下，我们是如何准备这次618的。

我们基本是提前2个月开始准备，有人可能会问，为什么提前这么久？提前2个月其实真的不算久了，让我来跟你算一算。

首选准备618，第一要了解的是业务部门的对这次大促的准备力度是怎么样的？预期的业务量是多少？这是一个重要的参考指标。比如，平时一天10万单，618促销的时候，业务预期是一天要200万单，那么你就要按照至少20倍的请求量来准备。

另外一点要个业务部门确认的是，这次打算用哪些促销形式，尽管现在主流的促销形式花样已经非常多了，预售、秒杀、满减、满增、用券、跨店铺用券等等，但每次促销的时候业务部门都会别出心裁发明一些新的促销玩法，如果这些促销玩法通过已有的功能稍加组合下就能达到效果那还算好，多数情况下是要重新定制开发，从产品经理跟业务部门开始讨论这个新促销开始到研发实现功能上线，最快最快也要1个月，新功能上了谁会保证没问题呢，并且还在大促这个关键节点，所以一般会提前一段时间上线，在线上简单验证一段时间，才会放心在大促期间使用。

所以提前2个月准备，真的不算久。并且这只是备战大促的一方面，还有很多事情等着我们去做。

刚刚提到，提前2个月跟业务部门一起准备，从业务部门要明确2个重要的信息：

一.大促期间的预计单量或者交易额是多少？

二.是否有新玩法的促销方式需要支持。

关于第一点尤其重要，研发人员要全面评估下目前系统是否可以支持业务部门预期的单量，如果业务部门一切准备就绪，在大促期间系统不支持，或者由于促销火爆，请求量比较大，导致整体大促销售目标受影响，那么研发的锅可就大了。

所以研发人员一定要全面评估系统的上限是否足以支持这次促销。研发人员如何评估系统的上限的？

一

般都会才有"压测"的方式。

压测就是给系统不断加压，直到系统出现问题，可以找出系统的短板在哪里，这样就可以对系统的短板进行有针对性的优化了。

但是压测方式有很多，这里学问也不小。

第一个面临的问题是，在什么环境进行压测？ 测试环境？线上环境？

测试环境的优点是：不影响线上的业务，怎么折腾都无所谓。

测试环境的缺点是：不具备代表性，不能准确反映线上的真实情况。因为首先测试环境的机器数量比较少，另外部署方式跟线上差异也很大，所以即使压出问题，也并不能代表真的有问题，仅能作为参考。

线上环境的优点是：可以真实的反映系统的健康水平。

线上环境的缺点是：

1.容易对线上业务造成影响，损失销售。既然在线上压测，那么目的一定是压出系统的瓶颈所在，系统出现瓶颈一定会对线上的业务产生影响。所以一般在线上进行压测都会选择在夜深人静的时候，尽量减少对线上的影响。

2.线上压测的另外一个问题是，只能进行“读”的压测，没办法进行“写”的压测。因为进行压测的数据一般都是假数据，如果进行线上的写压测，那么会对线上的数据统计造成影响。

说了这么多，看起来在那个环境压测都有些问题，那么有没有理想的这么一个环境可以供于压测呢？这个环境是可以有的，我们一般称之为“压测环境”，顾名思义，这个环境专门用于压测，一般情况下部署数量跟部署方式跟线上一致，或者等比例缩小若干倍，压测完的数据再等比例放大若干倍，基本可以体现线上的真是水平，但是这个环境一般造价高昂，并不是所有企业都会采用的，属于奢饰品，所以一般情况下，大家只能退而求其次在线上环境进行压测，然后进行有效的优化。

历

史踩过的坑

是不是只要压测过，并且优化后就可以高枕无忧了呢。答案一定是否定的，压测只能从一个维度粗略的看下系统的性能问题，并不能覆盖全部。所以我们还要从其他维度再次审视下我们的系统哪里可能还会存在风险。

一个比较常用的方式是回顾“错题本”，爱读历史的人都知道，中华历史几千年，各朝各代，循环往复，都有着很相似的经历，这个朝代灭亡的原因，一定是在其他朝代出现过。所以才会有“鉴以往可以知未来”这样的说法。这种思维应用在我们这里，那就是要把历史上所有出现过线上问题的地方都记录下来，分析清楚背后的原因，并且要举一反三，看看目前系统里还有哪些相似的隐患，要如何预防，这也是从另外一个维度来审视我们的系统还存在哪些隐患的地方。

做

预案

经过前面几个阶段，我们做了大量历史事故以及同行业的可能发生隐患的地方，那么其中有一部分问题是可以短期通过一定技术手段进行解决的。还有一部分问题是短期内无法快速解决的，那么针对这种问题，我们要提前做好预案，

所谓的“预案”就是提前准备好，如果某一事件发生，我们应该如何响应。

这里就是真正体现水平的地方，备战大促就跟将军带领士兵作战一样，将军一定要提前想好对方可能出什么样的招数，我们要如何应对，这样才能在战场上取得主动优势，战胜的可能性才会大大提高。

封

版

准备大促，最后一个要做的地方就是封版，一般至少提前1-2个周。这样做是尽可能保证大促期间系统是稳定的，除非有紧急情况，否则尽量不动生产系统，大促期间发版一个是风险很大，另外是人在高压下也很容易出错，大家都是凡人。

说了这么多也只是粗略的聊了下，备战大促应该准备的几个点，上面提到的每一点都有大量的细节待确认、待优化。就跟上学考试一样，不到进去考场前一刻，永远觉得还是有些知识点没有复习到位。

--完--