腾讯八年春节保卫战：流量爆表宕机、现场应急开发，技术人上演最强“剧本杀”

流量爆表，平台出故障了，连带导致系统全方位崩盘，用户投诉蜂拥而至。

这是 2013 年的春节。作为腾讯基础架构部自研业务负责人，邹方明的第一目标是在故障发生时，快速查找原因并做出一个决策来恢复系统。系统宕机后，老板在办公室一言不发，业务同事们着急的不断发着消息，运维在旁边等待他放在键盘上的手指敲下指令，产品团队需要一个回复，好向外界发出一个通告，告知用户不必恐慌。

到底需要花多少时间去定位问题查找原因，还是干脆一刀切下去进行熔断自救？如果决定多花三分钟去查原因，三分钟一无所获，也相当于浪费了三分钟。这是一个权衡博弈的过程，他也不确定哪个方法最好。晚一秒就浪费一秒，这种压力他能一直感觉到，大家都指着他做出一个“要人命”一样的决定。

十三亿中国人的春节，通过微信拜年、抢红包已经成了大家的一种习惯。海量的用户请求，一年比一年高的峰值，考验着基础架构，也考验着技术人。就算只经历过一次这样的故障，多年之后，邹方明都会不断的在脑海里进行模拟，当年到底使用哪个方案能够最快的恢复服务，是不是能精准地找到某一个点然后重启这部分服务，在没有把握的情况下是否能做出更好的决定…

“当时的经历只能进行一次，我就做了这么一个决定，也不后悔了…”

每一年的春节，都是技术人的职业生涯生死战

2021 年，运维人又渡过了一个紧张的春节。这个春节，也注定要成为无数国人心中最难忘的记忆，不再边听着超市里的“恭喜发财”采购年货，往日丰盛的年夜饭变成了外卖，握手寒暄、线下聚会变成了云拜年、电子红包。

今年除夕，几十位腾讯基础架构部的技术人员在公司早早地吃完年夜饭后，就全员投入到了春节保卫战中。从 7 点“云年夜饭”开始，春节红包、朋友圈这种重要业务的流量会不断翻倍，运维人员需要根据值班手册，盯着数据看板查看监控数据，保证业务不出问题。重头戏一般是每年的除夕 12 点，这个峰值过去之后，基本上不需要再做什么动作。

移动互联网开始之后，就进入了社交媒体爆发的时代。2005 年，腾讯 QQ 用户正式突破 1000 万。2011 年，微信上线，短短两年后用户数就突破 3 亿。不管是体量还是用户活跃度都非常高，从这个时期开始，每年除夕都会迎来一个非常突出的流量高峰。

相对短视频平台、电商平台，腾讯这种社交软件，因为用户之间 N*N 的网状交互，挑战会更大。电商春节发红包是百万级别，而社交平台红包在亿级别。压力也是全方位的，如果有某一个点扛不住压力，这个地方引起的问题会不断影响其他地方，就有可能像多米诺骨牌一样，连带导致整个系统崩盘。

每年的流量峰值是不可预测的，但一旦出现这样的故障，在公司层面影响会很大，毕竟这些系统代表了大家这么多年的工作成果。在关键时候出问题并不是人人都担得起责任，但在出故障的时候又需要有人做出恢复决策。“这种时候真的需要一颗很大的心脏”，邹方明说。

因流量爆发而带来挑战的时刻，并不止这一次。将这些故障时刻合在一起，那就是一部腾讯的应急开发和宕机史。

存储爆表

2013 年之前，腾讯没有“重保”的概念。除夕这天，按中国人的习惯是吃年夜饭、看春晚，这一年，微信的体量更大了，非常多的网友在零点时刻开始使用微信跟家人朋友互动，大家拉上几个群互相发拜年视频，微信流量就比平时高了六七倍。这一情况，微信没有提前预料到，准备的容量不够，这么高的流量直接爆掉了基础架构部的小视频系统。

