每年的618,、双11、双12等大促活动是一场电商圈的狂欢，如何应对大促期间暴涨的流量，如何保障系统的稳定性，是一个值得思考的问题，下面我将自己经历的几年大促保障工作，进行了简单的总结和沉淀，供大家参考，从如下6个方面展开讨论：
1，明确保障目标
2，封网/需求冻结
3，链路梳理和改造
4，系统预案
5，全链路压测
6，大促作战
下篇： 如何完美进行大促保障（二）
一、明确保障目标
对于一次大促保障来说，首先需要明确的是系统保障的目标，如要保障的流量等，明确了这个目标后，后续的保障工作都是围绕这个目标展开的，主要分为：业务目标，技术目标。
业务目标
支撑订单XXX亿/天，支撑揽件XXX万/天
技术目标
系统100%可用，无P1/P2故障。
峰值QPS：订单 XXX，登录 XXX，支付 XXX（按照自己公司业务场景来定）
系统QPS如何确定？
不同行业的峰值场景不一样，电商行业可能在0点时，有大量订单产生。在我们物流行业0点时不会有订单暴涨。
1，业务方提供业务量，技术人员换算成QPS。
2，参考日常流量峰值翻2-3倍。这点仅供参考，行业特性不一样，结果又不一样，在电商行业双11大促下0点流量可能不符合这个规律。
二、封网/需求冻结
大促期间必须要封网，大促KO会议上要明确封网时间，封网期间禁止发布，大促结束后解封。
封网时间确定后，需要进行各域的需求收集和冻结，评估上线的风险。
三、链路梳理和改造
所有的系统都要进行评估，核心的业务链路都要进行梳理，有风险的地方都需要进行改造和优化。
如何识别无需保障的系统？
1，一般来说，系统挂掉，对业务无影响，对依赖系统无影响的可以不进行保障。
2，可以明确知道大促期间不会有任何形式的流量增长的，且日常运行稳定的系统，也可以不进行保障
3，系统挂掉，业务有容忍度，影响在可接受范围，且老板认可不保障造成的影响，也可以不保障。
链路图/部署图
每个域都要梳理出链路图，结合保障的qps目标进行拆解，那么自己域内的各链路qps应该就非常明确了，图里要清晰的标出各链路的qps，识别出有风险的链路，进行改造和优化。
不能掉以轻心，所有链路都要进行评估，即使再边缘的链路，也要考虑进来。
<TODO：这里补张链路示意图，用作参考>
PS：某些淘宝双11改地址服务没有抗住，翻车了。
改造和优化
系统链路和qps都明确后，可以先进行相应的优化和改造。列举几个常见的点：
1，高可用
通常来说高可用是首先要保证的，排除掉单点故障。但是在某些情况下高可用也要综合来看，我的理解是：不是所有的系统和组件都要做到高可用，如果高可用的成本非常非常高，且系统挂了后，能在短时间内恢复，且故障期间的业务有损是可接受的，可恢复的，则也可以接受非高可用。
2，缓存穿透/雪崩
可以将一些配置，基元数据等可以适当做一些本地缓存，定期刷新缓存。
3, 慢SQL
所有的慢SQL都要进行治理，无法改善的也需要明确影响。
4，限流和降级
1）系统入口需要增加限流，防止超出保障目标的流量击垮系统。
2）对于依赖的外部组件/系统，一定要确认其是否能承载相应的qps，必要的环节加上限流。
3）按照业务优先级，给系统功能添加降级能力，紧急情况下进行降级，丢车保帅。
监控和预警
系统的关键链路，关键指标，必须要有监控，否则我们就是瞎子，对系统的运行情况无从得知。
有监控则必须要设置预警，达到设定的阈值，自动进行通知，靠人工时刻盯盘是不可行的。
限流和降级
系统的承载能力是有限的，如果有超出保障目标之外的流量过来，风险就很高，限流能力是必须要有的。
降级能力：按照业务优先级，给功能模块添加降级能力，必要的时候进行降级。
四、系统预案
预案就是对于突发情况的应对处理，所谓有备无患，预防执行时机和执行动作一定要清晰明确，发生紧急情况时，无需再思考解决方案，按照执行步骤来操作。
系统预案要完善，大促期间封网无法执行线上任何操作，预案是进行线上操作的唯一入口。
预案一般分为两类： 前置预案，紧急预案
。
前置预案
比如内存释放，磁盘清理，开关/限流操作等大促之前的前置工作，业务配置开关的关闭等。
紧急预案
大促期间发生紧急问题时的执行的预案，限流调整，系统功能降级等，以及一些预知到可能会发生的情况的应对操作。
预案演练
所有预案必须进行演练，没有演练的预案都可能有风险的
预案恢复
大促结束后，有些预案需要进行恢复
全链路压测相关的内容，下篇再进行讨论。
