图11 总带宽和高在线房间带宽隔离监控
散场场景
功能概述：如前文介绍，主房间的散场路径分别是退回至进入房间之前的流量入口页面和下滑至另外一个直播间。
QPS预估：
- 散场路径一为流量入口带来的QPS=PCU*退回点击率；
- 散场路径二为下滑的下一个直播间带来的QPS=PCU*下滑转化率。
与电影散场时观众同一时间集中走出观影厅类似，上述两个散场路径的QPS是非常明显的尖刺流量。
图12 散场场景的尖刺流量
技术优化：
- 散场路径一：出于推荐效果的考量，用户停留在主房间超过一定时间后再回退至流量入口，部分流量入口会触发自动刷新机制。但并不是所有用户回退后是继续消费最新推荐内容。因此，采取的手段是在部分时间段避免触发自动刷新机制，更自动化的手段是当超出系统承受值时，自动控制终端不触发自动刷新。
- 散场路径二：由于主房间的PCU过高，导致下滑的下一个房间也成为一个高在线房间，依赖高在线房间SDK可使该房间自动进入热门房间缓存。但根据对推荐结果的分析，我们发现推荐的下一个房间聚集在有限的几个赛事房间。为更安全的防御这类瞬时尖刺流量，优化手段是基于推荐结果，利用这几个赛事房间作为主房间下滑的房间候选池，并提前加入热门房间内存缓存。
图13 散场路径二优化后缓存命中率效果
全局维度关注流量
同一个下游，可能被多个业务场景同时调用，该下游的流量是所有被调用之和。因此除了关注某个指定接口的QPS，还需以业务场景维度和整场活动维度来关注，下文我们还会再探讨实际操作上如何去做。
另外，从项目成本以及资源考虑，赛事期间的流量远高于日常，所需要的资源也远高于日常，需要提前盘点各阶段成本、进行资源的采买，因此全局估算流量也是资源容量预估的前提。
保障任务分工
确定业务场景地图后，参与人和团队的确认需要结合保障事项和组织架构两方面考虑。
参考RASIC原则，保障事项拆分为若干项子任务，每一项子任务需设立负责人以及明确责任边界、目标和DeadLine。另一方面，实际过程中不免存在交叉事项涉及多方资源协调，因此根据保障事项涉及到的部门，分别设立了部门级别的方向负责人，方向负责人被充分授权负责协调保障事宜。最后，建立定时定期同步进展和风险的机制，也是整个项目顺利运行的重点。
图14 保障接口人思路示意图
实践和思考
除了前文所述用户强感知到的业务功能之外，还有基础建设部分，如业务功能底层使用到的流媒体、长连接、账号、风控等，我们将其归纳在业务基础建设中分专项进行保障。以及从B站的整体基础架构来看，各层基础组件如动态/静态CDN、SLB、入侵防御WAF、统一网关APIGW、内部服务发现Discovery、PaaS、存储Redis/DB、异步消费Databus、网络、大数据等的资源预备、多活容灾能力、应急预案，我们将其归纳在技术基础建设中整体保障（见图2）。
接下来我们将重点讨论技术链路的梳理、故障演练、全链路压测、预案SOP、变更管控和赛中跟踪的实践和思考：