故障发生后，技术人员没办法临时准备资源，也没有预备方案，更不可能临时去写代码。问题没办法即时得到解决，作为系统的研发负责人，邹方明只能选择利用“熔断机制”让系统进行自救。这个机制相当于一个粗暴的拒绝服务的开关，从 7 点到 10 点，系统就处于过载的状态，很多用户的请求堆积在队列里面，最高峰百分之七八十的人发视频的请求在队列里面超时。10 点过后大家的热情慢慢地降了下来，下降到系统可以支撑的程度，这些限制才被打开。

邹方明回忆说：“这一年的春保，也是我最痛苦的一次。那个时间段，显得特别长，特别让人难受。我一点招儿都没有。用户投诉都涌过来，作为负责人，虽然我当时在那里，但是我只能眼睁睁的告诉老板，用户刚性的需求严重超出系统的支撑能力，只能发通告了。”

从这一年开始，腾讯就开始有了春节重保的意识，春节也开始安排技术人员值班，保障业务运行。

2014 年底的时候，朋友圈视频功能在春节前夕上线。据说当时腾讯认为可能没什么人知道这个功能，因此没有给予足够的支撑资源，没想到春节零点时刻，朋友圈视频直接将存储打爆。运营人员赶紧去查看，也就花了 3-5 分钟，在这么短的时间内，系统全方位崩盘了：流量爆了，前端的系统就像洪水，后端的系统更脆弱，连倒了三四个系统平台，最后不光基础架构部的小视频平台倒了，底层存储的其他部门其他系统也严重过载堆积请求了。

当时业务同事、运维同事都指着邹方明做出一个应对决策，老板在旁边也不敢再给压力，产品同事需要一个回复，用来向外界发出通告，类似于光纤挖断，就要告知用户原因，让用户不必恐慌。时间浪费一秒就是一秒，但他一时间确实找不到崩溃的原因，最后考虑各方面的因素，选择最大化自救。做出这个决定，非常艰难，“就像被毒蛇咬到手臂需要断臂自救，这一刀，你砍不砍得下去？！”

具体来说，第一步是先拒绝掉 80% 的请求，然后将整个系统全部重启，花费了近 5 分钟。等待系统恢复到满载服务的状态，又花了接近 10 分钟。20%，30%，40%，一点一点的把用户的请求放进来，确保系统的最大可服务能力输出。

“做出决策，最快地恢复服务，这是我的第一目标。我能够感觉到就是崩盘了之后，大家都指着我去做‘要人命’的决定。出了故障我才有价值，没出故障我就像一个闲人。”

微信红包大考

2014 年 1 月 27 日，腾讯推出了微信红包，这个红包系统最开始的设计是公司内部让老板们给几万腾讯员工发红包用的。但令他们没想到的是，春节期间，大家都用微信红包系统来给亲朋好友发红包。抢红包功能像病毒一样扩散开了，传播速度远比想象的还快。微信技术团队赶紧紧急申请资源存储资源（CKV），只是里面还存在更多的技术问题：一个红包，如果只是几个人抢还好，但如果几十万、上百万人并发去抢，还集中在除夕的 12 点附近，流量比平时高几百倍，这种高并发的问题就容易引起宕机事故。

而且实际情况就是几百万人参与了。除夕这一天，482 万人参与了抢红包，零点时刻，瞬间峰值达到 2.5 万个红包被拆开，前 5 分钟内有 58.5 万人次参与抢红包，其中 12.1 万个红包被领取。

2014 年 11 月，微信拿下了当年春晚的广告互动权。

罗振宇曾在跨年演讲上说：“我们对春晚一无所知。”

这种“一无所知”用来形容腾讯春晚战事最为合适。2015 年腾讯成为了首家和春晚合作的互联网巨头，也是春晚红包活动第一次采取口播的方式让大家参与。这时候的挑战是根本没办法去准确预估或推演这个系统到底要承载多少访问量，这是做架构的大忌。相对 2018 年的淘宝、2019 年的百度、2020 年的快手来说，此时的腾讯并没有可借鉴的案例。

原来在 2014 年研发的面向公司内部几万人的红包系统，不合适用来面向全国十亿人发红包。不同的用户数量级对应的是不同的技术架构，腾讯重新定制了一套摇一摇红包系统，这是一次从 0 到 1 的重构，基础架构团队和微信支付团队一起，通宵达旦地工作了一个多月。每天晚上 12 点钟提交版本，1 点钟做测试，大概三四点钟出测试结果，大家再商量第二天怎么做优化和改造。

