电商的稳定性是一个很严肃而且很值钱的话题，尤其是大促时候的稳定性更是无比的重要。我参与大促次数跟老江湖比还是太嫩，只是借此文章做一个这阶段的总结，为以后的大促稳定性做基石。
稳定性最关注的就是三点—“新”、“先”、“细”。
先说新，每次大促一定要对新的组织、新的业务、新的技术要了如指掌，并且从他们中挖掘到可能会给大促带来不稳定性的元素，举两个例子：
1）本次大促出了小程序，那么这种H5的小程序安全性是否可以得到保证？会不会影响到大促安全？
2）本次大促集团提出“下沉市场”，即业务也会考虑三线以下的城市及农村，那么这样以来，可能单笔订单金额会下降，但是GMV又要稳定一个上升的局面，所以订单数就会大幅度增加。而现在已有的吞吐能力应付大量的订单，势必会延长高峰时间，延长1~2分钟还则罢了，要是延长10分钟呢？20分钟呢？系统在这样高水位的压力下能顶得住么？
再说说“先”，“先”就是要在大促前做的准备工作。
技术是可以解决问题的，但是技术也有一定的局限性，比如人手不足，比如时间紧迫，比如成本紧张。那么遇到高难度复杂性的挑战，单纯的靠技术肯定会就比较吃力了，那么可能这个时候就要“业务+管理”一起参与进来，比如购物车，本来购物车是可以展示40个商品，但是大促期间购物车模块压力过大，这个时候我们需要对其暂时做降级，比如展示25个，反正用户手机屏幕就那么大，他手指头划一下也不会有太差的用户体验，就这样我们就用最小的代价也获得了相对不错的结果。
定期回溯，其实每一次大促到双十一都会有很多的问题，这些问题在review会议上的时候，虽然提出了action，但是其实很多都没有改进，这一点要“往前看”，将那些“云action”彻底落地。
最后说“细”，大促稳定性说白了，其实最根本的就是四个词八个字—“容量、预案、预热、限流”。基本上做到这四点，大促就不会翻大车。
- 容量：要事前准确评估流量和承受能力，准确的评估可以降低成本。那么这个时候就需要算对机器的容量，也要算对应用的容量。因为随着业务的迭代，机器性能的退化必然导致系统能力退化，这一点就需要单独链路压测，摸好自己的水位，但是这里引申出一个压测的方式方法，比如某个应用可以接受HTTPS请求和RPC请求，但是HTTPS请求占大头，但是压测的时候做得请求只有RPC类型的，这样得出的系统负载能力肯定不对，因为HTTPS有鉴权和协议转换等等步骤，实际的负载能力会远远低于压测出来的值，那么这个值拿去大促，后果可想而知；
- 预案：预案是大促的保命草，我们说的预案既有提前预案也有止血预案，止血预案一般来说都是迫不得已的时候才拿出来使用，而且可能需要总裁级别的领导批准方可通行。而提前预案要在链路压测的时候提前验证，通过压测确认预案的有效性，毕竟过了一年的预案从灰尘里翻出来，谁都不敢用；
- 预热：预热有两个对象，一个是预热应用另一个是预热数据，做好了数据预热，整个链路都会变得精简，所以每次大促前热点商家、爆款商品等大量访问的数据都必须预热到位；
- 数据治理：这里插播一句数据治理，数据如果一直不精简，那么预热的数据就会越来越多，预热的环节就会消耗大量的时间。数据治理前要先全量备份，然后跟业务方讨论历史数据是保留“30天”还是“60天”；
- 限流：限流不是一层的，而是多层的。限流限什么？限QPS、用户数、线程数、资源使用率。这里注意新应用，因为新应用跟注重的是作用而不是安全，所以一定要注意新应用的限流方案；
