欢迎光临
我们一直在努力

做活动,系统扑街了,只能找开发?

12 做活动,系统扑街了,只能找开发?

 

 

运营同学搞活动,最不希望看到的,恐怕就是系统扑街了。这种事情似乎没什么办法,公司程序员水平太次,总拖后腿,我能怎么办?我也很为难啊。

 

其实,这事未必都是程序员的锅,作为运营同学,要想避免系统扑街也是有方法可以遵循的。

 

那么,常见的活动扑街都有哪些表现呢?

 

通常,按照技术的专业术语来讲,有 40x 及 50x 系列。我们在网站上经常能见到的,就是类似“404 页面找不到了”这种提示。可能还配有卡通和卖萌的文案,但是实质都一样,就是系统找不到你要访问的页面。

 

还有就是 50x 系列,会提示类似“啊哦,系统崩溃了~”,或者“系统繁忙,请稍后再试”。意思就是系统真的扑街了,崩溃了。

 

更轻量一点的,可能是页面长时间加载中,部分或者全部内容不可见。这说明系统的响应超时了,忙不过来了。当然,这里要排除客户端的网络因素,也可能是网络太慢导致。

 

对于比较复杂的网页来说,由于各个模块可能是分开加载的内容,所以也有可能部分内容不可见,即单个数据接口挂掉;或者忙不过来了,比如页面的一个排行榜长时间加载不出来。

 

那么,作为运营同学,对于这些常见的错误,我们能做些什么呢?

 

下面,按照错误的严重级别,我们分别进行讲解。

 

No.1:50x 应对方案

 

首先,最严重的莫过于 50x 系列了,就是系统真的挂了。

 

这种情况有可能是运维的锅,也可能是程序员的锅,导致系统架构不合理,代码不合理,或者机器性能不足,带宽不够等等。排除程序错误的硬伤,这些都可以概括为“系统能力与所承接的流量不匹配”;也就是说,你的系统承接不了这么大的流量。

 

我们都知道系统扛不住可以加机器,但是加机器也有局限性,比如临时扩充的速度,多台机器数据同步等问题。流量到了某个量级,就不是加机器能解决的问题了。

 

那我们能做什么呢?

 

预估活动流量,提前周知开发和运维以及其他相关人员。

 

如果不好预估,可以让相关技术同学根据以往活动的经验,在预算允许的情况下,尽量为系统多预留一些能力。比如加机器,提升带宽等。

 

很多时候不是机器不行,而是出口带宽受限,比如调用微信的 api 慢,往往是自身机器出口带宽不够,而不是微信的服务器慢。

 

提前多留点余地总比系统挂掉强,接不住的流量没有任何意义,反而会影响品牌口碑。

 

No.2:40x 应对方案

 

对于这类错误,往往是查找文档出了问题,常见的原因可能是服务器权限问题导致 403,路径配置错误或者文件没有发布成功导致 404。

 

运营同学尤其要注意的是,在一些可配置的地方粘贴的 URL 是否符合规范,比如是否包含特殊字符,参数“?”和“&”是否使用正确等等。

 

有些时候仅仅是因为链接配置错误,才导致 404,这完全是可以避免的。

 

还有种可能是开发哥发布失败,那么对于重要的活动,周知上线后,不管有多忙,一定要自己亲自体验一遍;不要因为别人的错误,影响了自己的工作

 

No.3:响应慢的应对方案

 

系统响应慢往往是 50x 的前兆,如果长时间无响应,这个接口的后端进程就可能被杀死,那么这次客户端的网络请求,就无法响应了。归根结底,还是系统能力与承接流量不匹配。

 

那么,除了前面讲到的提前加机器,加带宽,还有没有什么可以做的呢?

 

当然有。

 

如果这种问题经常出现,那么一定要提需求让开发和运维哥优化系统架构,优化程序代码,增加多级缓存等操作,提升系统的抗压能力。

 

活动的节奏,往往也是有弹性空间的。

 

比如公众号推送,可以选择分组推送,用户对于自己比别人收到消息早点晚点,是没什么感知的。稍微分分组,就可以有效缓解系统压力。

 

还有就是推送的图文消息中,链接到自己系统的入口放在哪个位置也很关键。比如放在页面底部,那在用户浏览页面的时候,就已经在时间上拉开了差距,分散了系统的压力。

 

有些系统压力,是定时任务造成的。

 

比如,业务需求中经常有些“自动任务”,在每天的特定时间执行。而对于每日的定时任务,许多开发哥会默认使用 00:00 这个时间设置,从而导致每天的 00:00 系统负载都处于高峰。而运营活动也喜欢在这个时间,比如双十一的抢购,付尾款等等。这就导致压力都集中在了一起,自己都把自己拖垮了。

 

对于这部分,我们能做的就是考虑下这些定时任务的需求,能否不在 00:00 整执行,在凌晨 02:00 执行是否可行?

 

这样至少能把我们内部的压力分散开来,才有资源去承接外部的流量压力。

 

通过修改活动规则也可以分散压力,可以不要求大家都在很小的时间窗口来抢购,而是稍微拉长一点活动节奏,比如连续签到打卡之类。

 

No.4:躲不开的流量

 

前面的方案都是分散系统的整体流量,那么对于已经来了的流量,有没有什么办法呢?

 

前面说过,一定程度内可以加机器硬抗。但是最好提前有准备,不然可能扩容搞定了,瞬间的流量高峰已经过去了。

 

那么对于已经进入我们页面的用户来说,我们还可以通过修改交互的方式,使消耗系统资源多的操作滞后。比如,页面如果一进来就直接操作数据库查询一个大的排行榜,就很耗资源。

 

当然,这种情况可以用缓存来解决,但是有些情况是很难缓存,比如:查银行余额、积分余额等。这些资产相关往往要求高度的实时性,那么我们能做的,就只有设计一个可以拉开流量的交互。

 

典型的例子是活动逻辑很重,为了拉低流量高峰,在活动页前面加前导页,做氛围图和活动说明,然后加按钮“立即参与”,才去逻辑更重的活动页。

 

这样虽然稍微有损用户体验,但是也比高峰时候页面卡在那里强。由于每个人浏览和点击的时间不一样,这种方法可以有效削峰。

 

同理,对于实时性要求不高的业务逻辑,可以异步化,稍微晚一点更新也没关系。这样就可以用定时任务去处理,哪怕时间间隔短一点,也是按照队列井然有序在处理,不会一下子吃掉系统的资源。

 

对于抢购等业务,更是要强制设计成排队机制,不管来多少人,都不做太重的业务逻辑;先丢到队列里去等待,我们只选部分人继续后面的业务逻辑。这些内容很大程度上依赖系统架构师的工作,这里就不讨论了。

 

最后,临时出了问题,还是赶紧去找开发哥、运维哥,千万别犹豫。事中的应急方案,如果没有提前制定,只能靠技术人员的应变能力了。事后再通过活动复盘,总结各方经验与教训,避免下次悲剧的发生。

 

总结一下,核心就是以下 6 点:

 

  1. 整体活动节奏周知,事前预防;
  2. 检查配置信息,是否人为错误;
  3. 修改活动规则,拉长活动时间,分组推送;
  4. 修改交互,逻辑后置;
  5. 提前计划事中应急方案;
  6. 事后复盘,总结教训。

 

怎么样,各位同学学会了吗?

 

作者:姬小光

微信公众号:姬小光(ID:hi-laser)

 

赞(0)
未经允许不得转载:电商之家 » 做活动,系统扑街了,只能找开发?

登录

找回密码

注册