只是这个时间还是太仓促，不足以在摸索中做出一个逻辑完备的系统。

除夕前三天，腾讯云副总裁、腾讯基础架构部总经理肖志立在排查中，发现了一个可能会有风险的实现逻辑，希望研发人员通过修改代码的方式减少风险。被要求修改的开发人员有点崩溃，他认为这时候去改动代码，压力太大了：临近大考肯定是能不改就不改，毕竟出了问题都不知道算谁的。

“一开始做了很多推演和预测，最后的结论是我们真预测不了，所以还不如换一个思路，去想各种方法控制住最后进到系统里面抢红包、拆红包和分享红包的用户比例，所以我们用了一些柔性措施，将用户请求在客户端就开始做筛选，会在链路中用漏斗模型过滤请求，控制真正进入到红包系统底层的用户数量。”

最后，通过“柔性”措施，腾讯比较顺利地支撑了这次活动，除夕当日微信红包收发总量则达到 10.1 亿次。

此后，春节红包活动变得常态化。2016 年，微信和 QQ 齐齐出击，不仅发出了数亿元的红包，更通过红包照片等新玩法赚足了眼球。不管是参与红包的人数、还是金额都创下了新高。2017 鸡年除夕当天，微信红包的收发依旧高达 142 亿个。只是顶住了 2015 年的洪峰，后面几乎就没有再出现过什么大问题。

腾讯会议扩容

2020 年春节期间的腾讯会议，再一次让人意外。当年一月的时候，腾讯会议 DAU（日活跃用户）还只有 5000，到了二月中旬，同时在线已经突破 400 万了，达到了 1000 倍的增长。几百万流量的业务在腾讯有很多，技术层面上的难度还能应付，这次最大的问题是物理资源。腾讯云的服务器是开放给外部客户的，不可以动，所以运营管理部门需要自己想办法。在春节期间，运营商 BGP 的带宽满足不了，运营商的外网 IP 地址满足不了，而且设备供应商由于无法复工，所以设备也供应不了。

肖志立回忆说：“当时给合作伙伴打电话，能不能给库房供 1 万台机器，他们说不好意思，员工都回家了，疫情期间没有办法回来。”

硬件设备不足的问题就得由软件来消化：不能依赖 BGP，要做三网调度，做移动、电信、联通这样的分运营商出口的调度模式，同时质量又不能变差；IP 地址不够，就想办法用端口复用的技术，但这又涉及到一个问题，如果不是知名端口，会涉及到防火墙穿透的额外技术手段；还有新机器供应不了，我们从全国各地调用服务器，重新通过虚拟化的方式，或者软件架构的方式去适配，把业务支撑起来。

初七，肖志立召集了几十位业务技术人员开始了改造，从进场、确定问题、确定方案、动手改造，大家一起通宵奋战了七天。第十天后，流量也达到了业务的最高峰。“其它时候多少会有些小问题，但所面临的困难和紧迫程度、压力都不如这次。”

从“拜佛保平安”到“一切按照剧本走”

从 2013 年到 2016 年，腾讯的系统处于性能、承载力不足的阶段，各种不足有可能导致系统发生不同的故障。最开始大家确实有点“手忙脚乱”，运维人员需要承受巨大的压力用最快的速度去恢复服务。基础架构部红包系统的运维负责人肖攀说，为了缓解紧张，到了除夕夜，“我们还会在办公室拜拜‘佛‘——也就是企鹅公仔”，祈祷不宕机。

故障是软件系统的一部分，宕机则是很多故障累积到无法恢复的程度。每年春节过完，腾讯都会马上组织复盘，去分析每一个故障，在技术或架构上做对应的优化，将踩过的每一个坑都填补起来。

2014 年除夕微信小视频发生故障之后，面对春节后依然很高的流量，腾讯优化了视频处理的系统架构，正常的时候用普通的存储系统来支持，多余的量放到缓存中。后来几年这部分缓存功能又被进一步优化，用延时统计请求、降码率、前端主动扩展等多方面的策略代替缓存去提升性能。

