2025 B站春晚直播——技术保障复盘

2025年1月9日，哔哩哔哩正式宣布与中央广播电视总台达成合作，成为《2025年春节联欢晚会》的独家弹幕互动直播平台，对于技术团队来说首要目标是确保春节七天系列直播活动稳定运行，尤其需要重点保障春晚四小时黄金时段的直播质量万无一失。然而，一个细微的代码错误或第三方服务的意外中断，都可能导致整个直播系统出现故障。针对这些潜在风险，我们将详细介绍相关应对措施与解决方案。

除常规活动需求开发外,项目组特别召集了跨部门的核心技术人员,专门就系统稳定性保障事宜进行深入研讨。会议期间,与会人员就"活动保障与日常运维保障的本质区别"这一关键议题展开讨论。经过分析,我们认为活动保障与日常业务保障的主要差异体现在以下几个方面：

1. 项目开发周期紧凑,需求变更频繁,且存在严格的时间节点限制,这对研发团队的交付能力提出了严峻考验。

2. 预期用户访问量将远超日常运营水平,加之春晚现场口播引流因素,可能导致瞬时流量剧增,这将给服务器承载能力带来巨大考验。

3. 系统整体运行容错空间极小,特别是在春晚直播期间,需确保数百个业务系统和数千个后端服务的稳定运行。在高并发环境下,即便微小的技术故障也可能造成系统性影响。

为深入探讨各项技术保障措施,我们特邀各技术领域的代表进行专题研讨,共同分享其保障策略与实践经验。

每次大型活动前，通常都会进行一次摸底故障演练，故障演练是按照用户的功能场景来划分的，而场景是指提供用户功能的后端接口和相关调用链路上应用与调用关系的集合，准确、无遗漏的调用链路是我们做故障演练的数据基础，在过去，场景的梳理完全依赖人工经验，散落在各团队的文档中，人工梳理容易出错且非常低效。2024年，业务架构团队构建了场景元信息平台，通过客户端实时采集用户操作链路数据，进行链路拓扑分析，构建出直播75个核心场景、300+子场景的完整依赖关系。

例如，用户在首页点击“春晚直播卡片”时，后台实际触发了100+微服务调用，涉及获取房间信息、用户与挂件信息、播放地址、风控判断、数据统计等等数十个环节，纯靠人工梳理很难梳理完整。

在有了场景信息后，下一步是验证每个接口和链路的故障表现，明确在业务场景下的强弱依赖关系，发现不合理的依赖问题，为了解决场景链路到故障点创建和执行的鸿沟，我们打通了故障演练平台与场景元信息平台的数据交互，使其可以在场景元信息平台上一键进行故障创建和演练执行，极大的提升了演练效率，将每个故障点的演练耗时从分钟级降低到秒级。

演练完成后，可以直接在平台上面进行演练结果的标注：确定强、弱依赖、是否需要改进、补充故障信息等，通过这种方式让演练的进度变得非常直观，演练结果也不易遗漏，帮助减少重复演练，最终实现演练的增量执行。

• 链路变化实时监控：平台会启动后台任务，每日扫描全链路链路，一旦发现新增依赖（如增加新的接口依赖），立即提醒用户补充演练场景。

• 进度看板透明化：针对活动场景展示“演练覆盖率”，整体的演练进度、每个场景的演练次数、最近触发时间一目了然。

针对直播间的核心功能模块，我们设计了三级容灾体系：

第一级：进房播放必保

1.本地缓存兜底：在播放服务提前部署热更新配置文件，预置多个重保房间的播放地址、封面图等核心数据，当核心依赖故障时，直接返回内存中预置的播放数据。

2.双活架构：播放链路的核心服务做到双机房部署，任意机房异常都可以动态调控流量，将流量切到正常机房。

3.客户端降级策略：首次进入进入直播间时会下发兜底地址，当三次播放地址请求超时后，客户端自动启用兜底播放地址，避免黑屏的发生。

第二级：次优先级模块保障

• 答题系统：构建多级缓存体系（本地内存 -> Redis集群 -> KV数据库集群 -> MySQL数据库），任意依赖故障可无损降级到另一层。

• 弹幕系统：通过提前配置限流模块感知系统用量，当超过系统负载时，主动丢弃部分流量，避免系统雪崩。

第三级：可降级模块处理

底部面板：预先静态配置最小化功能模块，当底部面板服务不可用时，首先保障基础功能可用，同时隐藏故障对应的功能子模块，降低问题影响。

这部分我们将在下一篇文章详细介绍，敬请期待。

