S11总决赛那晚，B站SRE为活动保障都做了些啥？

​一、背景

B站每年都会有多次大型活动，如拜年纪、最美的夜、LOL全球总决赛、电商626、919秒杀等其他活动。其中最美的夜和LOL全球总决赛是在线流量最高的活动。在S11总决赛过程中，全站整体平稳运行，无基础设施、组件故障和服务核心链稳定性故障，抗住了远超预期的在线人数和流量，直播同时在线人数突破千万。

一场成功的活动保障离不开多个团队的共同付出和努力。SRE在背后是如何支持保障这些活动并不断完善我们的活动保障体系的呢？接下来就为大家揭晓。

二、活动场景

案例1

在SRE的某次活动保障中，突然听到运营同学说某某时刻微信、头条等APP会上线活动的推广链接。考虑到微信和头条APP的用户量级，SRE担心新用户到来会对基础资源和业务服务带来冲击。但因为事发突然，短时间大家也无法预估接下来的用户量级。所幸最终推广带来的用户增长有限，未对活动产生影响。

案例2

在某次活动事前沟通中，SRE从研发侧得知运营要在活动中对全站在线用户做一次站内Push：对打开App的所有用户推送一个App内的弹窗。此方式会快速推送到几千万量级的在线用户。如果用户点进活动链接，那瞬间带来的流量会击垮活动业务，甚至对我们的基础设施也会带来压力。SRE跟运营和研发三方确认后，认为此方案风险太大，最终取消。

案例3

在SRE的某次活动保障时，峰值流量已成功过去，活动保障进入收尾阶段，大家已经准备收拾东西下班了。突然多个服务发生报警，服务不可用。SRE紧急介入排查，发现是活动后运营做了一个推送，导致用户集中去访问一个非活动链路中的服务，此服务未纳入活动保障中，导致容量过载，服务不可用。

还有非常多类似的案例。所以对SRE来说，为了能成功的保障一场活动，除了技术上的保障和跟研发沟通外，还要主动跟运营、产品确认活动形式、玩法、外宣方式等，SRE得离业务近一点。SRE目前会收集活动如下的信息：

​1、活动形式

活动的具体玩法是什么：是一个直播间、还是一个秒杀、还是一个互动等，不同的玩法所需要重点保障的业务场景完全不一样。

​2、重点场景

同一个活动，但重点场景可能不一样。比如某一场直播的重要场景是在线人数和弹幕，但另一场直播的核心可能是用户送礼和抽奖。

了解重点场景，可以指导SRE后续跟研发共建服务端保障的重点预估在线人数。

3、预估在线人数

活动本次预估在线人数是多少，如何预估出来的。

有哪些在线人数转化的路径。

​4、活动对外链接

WEB、APP内的活动入口是什么？

了解用户访问路径，SRE才能做到全链路的可用性保障。

​5、活动推送

活动中一共有几次推送？推送的形式是什么？用户转化率是多少？

​6、活动后场景

活动结束时有没有特殊行为，比如直播间自动跳转点播页面？

活动后有什么运营事件、有什么二次热点？

这些事件所对应的用户访问路径和服务都需要SRE去重点保障，不然会有始无终，顾头不顾尾（这都是血泪的教训）。

​7、时间线

活动前期上线、外宣、预热的时间线。

活动中的开始、推送、抽奖、口播、结束等时间线。

三、资源准备

根据前一步跟运营、研发了解的活动内容，我们已经知道本次活动预估的在线人数，根据此在线人数和历史活动的容量数据，我们可以初步预测本次活动需要的资源。SRE把资源分为两类：基础资源和业务资源。

​1、基础资源

主要是基础设施对应的资源，如下，一般是要确认CPU资源和带宽资源：

DNSDCDN（动态CDN）静态CDN带宽直播弹幕带宽高防源站四层LB源站七层SLBWAFIDC-云专线带宽IDC间专线带宽NAT带宽网络硬件带宽日志/监控

在这里对最后两项作出解释：

1）日志/监控

活动期间大家格外关注监控数据，需要基于监控数据来执行预案，所以监控的保障非常重要，需要纳入SRE的管理；日志类似，活动期间，查询各种数据，用户行为，业务异常等，也需要日志系统稳定。

2）网络硬件带宽

因为活动中业务流量突发，历史活动中曾出现过网络硬件设备带宽被突发打满的情况。所以对于业务的核心链路（机房入口—