虽然 2014 年底重构了春晚红包系统，但 2015 年央视春晚活动之后，腾讯再次对红包体系做了一次性能优化，原来抢红包对系统请求两到三次，调整后变为了请求一次。早期的红包系统主要部署在深圳，考虑到假设深圳机房或网络出现问题会对用户产生一些影响，在 2016 年除夕来临之前，腾讯增加了深圳和上海两地部署的架构，增强了容灾性能，随后又通过数据压缩等方式不断降低资源成本。

一年年的，系统越来越稳健，大家也越来越熟练，不再手忙脚乱，想不到的地方越来越少，每年的复盘工作也让大家形成了方法论，变成了一个跟原来不一样的、例行化的、全年性质的工作。

用一年时间准备一次大考

我们看了太多临危受命的春晚红包故事，春节前一个月左右才收到正式通知，紧急组建团队参与战斗，最终赢得了胜利。但这样的战斗背后，掩藏了非常多的技术人的努力，并不仅仅是两个月的工作量。

春保包含两方面的工作，第一是全年都在做的，日常在系统架构上的升级优化，在技术层面上需要不断地设计得更好，防止突发。第二是提前去做容量方面的全链路压测，确定柔性策略和扩展策略可以下发成功。

为了筹备春保，腾讯将全年的工作分成了两个阶段。国庆之前主要是提升系统的可用性、稳定性。基础架构部门会考虑怎么去设计一个优雅而又低成本的系统，从架构上怎么去实现一些不影响用户体验的柔性措施，包括前端到后端，整个链路上的架构升级迭代，让用户觉得响应更快，延时时间更短；还会去研发一些自动化工具，让运维效率有所提升，让系统能够拥有一些自我管理的能力。

资源筹备一直是春节重保的重头戏。

各互联网企业每到春节，都得为协调资源操碎心。2018 年，淘宝为春晚准备了三倍于“双 11”的服务器资源，而就在主持人口播活动开始的一瞬间，流量达到了“双 11”的 15 倍，服务器瞬间超过负荷。2019 年百度为春晚红包提供了 10 万台服务器，其中有 5 万台服务器是冒着风险从百度核心的“凤巢”广告系统临时下线让渡而来。2020 年快手提前准备了 10 万台服务器，还包括协调腾讯等友商的 2 万台云端服务器。2020 年春节期间的腾讯会议也扩展到了 10 万台服务器。

每年春节，腾讯红包业务的流量是平时的几百倍，设备数量也是平时的几百倍，图片视频业务相对使用的带宽和设备也会更多。资源沟通不仅涉及内部业务之间，也会涉及到运营商带宽申请等等。

运营技术部门会先收集需求，跟一些需要重点服务的业务后台负责人对接，包括 QQ 空间、微信、腾讯会议等七八个核心业务，了解他们会不会在除夕做活动，产品上面有没有一些新的场景或玩法。比如今年视频号提出了“点亮心愿”的玩法，就需要评估这个玩法会吸引多少用户，对应量级的用户需要多少台设备。在这个过程中，会把 IO、存储、带宽这些资源的需求盘点一遍。这一轮 PK 大概需要一个星期的时间。

随后技术运营会去准备资源，找运营管理部、负责采购部门的部门调配或购买机器，要求在 11 月或 12 月设备到位。但也不是你要 5 万台就给你 5 万，运营会根据公司整体资源使用情况，以及规划中所有应该考虑的因素，将资源和需求做一个折中的平衡，给出一个需要申报的量级。所以可能是你要 5 万台，技术运营根据实际情况给出 1 万台，剩下的就需要从技术层面、用户体验层面、产品玩法层面上做折中。

最通常的做法是去提升单位成本下的设备承载能力。同等设备同等的资源情况下，将设备的承载能力变强，比如 1 万台设备原本只能支撑 100 万的请求，现在优化到可以支撑 500 万的请求。同时将软件系统的逻辑设计得更为简洁，同样一个资源，以前消耗三次，现在只需一次。

