如何完美进行大促保障(一)

每年的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)按照业务优先级,给系统功能添加降级能力,紧急情况下进行降级,丢车保帅。

监控和预警

系统的关键链路,关键指标,必须要有监控,否则我们就是瞎子,对系统的运行情况无从得知。

有监控则必须要设置预警,达到设定的阈值,自动进行通知,靠人工时刻盯盘是不可行的。

限流和降级

系统的承载能力是有限的,如果有超出保障目标之外的流量过来,风险就很高,限流能力是必须要有的。

降级能力:按照业务优先级,给功能模块添加降级能力,必要的时候进行降级。

四、系统预案

预案就是对于突发情况的应对处理,所谓有备无患,预防执行时机和执行动作一定要清晰明确,发生紧急情况时,无需再思考解决方案,按照执行步骤来操作。

系统预案要完善,大促期间封网无法执行线上任何操作,预案是进行线上操作的唯一入口。

预案一般分为两类: 前置预案,紧急预案

前置预案

比如内存释放,磁盘清理,开关/限流操作等大促之前的前置工作,业务配置开关的关闭等。

紧急预案

大促期间发生紧急问题时的执行的预案,限流调整,系统功能降级等,以及一些预知到可能会发生的情况的应对操作。

预案演练

所有预案必须进行演练,没有演练的预案都可能有风险的

预案恢复

大促结束后,有些预案需要进行恢复

全链路压测相关的内容,下篇再进行讨论。

稀土掘金
我还没有学会写个人说明!
下一篇

PDF转换库 WeasyPrint 使用指南

你也可能喜欢

评论已经被关闭。

插入图片