1月4日，估计不少人刷到了“汉堡王崩了”的热搜。网友们表示，页面要么卡顿加载不出来，要么直接闪退，甚至出现定位莫名跳到北京的情况。
事情起因是汉堡王官宣新代言人田栩宁，今天上午10点正式上线他的联名元旦礼盒套餐，全国就限量6万份，售价69.9元，还带亚克力挂件、小卡这些粉丝喜欢的周边。结果离开售还有5分钟，大量粉丝就提前蹲守在官方APP、微信小程序和支付宝端口，等着抢购。瞬时涌入的用户太多，直接把三个平台的系统都给冲垮了，线上点餐功能完全停滞，这个状态还持续了超一个小时。
对此，官方发了第一次道歉声明，承认是“瞬时访问量巨大，系统承载能力不足”，正在紧急修复；没过一个小时又发了第二次道歉，专门针对没买到套餐的用户，承诺近期会在天猫旗舰店开放同款周边的预订。
说起来，“因活动火爆导致崩溃”这种事情，在很多品牌身上都出现过。
最核心的原因，是流量预判失误，系统承载能力没跟上。我们可以把系统看做一个公路，平时车流量就在那了，怎么样都没问题，但突然来了上百倍的车流量，公路肯定会堵死，甚至是塌陷。而汉堡王这次联名套餐限量6万份，粉丝为了抢周边肯定会扎堆操作，每秒可能有成千上万的请求涌向服务器，自然就扛不住了。
再者就是技术架构和容量规划的问题。很多餐饮品牌的线上系统用的是比较传统的架构，就像“独木桥”一样，所有请求都要挤一条通道。正常情况下没问题，但遇到高并发场景就很脆弱。专业点说，就是没采用分布式架构、异步消息队列这些能分流压力的技术，也没做好数据库读写分离和缓存优化。而且可能在活动前，没有做压力测试，比如模拟几万人同时抢购的场景，看看系统在极限状态下会不会出问题。
还有就是应急响应机制不完善。从系统崩到基本恢复，用了一个多小时。这期间很多用户刷不出页面、找不着客服、投诉无门。说明运维那边可能缺少实时监控和预警机制——比如服务器压力一到临界点就该自动告警、触发扩容预案，哪怕不能完全避免崩溃，也能尽快缓解问题，减少用户干等的时间。
作为普通用户，咱们无非是图个开心才去抢购，结果热情全耗在刷新和闪退上，体验确实没那么完美。虽然汉堡王后续道了歉、也承诺补货周边，但还是有不少人因为点不了餐，干脆转头去了别家。
希望品牌以后搞活动前，真得把系统测试做好，别让大家的期待，最后败给了一个总在转圈圈的页面。
热门跟贴