我们通过蓝军模拟攻击的方式，发现技术和非技术的保障隐患，快速完成查漏补缺。

蓝军团队的角色与筹备

在春晚项目预演时，共约10名研发、运维、测试同学组成了“蓝队”团队进攻，其他技术、SRE同学作为“红军”团队防守。

攻击剧本：

• 流量洪峰：模拟除夕夜开播瞬间的数十倍峰值流量，验证网关业务容器的扩容策略和限流保活方案。

• 关键微服务故障：在关键服务节点注入高延迟，触发超时熔断机制，注入单机房服务异常故障，验证多活切换机制。

• 现场突发情况：蓝军在演练时将指挥室断电断网，考验团队应急能力。

• 核心后台异常：模拟后台故障，验证是否能绕开故障的管控后台，直接通过API恢复业务。

• 模拟人为误操作：对变更类问题，配置错误、发布事故，能否快速感知、恢复、验证。

• 关键人离场：模拟关键人春晚当前无法到达现场操作后台系统，验证是否有备用操作人，是否熟悉操作流程。

最终发现多个隐患：

• 现场座位安排不合理，异常情况出现时沟通不畅 -> 后续调整为每个能力模块为一个小组，产品、运营、开发等角色尽可能坐在一起。

• 部分网络协议的网关流量管控能力异常 -> 事后进行定位、发现问题进行修复。

• 在模拟人为登录容器进行破坏时，难以快速定位操作人 ->  增加特定时段物理机、容器手动执行命令的后台实时监控通知能力。

首页框架可能是B站年纪最大，业务逻辑最复杂的模块。但它一方面要时刻响应产品侧灵活多变的需求，另一方面也要直接承接春节的流量洪峰冲击。

在极限的开发节奏下，又快又好是我们始终如一的承诺：

• 注重体验，精准导航：通过系统性的归纳和设计，春节Tab页承接了来自微信/QQ/H5/新老客户端分享等数十种召回场景的唤端和准确跳转，保证用户体验丝滑流畅。

• 垂直领域拆分+独立保障：将春节Tab上直播/答题/节目表/赞助商鸣谢等多个垂直领域的业务模块拆分开来，针对每块业务独立设计首屏保障方案，确保每个模块互不影响，可独立降级/重试。

• 态势监控+本地容灾：精确监控每一个请求处理过程中网关系统的响应状况，做到核心依赖可本地容灾。极端情形可在所有下游依赖宕机的情况下，保持春节Tab页可用。

• 冷启动链路梳理与保障：App冷启动涉及上百个接口，经过产研同学的系统性梳理后，按重要性进行了分级保障，包括扩容/限流/黄金时段熔断请求等不同策略。

• 可扩展架构+支持业务热更：系统水平扩容无瓶颈，除夕晚会期间平稳支持活动页面布局/内容等业务信息热更新数十次。

春晚当天交出了一份完美答卷：多场景召回跳转体验一致，晚会口播期间稳定的承接了洪峰流量。

答题作为本次直播活动新引入的主玩法，一直处于“变化”和“未知”中，需求在变、流量口径在变、产品形态在变，技术方案不断推翻重来迭代，研发侧压力陡增。

为此研发侧只能“变中求稳，稳中求进”：

• 抽象组合业务逻辑：从变化的需求中寻找可抽象可组合的部分，降低频繁变更带来的代码质量风险

• 优化与端上交互方式：调整端上答题信息更新、题目下发机制，可指数级降低异常QPS风险

• 双机房+双存储模式：为了解决潜在风险，包括单机房故障、KV存储故障、databus故障等

• 饱和式压测：预估峰值+人为buffer+摸高，不断挑战系统极限

• 风控组合拳：waf拦截、接口签名、antispam、行为风控策略等，多种策略组合降低黑产刷接口带来的风险

• 业务指标监控+SOP手册：近实时业务监控面板和详尽的SOP手册，用于应对临场特殊情况

在春晚当晚，看着一轮轮口播带来的突增峰值流量，心中已没有太多紧张和压力，Prepare for the worst, hope for the best。直播互动答题参与人数千万+量级下2s内精准统计现金瓜分金额，没有“炸”，玩法顺畅，一切皆如所愿。

春晚保障对基础组件、基础设施保障都是一个大考，既要满足业务资源需求、又要保障基础组件稳定性，确保业务必保目标达成。

面临的挑战：

• 备战周期短，叠加春节物流因素IDC机房内无法采买服务器和网络设备

• 年底云厂商资源供给不足

• 部分机房缺乏弹云能力，活动期间资源受限

• 有状态服务弹云难，DB、KV等有状态服务没有上云先例