还可以通过提供柔性服务解决部分问题。比如朋友圈视频，如果使用 2m 码率，在高峰的时候要扩展 10 倍需要几万台机器，运营肯定一下子给不了那么多，那就需要降低码率到 1m 或降低到用户可以接受的一个范围内。还有比如产品想提供一个精致的玩法，但可能只能确保 10% 的用户有精致的使用体验，另外 90% 无法参与，那么是否可以考虑一些柔性措施让 90% 的用户都参与进来。这是技术与运营的第二轮 PK…

经过这样的两三轮 PK，将各方诉求跟资源的匹配慢慢进行调整，逐渐形成一个重保方案的定稿。

这个时候就差不多 11 月底了，提交资源需求后，差不多也给运管留了一个月的资源交付的周期，研发也要开始入正常研发阶段。国庆之后，腾讯一般会将 50％的研发力量投入到春节重保准备上。两到三周后进入到最后的压测阶段。

在春节前的一个多月里，以周为单位进行压测，各个平台都会一轮一轮的紧锣密鼓地查漏补缺。整个压测过程，涉及到的链路很长，所以每一轮压测里面只要发现某个环节有问题，涉及到不同的团队和部门都会去做一些调整和优化。也确保在国庆到 11 月份期间做的这些柔性策略，可以成功的配置和下发到系统里。测试的流量需要不低于春晚，如果实际流量比测试的还高，就会在实际中使用一些降级措施。

春节到来之前，还有元旦，也会有一波很高的流量，可以当作是春节前的一次练兵演练。有时候元旦也遇到过一些问题，那么可以在元旦之后到春节的这段时间里做进一步的完善。把这些预案准备好，基本上到春节了，就可以迎接大考了。

吃过的亏，都变成了脚下的路

腾讯将每年的复盘总结成了一套春节重保方案，写进了他们的操作手册中，大家喜欢将这个手册称之为“剧本”。

第一阶段、第二阶段、第三阶段技术人员各需要做什么事情，都会添加进剧本中。大家有细致的准备和明确的分工，按照剧本一步一步地推进和演练。

剧本中会包含一些能预料到的关键时刻，比如元旦、中秋的晚上，国庆大阅兵的时候。这些时候大家喜欢发图片留作纪念，流量会有 10-20 倍的增长，需要腾讯会提前半个月做一些资源的补充和柔性上的设计，让整个服务不至于崩塌。

还有一些不可预料的热点事件。作为一名老技术人，邹方明在一天早上上班的路上，接到了很多同事打的电话，有做传输的，有做存储的，告诉他系统崩了，因为网络上上传某事件的视频已经传疯了，导致系统崩溃了。“我们这才意识到，我们的系统对热点事件也要有一个防范，需要有一个预警服务。”

“到现在，热点事件我们经历了非常多，逐渐就形成了一个三级的方法论”，邹方明表示，有了这套方法论，就算再有未知的热点事件，在目前的环境下，它也很难掀起大风浪了。

第一是在热点事件来临之后，该扩容就扩容，这是最简单的。

第二是必要的时候再增加柔性和熔断的措施，这也是腾讯的标配，“因为吃过的亏太多了”，必须要有柔性的开关，自我熔断的能力，因为人为预估的量不是总是准确的。超过的量，人操控的速度来不及，就由系统去控制。这种时刻，开发和运维会盯着关键的数据，各个级别的数据都在“剧本”上有对应的操作。流量的水位线分为几级，对应的柔性措施也分为几级。在水位线达到 90% 的时候，提前下发对应的柔性配置。“所以除夕当晚我们会有很多的微操，但是水位线是定好了，要求我们操作要比较快，能够生效，对系统其实是有一定要求的。”

“现场就是按照标准去操作，谁也别瞎来。”

第三，如果真出现了超出预期之外的故障，系统中总有这种看不到或想不到的地方，出现这种情况的保底措施就是人为熔断，就像 2013 年发生的故障那样，先拒绝一部分服务，然后看数据，不够再拒绝更多，直到全部拒绝。

流量太高的情形下，一般原则是先降级后限流。限流是没有办法的办法，是最终的一个降级手段，让用户不能正常使用了。在春晚红包系统中，常做的是降级措施，平时收发红包之后，红包账单记录用户是即时收到的，但在春晚这一天，系统会把账单延后两小时写到个人账单中。这种延迟服务就是一种降级，能将系统压力降下来。

