运营同学如何防止活动中系统扑街 ?

运营同学搞活动,最不希望看到的,恐怕就是系统扑街了。这种事情似乎没什么办法,公司程序员水平太次,总拖后腿,我能怎么办?我也很为难啊。其实,这事未必都是程序员的锅,作为运营同学,要想避免系统扑街也是有方法可以遵循的。

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

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

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

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

那么,作为运营同学,对于这些常见的错误,我们能做些什么呢?下面,按照错误的严重级别,我们分别进行讲解。

1、50x 应对方案

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

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

那我们能做什么呢?那就是,预估活动流量,提前周知开发和运维以及其他相关人员。如果不好预估,那么可以让相关技术同学根据以往活动的经验,在预算允许的情况下,尽量为系统多预留一些能力。比如加机器,提升带宽等。很多时候不是机器不行,而是出口带宽受限。比如调用微信的 api 慢,往往是自身机器出口带宽不够,而不是微信的服务器慢。提前多留点余地总比系统挂掉强。接不住的流量没有任何意义,反而会影响品牌口碑。

2、40x 应对方案

对于这类错误,往往是查找文档出了问题,常见的原因可能是服务器权限问题导致 403,路径配置错误或者文件没有发布成功导致 404。那么运营同学尤其要注意的是,在一些可配置的地方粘贴的 URL 是否符合规范,比如是否包含特殊字符,参数的 ?和 & 是否使用正确等等。有些时候仅仅是因为链接配置错误,才导致的 404,这完全是可以避免的。

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

3、响应慢的应对方案

系统响应慢往往是 50x 的前兆,如果长时间无响应,这个接口的后端进程就可能被杀死,那么这次客户端的网络请求,就无法响应了。归根结底,还是系统能力与承接流量不匹配。那么,除了前面讲到的提前加机器,加带宽,还有没有什么可以做的呢?当然有。

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

对于活动的节奏,往往也是有弹性空间的。比如公众号推送,可以选择分组推送,用户对于自己比别人收到消息早点晚点,是没什么感知的。稍微分分组,就可以有效缓解系统压力。还有就是推送的图文消息中,链接到自己系统的入口放在哪个位置也很关键,比如放在页面底部,那在用户浏览页面的时候,就已经在时间上拉开了差距,分散了系统的压力。

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

对于这部分,我们能做的就是考虑下这些定时任务的需求,能否不在 00:00 整,比如凌晨 02:00 执行是否可行?这样至少能把我们内部的压力分散开来。然后才有资源去承接外部的流量压力。

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

4、躲不开的流量

前面的方案都是分散系统的整体流量,那么对于已经来了的流量,有没有什么办法呢?前面说过,一定程度内可以加机器硬抗,但是最好提前有准备,不然可能扩容搞定了,瞬间的流量高峰已经过去了。

那么对于已经进入我们页面的用户来说,我们还可以通过修改交互的方式,使消耗系统资源多的操作滞后。比如页面如果一进来就直接操作数据库查询一个大的排行榜,就很耗资源。当然,这种情况可以用缓存来解决。但是有些情况是很难缓存,比如查银行余额,积分余额等。这些资产相关往往要求高度的实时性,那么我们能做的,就只有设计一个可以拉开流量的交互。

典型的例子是,活动逻辑很重,为了拉低流量高峰,在活动页前面加前导页,做氛围图和活动说明,然后增加按钮“立即参与”,然后才去逻辑更重的活动页。这样虽然稍微有损用户体验,但是也比高峰时候页面卡在那里强。由于每个人浏览和点击的时间不一样,这种方法可以有效削峰。

同理,对于实时性要求不高的业务逻辑,可以异步化,稍微晚一点更新也没关系。这样就可以用定时任务去处理,哪怕时间间隔短一点,也是按照队列井然有序在处理,不会一下子吃掉系统的资源。对于抢购等业务,更是要强制设计成排队机制,不管来多少人,都不做太重的业务逻辑,先丢到队列里去等待,我们只选部分人继续后面的业务逻辑。这些内容又很大程度上依赖系统架构师的工作,这里就不讨论了。

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

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

  1. 整体活动节奏周知,事前预防;
  2. 检查配置信息,是否人为错误;
  3. 修改活动规则,拉长活动时间,分组推送;
  4. 修改交互,逻辑后置;
  5. 提前计划事中应急方案;
  6. 事后复盘,总结教训。
本文由 新媒体之家 作者: 姬小光 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
3

发表评论