• ...

资源需求：业务技改治理 + 基架容量调控

1、业务技改治理

计算资源治理：冷起场景治理，通过无流量接口下线、弱依赖接口"口播期间"干预端上不请求、多接口合并成单接口请求等手段，极大降低源站计算资源请求。

带宽类资源治理：干预离线包资源下发，口播期间不下发春晚无关离线包。

APP流控：服务端限流时，下发端上流控冷却策略，避免限流后触发业务雪崩。

2、基架容量调控

• VPA技术：通过应用容量画像，基于应用服务等级、历史资源水位、多活等数据，动态调整应用request值，释放大盘可调度资源。

• 弹性上云：UGC转码因其占用资源多、无状态、延迟要求低、容器化等特点，天然具备快速上云能力，唯一要考虑的是专线带宽相关的支撑，通过转码上云给业务供给X万核资源。

• 多活切流：多活机房缺乏云弹性能力，通过多活切流，让更多流量偏移到主机房。

• 跨部门资源调配：春晚保障属于公司级项目，统一资源协调，从离线、商业等部门借调资源

• 跨组建资源供给：k8s容器化资源弹性上云，供给资源给SLB、WAF等

• 静态CDN多厂商供给：多家商业CDN做带宽储备，用DNS做智能调度实现均衡和容灾

• ...

组件稳定性：业务摸高压测 + 故障域隔离 + 业务降级

业务压测：压测是保障组件容量符合要求的必然途径，我们全面梳理春晚活动场景用到的基础组件，细化到每一个DB库，KV表，MQ的Topic，按照预估峰值的1.5-2倍扩容，业务进行摸高压测，验证系统承载能力并优化性能瓶颈。

故障域隔离：基于不同场景，隔离影响故障域，直播、活动、支付等核心场景在资源层独立部署，隔离故障域。

业务降级：梳理每个组件可能的异常场景及收敛时间，业务建设容灾能力，整体策略如下：

• 多活业务平滑容灾：通过apigw平滑重试，单可用区组件故障、抖动，业务可以平滑重试到另一个可用区，用户无感

• 非多活业务降级：双集群降级、同步转异步降级、业务重试等

• 能接受故障收敛时间的场景，提前同步产品、业务，达成一致

做好容量、组件保障预案，在突发事件中提前规划好预案也很重要，确保出线重大故障能快速响应、有序处置，最大限度降低风险与损失。

• 目标设定：明确验证指标，如故障场景下端到端功能稳定性、业务影响面、数据一致性等

• 环境准备：在故障演练平台创建好场景并半自动收集链路后，由QA同学在UAT环境或线上染色环境执行依赖项的故障演练

• 预案确认：监控告警指标、功能兜底策略、回滚方案、人工操作降级预案

• 故障注入：模拟接口超时、接口故障、流量突增、网络故障等，平台支持grpc/http请求、redis缓存、消息队列、DB存储、分布式存储等多种依赖的故障注入

• 多维度观测：功能可用性、接口响应时间、日志告警、业务指标监控、故障恢复时间等

面向提高演练频度和效率，实现故障模拟的自动注入及恢复、端到端自动化测试、故障智能判定和定位分析

极端机房网络故障场景下，如专线中断、单机房网络设备异常的基础故障，需要将流量全切其他可用区。面对春晚高稳定性要求的挑战，业务多活有效性需要提前预演，保证多活在故障时可生效、可切量、可逃生。

可通过前置cdn切流，在不影响线上用户的同时，模拟双机房专线中断故障。QA汇总业务场景范围和测试案例，在故障期间通过测试CDN定向校验多可用区，验证单可用区多活服务的有效性以及多活自动容灾的效率。

春晚保障期间，通过系统化多轮次故障演练，累计覆盖900+核心业务接口，模拟9000+上下游服务故障场景，共定位召回300例潜在业务稳定性隐患，为系统的可靠性和容错能力提供了坚实的技术保障。

通过以上各位技术同学的深度分享，相信各位读者已经获取了宝贵的技术洞见。当春晚直播倒计时归零，观众在直播间弹幕中欢庆"新年快乐"的同时，技术团队监控大屏上显示的"零定级事故"字样，正是对我们技术团队数十个日夜精心准备与坚守的最佳印证。

最后，附上我们保障团队的合影留念，让我们明年再见吧~

-End-

作者丨小旭、Shliesce、春申、山涛

在你的工作中，是否遇到过类似春晚直播这样高并发、高压力的技术保障场景？你是如何应对的？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取扭扭龙+B站pu定制包

抽奖截止时间：3月21日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！