按照现在的机制，如果聊天系统或图片系统挂掉了，三分钟就会发出预警信息，运营看到后就要去做手动熔断，让系统重启，预期时间 3 到 5 分钟恢复系统。

这种故障发生后，系统负责人去查看问题定位方案，“按照剧本，我们限定了最高时间为 5 分钟。5 分钟找不到问题方案，我们就强制系统重启。”邹方明表示，“我们的要求也是不断的提升的，以前是 10 分钟，后来缩短到 5 分钟。根据多年经验，我们系统有好几次有 30 分钟甚至一个小时挂在那里。这样的方式对用户不是特别好，但能一定程度提升系统灾容性能。”

最终以用户投诉量为标准。邹方明举例说，有一次朋友圈视频出现过故障，它也不是完全不可服务，只是长时间维持百分之十几的失败，这时候重启能恢复，但是会导致大量投诉，大家不知道该怎么办。这种情况下，在巨大的压力面前，与其大家无法做决策，不如事先在操作手册上把决策做好。

“不出问题，当然就很开心”

农历庚子鼠年的最后一夜，晚 7 点，在腾讯大厦里，一群技术人目不转睛的盯着流量监视屏，保证突发流量不会导致微信、QQ 出现故障。一旦有爆发点，需要他们反应迅速地提前开启一些降级开关，比如延缓朋友圈消息的下发，来保障用户在突发点上业务的体验。

今年与往年有所不同，国家提倡原地过年，同时微信也推出了视频号。

按照往年的经验，到了零点大家开始拜年，有的人发红包、文字、拨微信视频，红包会有一个流量尖峰，同时微信小视频在零点之后的流量也会达到平时的两到三倍。

预料到“云年夜饭”的情况，今年的监控被提前到了 7 点。果然这个时间段，音视频通话有了一波突发，很多人在这个点给家里打电话，导致 7 点的峰值比往年零点还高。运营根据系统的容量和转码能力，对视频码率做了 10% 的降低，安然度过了零点前的这个关口。

视频号也加入了今年的春节重保中。今年微信推出个人定制红包封面，前提是要开通视频号并发布视频。这给视频号的发布量带有了一个巨大的增长。视频号的视频比朋友圈小视频更大更长，且一个视频上传微信要处理 6-8 个格式出来。应对视频号的突发，腾讯做了一些视频处理的动作，着重处理最关键的部分，压力就在于有大量的转码。

今年点亮 2021 的视频号直播的活动，也是比较成功的，流量涨幅是平时的 10 倍。它也是腾讯在春节期间推出来的一个新技术，主要利用小视频里的能力，音乐是单独下发的，活动中看到的背景其实是一个画布，是一个会实时更新的单独的一张图片，由客户端拉取过来。

整个活动对图片平台的影响比较大，封面图片每五秒更新一次，全网的用户都要更新，对 CDN 和数据传输产生了一些挑战。为了减少高并发的影响，腾讯在技术上预先做了针对性的优化，利用非实时推送的策略。在后台生成这样图片的时候，腾讯会在五秒内推送过去，用户是在五秒后看到这张图片，这样就减少了因同时在线用户数量高产生的并发量。

今年的春保显得相当平稳，大家的压力明显小了很多。肖攀表示，“我们基本上就是看着系统的状态为主，空的时候甚至还可以跟家里人聊聊天。”

初二后，所有的用户请求量逐渐下降。针对除夕做的很多定制化研发，在初四、初五之后，技术人员也需要将这些定制的参数、定制的逻辑恢复到正常系统状态。

春保结束，腾讯将除夕使用到的资源分为了两个部分回收。一部分资源在元宵节前退回，一部分容量作为预留，给元宵节后有二次增长还需要继续持续扩容的业务。红包的业务一般会把春节中扩容那部分全部回收，还有其他业务自然增长的也会回收。这些资源会统一放进公司的“大池子”里。

对比前七年的坎坷，今年春节重保显得从容很多。腾讯基础架构部总经理肖志立自信地说：“我觉得在目前来看，今年没有特别明显的缺陷和短板。”