正文约 2500 字，阅读大约需要 7 分钟
运营同学搞活动，最不希望看到的，恐怕就是系统扑街了。这种事情似乎没什么办法，公司程序员水平太次，总拖后腿，我能怎么办？我也很为难啊。其实，这事未必都是程序员的锅，作为运营同学，要想避免系统扑街也是有方法可以遵循的。
那么常见的活动扑街都有哪些表现呢？通常，按照技术的专业术语来讲，有 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 ]
识别二维码获取更多干货文章 ↓↓↓
