大流量活动技术保障方案和执行流程

大流量活动预案

互联网型业务活动技术准备方案参考实践模型

乱语

又要搞活动了。业务人员讲不清技术，技术人员忽略业务。但总还得有人办事。现在的人好多事好多路讲不明白、走不明白。技术和技术管理如果非要区分你我，那应该反思是不是我们的能力不够。回到技术，前人栽树后人乘凉，前人犯过的错后人应该引以为戒，至少应该吸取一些经验教训，这样才能站在巨人的肩膀上，到此一游。至此，综合京东技术师者和一个互联网前辈的文章，（也引用了一些其他博客的图，但是时间太久忘记了出处，原作者看到请见谅）更加贴合实际的整理了如下活动预案模板，尤其是大型互联网活动可以参考做技术活动前的准备。
其中包括活动流量的评估、检查、复盘跟踪等一系列流程。参见如下：

背景

大流量活动的特性是生命周期短，推广资源集中，突增流量多，对系统负载有较大的挑战，可能会对现有业务产生冲击。 简单来说我们能做的是，在有大流量活动上线之前我们要做好提前准备，提前预估容量，做好扩容准备，做好应急预案。在大活动之前每个项目分别去整理自己的依赖关系和计划，技术发起人负责通知到相应的技术组。我整理出以下方法和步骤，尽力为每次活动做保障。

一、识别保障范围

• 识别保障优先级
  确定本次活动的边界范围，哪些业务是这次活动核心链路上的业务，以及业务的优先级。当问题发生时，明确要保障的业务的优先级。

• 业务压测
  在活动上线之前，确保业务对应的服务已完成压测，限流扩容等方案都做到有数据可依。

二、业务量预估及检查（容量预估扩容降级）

• 服务定制
  针对于大流量的活动，我们可以根据活动进行一些定制，比如抢购活动，可以针对活动去定制化的进行流量隔离设计，服务隔离设计，业务隔离设计等。
• 容量预估和扩容
  在确认为大流量的活动上线前需要对活动做容量预估，预估总用户量有多少，用户同时参与的可能峰值是多少？确认后评估系统能力是否能够支撑，如果不能，进行优化或扩容。评估系统时需要考虑系统本身以及支撑系统的服务的承载量。可以基于历史活动数据以及现有用户数去评估业务链路需要的资源量。比如：服务器部署的实例、缓存大小、数据库空间以及性能、连接池等。
  其次，最好还是基于历史数据和活动前的营销效果，预估本次的量为现在的多少倍。在流量入口点可以根据倍数做实例扩容升级，但是对于链路上的其他服务，其实没有必要一拍脑门子全部扩容200台。根据代码分析和调用堆栈分析，梳理出对下游服务的调用顺序和调用次数，根据调用比例关系做相应的扩容准备。（参考美团CAT实现，https://tech.meituan.com/2016/09/28/stress-test-before-promotion.html）
  
• 降级
  服务降级需要和产品侧提前沟通确认。当应用访问遇到高峰时，超出了应用所能处理的最大能力时，为了保证整个应用的安全可用，可以进行降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降到一个安全的水平。
  降级服务可以从功能和用户两个维度实现：
  1、功能降级：可以在开发阶段提前设计好降级预案，通过手动来触发。例如：抢购优惠券服务，后台设计了一个降级开关，当开关打开时，会直接显示优惠券已抢完。流量不会进入后台服务和数据库。
  2、用户降级：根据自定的策略实现，例如可以直接抛弃用户的请求。例如1中功能降级的开关或是系统的直接拒绝限流。
• 限流
  根据系统和接口的实际负载能力，做好限流防护。限流是一个系统最后的防护，可以在万般无奈的情况下，保留系统的最后一丝喘息的机会。同时可以结合降级去做一些起死回生的降级方案或做到故障转移。例如在大流量突发情况下把feed社区的服务打垮，这时候只要网关层不垮掉，可以用nginx+lua缓存首页的方式做到服务产品级别的降级，来争取短暂的恢复时间。

三、预案整理及业预案演练

兜底方案，万一服务因为某些情况表现异常时，做好最坏的兜底策略。可以从如下角度考虑：

• 服务的高可用
• 业务&服务降级
• 弹性扩容预案

四、监控及报警

在每次活动之前，提前在grafana或其他工具中配置好对应服务的相关数据监控，保证监控的实时准确性，相关监控尽量做到一个看板中，可以从以下两个角度设置：

• 存活监控（存活状态出现问题，一定第一时间知道才行）
  • IP
  • 端口
  • 服务
• 状态监控
  • CPU使用率
  • 内存占用比例
  • 磁盘IO
  • 接口请求数量
  • 接口RT

五、值班

确保线上报警可以第一时间响应，如有异常，按照预案处理。活动开始前，相关业务及研发人员最好组织统一作战室，观察活动进行，确保活动稳定时，再解散。技术侧发起时，则由本次技术负责人筹备。

六、技术复盘

每次活动中，要保证服务的数据准确的记录下来，以便进行技术复盘，同时为下一次活动提供数据素材。以及流量回放时有据可依。
技术复盘时，可以分析本次活动中的不足点，以及觉得很好的地方，进行归纳总结。

写在最后

6步备战，大流量活动是一个定频的行为，不能每次都从零开始。用坚持迭代和优化，来不断完善我们的流程和架构。

附录（重点，操作步骤）

每次活动前，请拷贝如下三个表单，完成功能操作记录。