背景：
在阿里经历过3年双11大促，从事云相关工作之后，发现经常会有各类云上客户面临大促护航需求，借此文总结下常规的大促备战都需要做些什么，我们需要从哪些方面入手去备战，尽量避免遗漏，做到大促平稳顺滑。
大促备战该从何入手，具体做些什么
1）第一阶段：业务梳理，架构整合，流量预估
1.1 业务梳理
在备战大促的过程中，我们首先需要对我们的整套系统所有应用进行梳理，了解哪些应用会面临大促的压力，哪些与大促无关；哪些是核心应用，需要重点保障，哪些是非核心应用，可接受降级或短时间不可用；理清这些应用之间的关联关系，有哪些上下游依赖，中间件等；
1.2 架构整合
一套在线系统一般都是由多个团队负责的，包含基础在线服务、离线数据、基础中间件、网络等；但是在大促备战过程中需要整理出整体的业务架构大图(可分成在线离线)，包含各个应用，上下游依赖，中间件，所在的网络环境，带宽使用量，负载均衡设备，数据库，在线数据采集、订阅，离线数据处理等所有环节；只有把整个架构都搞清楚了，才能针对性的进行风险评估、容量规划、预案准备；
如果只规划单个的容量，忽略了上下游以及其它依赖的承载能力，整个系统的任何一个环节出了问题，都会最终传导到系统入口，导致服务异常；
1.3 流量预估
在大促准备初始阶段，都需要根据以往的流量情况以及运营的推广力度来评估此次大促的流量峰值；然后根据峰值流量进行压测，明确当前系统的承载能力，准备好优化和扩容的方案；
如果由于业务发展不规律，流量增长非线性，没有有效的历史数据来协助预估的话，那么也需要有一个理想承载能力的预估，以此作为容量规划的目标；
峰值的流量来源一般需要考虑几个方向：
1）由于秒杀、红包活动、整点峰值等导致的自然流量高峰；
2）由于运营主动push消息导致的流量瞬时高峰；
建议：涉及到主动push的机制，建议一般都设置推送步长，逐步推送到峰值，避免瞬时流量高峰导致的一系列类似缓存失效，类脉冲攻击流量导致连接异常等情况；
3）由于上游传导过来的峰值流量；
2）压测&优化&扩容
2.1 压测准备
压测是整个大促备战过程中最核心重要的环节，贯穿整个备战的始末，需要通过压测才能摸清系统的承载能力，然后不断优化扩容，重复压测直到达到预估的承载能力。
压测简单分为线下压测和在线压测：
1)线下压测
指未接入真实流量的线下环境，保持与生产一致的机器比例，可以通过tcpcopy方式复制生产流量，只可取得链路瓶颈和单模块的压力，非主力压测方式，因为环境和生产不一样，网络环境、上下游依赖等都不一样，压测出来的结果也会有差异；
2)在线压测
在线压测是指直接使用生产系统进行压测，能保证压测结果即是最终的系统承载能力；如果系统有充分容灾能力，可以切走一个可用区或region流量，然后再直接在生产系统上进行压力测试；如果没有足够的冗余，也可以选择在夜间流量地缝时进行，将可能的影响降到最低；
2.2 优化&扩容
一旦通过压测发现系统性能瓶颈，优先考虑能否进行优化，根据压测瓶颈时系统资源使用情况，充分利用内存分配优化、线程池调整、锁机制优化、异步化等方式进行业务优化。次之再考虑扩容方案，云上业务可考虑ESS或提前预约所需资源或配置升级。优化和扩容结合压测反复进行；直到系统可承载能力最终达到业务预期；
2.3 预案
预案不仅是大促不可缺少的一环，日常系统运维过程中其实也是必不可少；大促预案分为前置预案和应急预案；
1) 前置预案
指在大促峰值流量之前执行的提前降级预案，无损或者预期范围内的。例如提前关闭写io频繁的日志写入，混部场景中调整调度策略避免调度到高压模块，提前关闭一些生产高消耗的策略等；
2）紧急预案
是指在流量超出预期或者链路中单个应用性能异常等情况下执行的应急预案，旨在快速恢复系统服务能力；入口的限流，应用策略降级等，可能的情况下优先采用无损的降级预案；
2.4 大促中
大促实际备战过程中，需注意:
1）提前预案的操作，设定紧急预案执行的决策人、执行人和double check负责人，尽量不进行非预期的操作；
2）峰值时段流量、系统表现相关数据采集；
3）特别注意主动的数据推送，活动安排等导致的流量高峰，注意调整推送步长；
4）系统各种大小异常情况信息采集
相信做好了压测和容量准备，模拟了各种压测和问题场景，大促肯定能平稳过渡；
3）总结&沉淀
每次大促都是一次难得的经历，不管是对系统还是对开发运维人员，做好总结和沉淀能够对后期日常的系统维护以及以后的大促提供非常宝贵的经验；
1) 压测方案的沉淀；
2) 系统优化方案的沉淀；
3) 演练过和执行过的预案及场景整理；
4) 峰值流量、对应系统资源消耗及扩容数据收集；
5) 其它相关业务重要数据沉淀
