本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！
最近几年大型电商网站如淘宝、天猫、京东、拼多多愈战愈烈。激战正酣怎么敢在大促期间出现故障呢！
这不仅带来经济上的损失，很可能一不小心掉出电商的第一梯队。 这些电商平台在大促前期、中期、后期做了哪些工作呢！才能保障大促如此平稳进行
接下来我们一起分享一下，自己在某平台工作中经历三次618二次11.11备战和督战。
大促前： 大促开始前都会有一个备战启动会,需要进行宣誓。感觉仪式感还是比较强的,有了宣誓大家都会感到沉甸甸的责任。
接下来各部门中各个业务线需要做的就是为大促做各种技改和整理预案,印象比较深刻的是核心系统需要交叉review大促预案,本身业务线都会配有架构师我们比较幸运配备的亚马逊过来的资深架构师。
以下是我经历过几次备战和实战后总结的一些要点。
简单的说“三预、三限、三降”。
三预
1.预警
大促期间预警一定要准并且监控面板一定要有全流程监控。虽然大促期间都是7*24值班通过监控面板进行系统监控,但是难免会有一些不明显抖动比如超时偶尔超时监控中根本体现不出来，我们一般都需要配置TP99、TP999超时预警和可用率预警。通过预警需要迅速定位问题，大促期间查询日志确定问题速度太慢并且日志也非常。
预警出现了怎么解决，这时候就需要我们熟悉系统和非常熟悉紧急预案。预警如果在紧急预案的case中那么对于的case就会有对应的操作，如果预警没有在紧急预案中你就需要通过对系统业务的判断决定是否有影响。(大多数情况都会自动降级方案)
经历：预警到手机没电，电话和短信一直不断。那是因为预警设置的不合理，果断调整预警。大促期间重要预警调整需要报备。
2.预扩容
系统经历半年有可能多半业务叠加，系统的性能很难维持到上次大促前的性能指标。这个时候我们必须要进行压测，压测需要注意的首先不能影响生产环境其次压测不能失真比如生产环境100台服务器你用1台服务器进行压测实验很明显失真。
经历：我们为了节省成本就这么干过发现失真非常严重，导致我们提供给上游的TP99、TP999指标达不到。造成的后果是上游系统不断会有超时情况出现。
3.预热
现在的大促都已经有了预热环节，预热环节可以使我们系统对缓存数据更好预热。不过我们系统预热的数据可能不止某几个sku或某几个品类。同时还需要我们进行系统中全量数据的预热，否则会拖慢我们系统甚至会宕机。
经历：有个比较冷门品类数量并不到当时没有考虑到进行缓存预热，当时大促当前业务方临时调整价格导致流量暴涨还好是查询,当时峰值大几千的QPS由于我们从库比较多平稳度过。(数据库绝大多数都是双机房且每个机房都需要高可用，也就是至少需要4个从库）
先写到这里看看反馈如何？大家觉得还不错的帮忙点个赞呗！
