重点活动保障流程

经过多次重点活动保障，特总结以下保障流程。用于活动保障参考

1. 准备阶段

1.1.1 梳理业务流程图以及系统依赖图

梳理业务流程图的目的是用来明确本次活动的保障范围，以及在本次活动可能会存在的短板，并且作为本次活动保障的一个全局视角

重点活动的业务有可能会涉及多条业务线，如一次团购，涉及到多个入口，以及多个线条等

流程图应该包括主要的三个点，1. 此次活动的入口，2.从业务入口到业务完结所涉及到的所有中间件以及三方平台

除了以上内容外，以下两个关键点也需要关注

1. 除了活动当时的内容外，还有没有其他爆点，比如宣发时间，宣发的平台也需要关注
2. 活动结束后是否还有高峰期，高峰期包括流量高峰以及业务高峰，如数专销售期结束后，免费时间点，或者是咪咕汇结束后的内容分发保障。

1.1.2 预估QPS

QPS 可根据历史中的相似活动进行参考，可以由业务方预估本次活动的量级别。业务方会更清楚此次活动的投放渠道，当前活跃用户量，以及日活等数据。业务方应该给出的数据为：预估的各个业务的最大人数
如果有历史数据，整理出历史数据中的峰值（如果没有，应该是最近时间段内的峰值，或者是最近运营侧策划的相关活动）
根据人数

1.1.3 梳理业务流程中的接口

根据1.1 中梳理的业务流程图，对流程图中的接口进行梳理，并根据往此接口以及本次预估的QPS ，得到本次接口的目标QPS ，梳理的结果应如下图所列出的内容。

表格一： 内部接口

场景	接口	接口描述	所属服务	三方依赖	历史峰值	本次目标值	总限流值	varnish	降级策略	压测结果
打开app首页	/index	首页数据	card-service	发布平台	5362	53620	1000	否	无	qps:2000，响应:65ms，压测值:2200/100 ，压测id
打开活动页	/active/111	获取活动信息	a ctvie-service	无	5362	53620	无	是	接口前置	qps:2000，响应:65ms，压测值:2200/100 ，压测id

表格二：三方接口

uri	服务	接口说明	三方接口	三方平台	目标值	压测值	内部接口是否有缓存	24日压测结果	压测截图
/user/loging	user-service	用户登录	/user/check	登陆平台	2000	2400	否	QPS2058 ,压测编号5681

1.1.4 确认关键时间点

由运营人员给出一个活动的时间清单，应该包括宣传时间点，开始是几点
根据时间点需要倒排出我们的时间点，具体包括

1. 首轮压测截止时间
2. 首次优化时间点
3. 基础服务扩容完成时间点
4. 需求冻结时间点

另外，还需要一个关键时间点，用做活动当天的关键操作，此表格一个是用做备忘，一个是用于提前安排人力

时间点	操作内容
14号21：10	找到业务部门，拿到业务数据id 灯
14号21：12	检查是否收到，通过测试环境进行验证
14号23：35	进行紧急预案等的配置

1.1.5 执行压测

压测需要提前与三方确认压测计划，并明确一个压测的时间点，在计划时间进行压测。
压测可能会存在几轮，按照如下方式进行：

1. 单接口单容器的压测，这个压测用于预估这个接口的性能
2. 正式环境的压测，用于评估整个链路的性能
3. 历史数据回放，或者是多接口的同时压测，这种压测相对来说能够预估整个业务的性能

需要注意的是压测时产生的脏数据不应该污染正式环境的数据，比如上报数据等。

1.1.6 进行优化及降级策略配置

优化的方案按照具体的场景进行优化，优化时应考虑带来的影响，一般来说对代码的优化应该慎重，一般情况来说改动到正式活动的时间不是很充足，改动代码的风险会比较大
另外的包括扩容、等也属于优化方案
对不能优化的内容可以考虑降级策略，降级可以是在每个网络节点的，如app 的降级、n g的降级、熔断等。
这个阶段需要把表格一种的限流、降级策略补充完整

1.1.7 服务器节点性能梳理

1.7.1 梳理并整理出依赖的中间件的ip 以及最大链接数， 最大链接数往往决定着这个微服务的能够扩容的最大容器数量

1.7.2 梳理出这次所涉及到的微服务，并整理出在整个集群中所能允许的最大数量，最终的表格如下：

微服务	中间件	中间件ip	最大链接数
aaa-service	mysql		500
	redis		500
bbb-service	无

微服务	当前pod数量	最大允许数量
aaa-service	20	100
b b b-service	20	无限制

1.1.8 监控配置

监控的配置应该有两方面。

一个是业务数据的监控，如累计下单总量，关键页面的PV，UV,累计试听次数等，具体的监控应根据活动的属性来配置，监控的内容应该能覆盖核心的指标，其他内容不留在监控面板中。

另外一个是系统负载的监控，应该包括中间件、微服务的系统负载，jetty连接池,中间件连接池等能直接反应系统状况的图。

1.1.9 梳理应急预案

应急预案应该需要明确预案中每一步的操作时间
如，对于需要前置的数据应该明确前置数据的准备时间或者是准备方案

应急预案需要结合业务场景,明确操作场景、操作执行步骤、操作执行人、操作确认人 ,具体表格参考下方

一级分类	二级分类	应急场景启动条件	业务应急策略	业务策略 负责人	预警条件	应急措施	业务影响	执行时间	技术应急方案负责人	应急方案 执行人	应急方案 授权人

1.1.10 演练

演练内容应该覆盖到应急预案中的所有点。

2 活动间

活动期间首先需要按照梳理的表格时间点进行关键的操作，如已经预案相关内容的准备，如前置报文等。

然后，各个组的运维、开发需重点关注日志，监控情况，提前进行预警以及数据的准备。

3 活动结束

活动结束后需要继续保障后续的内容，如分发，业务处理等

还有就是数据的收集，数据收集用做两方面，一方面是汇报材料，另外一方面是未来相似活动的数据

收集的内容应该包括：

1. 接口的峰值(对外提供接口api，调用其他的接口remote数量，以及内部自己关心的接口service数量等)
2. 业务数据（下单量、PV，UV）、
3. 中间件（连接池使用率）
4. 服务器资源的利用率

---

• 分类： 主业
• 标签： 无标签