运营活动中，系统扑街怎么办?

那么常见的扑街活动有哪些表现呢？一般来说，根据技术专业术语，有40x和50x系列。我们在网站上经常看到的是“404页找不到”这样的提示。也许还有卡通和卖萌的文案，但本质上是一样的，就是系统找不到你要访问的页面。还有50x系列，会提示类似“哦，系统崩溃了~”，或者“系统很忙，请稍后再试一次”。意思是系统真的扑街崩溃了。稍微轻一点的，可能是页面长时间加载，部分或全部内容看不见。这说明系统的响应超时，太忙了。当然，这里要排除客户端的网络因素，也可能是网络太慢造成的。对于更复杂的网页，因为每个模块可能是单独加载的内容，所以有些内容可能是看不见的，也就是说，单个数据接口挂断，或者太忙，比如页面排名列表不能加载很长一段时间。那么，作为一名操作学生，我们能为这些常见的错误做些什么呢？下面，根据错误的严重程度，我们分别解释。No.1：50x应对方案首先，最严重的是50x系列，就是系统真的挂了。这种情况可能是操作和维护的锅，也可能是程序员的锅，导致系统结构不合理、代码不合理、机器性能不足、带宽不足等。排除程序错误的*伤，可以概括为“系统能力与流量不匹配”。也就是说，你的系统承受不了这么大的流量。我们都知道系统不能携带可以添加机器，但添加机器也有局限性，如临时扩展速度、多台机器数据同步等问题，流量达到一定数量级，不是添加机器可以解决的问题。那我们能做什么呢？也就是说，预估活动流量，提前了解开发、运维等相关人员。如果不容易估计，相关技术学生可以根据以往活动的经验，在预算允许的情况下，尽量为系统预留更多的能力，如增加机器、提高带宽等。大多数时候，并不是说机器不好，而是出口带宽有限。例如，呼叫微信的应用程序速度较慢，通常是因为自己的机器出口带宽不够，而不是微信的服务器速度较慢。提前留出更多的空间总比挂系统好。无法连接的流量毫无意义，但会影响品牌声誉。No.2：对于这类错误，40x响应方案往往是发现文档有问题。常见的原因可能是服务器权限问题导致403、路径配置错误或文件未发布成功导致404。因此，操作学生应特别注意粘贴在某些可配置位置的URL是否符合规范，如是否包含特殊字符和参数？和&是否正确使用等等。有时仅仅因为链接配置错误，就会导致404，这是完全可以避免的。另一种可能是开发兄弟发布失败，所以对于重要的活动，知道在线，无论有多忙，都必须亲自体验，不要因为别人的错误，影响他们的工作。No.3：响应缓慢的响应方案系统响应缓慢通常是50x的前兆。如果长时间没有响应，接口的后端过程可能会被杀死，那么客户端的网络请求就无法响应。归根结底，系统能力与承接流量不匹配。那么，除了前面提到的机器和带宽，还有什么可做的吗？当然有。如果经常出现这样的问题，必须要求开发和运维哥优化系统架构，优化程序代码，增加多级缓存等操作，提高系统的抗压能力。对于活动的节奏，通常也有一个灵活的空间，比如公共账户推送，你可以选择分组推送，用户比其他人早晚收到消息，没有感知。稍加分组，就能有效缓解系统压力。此外，在推送的图形新闻中，链接到系统入口的位置也非常关键。例如，在页面的底部，用户在浏览页面时打开了时间差距，分散了系统的压力。一些系统压力是由定时任务引起的，例如，一些“自动任务”经常在业务需求中每天的特定时间执行。对于日常定时任务，许多开发兄弟默认使用00:00这个时间设置，导致每天00:00系统负载处于高峰。而且运营活动也喜欢在这个时候，比如抢购双十一，支付尾款等等。这导致压力集中在一起，拖垮了自己。对于这一部分，我们所能做的就是考虑这些定时任务的需要，以及它们是否不在00:00整，比如凌晨02:00执行可行吗？这样，我们至少可以分散内部压力，然后有资源承受外部流量压力。还可以通过修改活动规则来分散压力。你可以在很小的时间内不要求每个人都在窗口抢购，而是稍微拉长活动节奏。比如连续签到打卡。No.4：流量前面的方案是分散系统的整体流量，那么对于已经到来的流量，有什么办法吗？前面说过，机器*抗可以在一定程度上添加，但最好提前做好准备，否则扩容可能会完成，瞬间流量高峰已经过去。所以对于已经进入我们页面的用户，我们也可以通过修改交互来滞后于消耗大量系统资源的操作。例如，如果页面一进来就直接操作数据库查询一个大排名列表，它将消耗资源。当然，这种情况可以通过缓存来解决，但有些情况很难缓存，如查银行余额、积分余额等。这些资产往往需要高度的实时性，所以我们所能做的就是设计一个交互，可以打开流量。典型的例子是，活动逻辑非常重。为了降低流量高峰，在活动页面前添加导向页面，做氛围图和活动描述，然后添加按钮“立即参与”，然后添加逻辑更重的活动页面。虽然对用户体验略有损害，但也比高峰时段页面卡在那里好。由于每个人浏览和点击的时间不同，这种方法可以有效地削减峰值。同样，对于实时性要求较低的业务逻辑，可以异步化，稍晚更新也没关系。这样，就可以用定时任务来处理。即使时间间隔稍短，也会按照队列有序处理，不会一下子吃掉系统资源。对于抢购等业务，需要强制设计成排队机制。不管来多少人，都不要做太重的业务逻辑。我们先把它扔到队列里等。我们只选择一些人继续以下业务逻辑。这些内容在很大程度上取决于系统架构师的工作，这里就不讨论了。最后，临时出了问题，还是赶紧去找开发哥、运维哥，千万不要犹豫。如果不提前制定即事应急计划，只能依靠技术人员的适应能力。然后通过活动回顾，总结各方的经验教训，避免下一场悲剧。综上所述，核心是以下六点：知道整体活动节奏，提前预防；检查配置信息，是否人为错误；修改活动规则，延长活动时间，分组推送；修改互动，逻辑背景；提前计划应急计划；回顾后，总结教训。怎么样，你学会了吗？