如何保障一场千万级大型直播?( 三 )


1. 全链路监控
整个直播链路的监控包含了上行推流链路的流质量、媒体流实时转码处理、端上播放质量、智能调度系统的可用性、业务量水位等相关监控数据 。上行链路常见的QoS指标有帧率、码率、RTT等,其维度包含主备线路、出口运营商、CDN厂商节点等 。端上的QoS指标则包含了拉流成功率、首帧时长、卡顿率、httpdns缓存命中率,维度则覆盖包含CDN厂商、国家、省份、运营商、直播流、清晰度档位、客户端等 。
此次直播中,内容上支持了多种机位流以及多个清晰度的转码输出流,同时通过多个CDN厂商进行分发,我们把上行链路中节点的码率、帧率,直观地通过N个指标卡集中展示在单个大盘页面上,并且通过增加预警值进行异常显示和弹窗消息告警 。活动作战室现场,我们采用了多个大屏展示,非常直观地展现当前主备双推流链路的实时帧率、码率等情况,为现场地指挥保障提供了强大的数据决策支撑 。
以下图为例:蓝色表示上行帧率,绿色表示正常的上行码率,红色表示码率值过低,N/A表示当前没有上行推流数据 。

如何保障一场千万级大型直播?

文章插图
而在下行播放链路中,比较常用的指标就是卡顿率 。下面是我们对卡顿相关的描述:
l 一次卡顿:播放器持续2s发生缓冲区空,即播放器2s没有拉到流
l 一分钟用户卡顿:1分钟窗口内,用户只要卡顿一次,则该用户计作卡顿用户
l 一分钟用户卡顿率:1分钟窗口内,卡顿用户数/总的用户数
l 一分钟用户零卡顿率:1分钟窗口内,(总的用户数 - 卡顿用户数)/总的用户数
为什么会选择用户卡顿率这个指标呢,而不是使用整体的卡顿采样点/总采样数呢?是因为我们更想看到有多少用户没有出现过卡顿现象,这更能直观体现优质网络的整体占比 。通过对各省份用户零卡顿率、用户数排行,以及各省用户卡顿率的观察,我们可以非常直观地找到卡顿严重的地区,以便重点关注,进行资源调度优化 。
2. 直播应急预案
| Hardware faults,software bugs, and operator errors, such failures are a fact of life:not a problem that will someday be solved once and for all, but a reality that we must live with.
Armando Fox.2002.Torward Recovery-Oriented Computing. VLDB 2002.
任何一个系统,无论你号称它被设计得多么健壮,它仍然会有故障时间的存在 。硬件故障、软件bug、人为操作失误等等,这些都无可避免地存在着,他们未必是一个必须多少时间内将其彻底解决的问题,他们是我们必须认清并接受共存的一个事实 。
所以,预案管理是大型直播活动保障中不可缺少的一环,我们遵循以下的预案原则:
1. 预案信息明确:大盘自动监控不具备二义性,确保预案信息来源正确,触发执行预案的条件明确且有数值化约束 。
2. 预案操作简洁:所有的预案操作都有有简洁明确(开关型)的操作输入 。
3. 预案操作安全:所有预案要经过充分预演,同时预演操作本身需要有明确的确认机制,以确保在正常情况下不会被误触发 。
4. 预案影响:明确理清预案操作的影响,QA在预演阶段需要对相关影响进行充分验证 。
此次活动的前期筹备中,我们总计进行了3次直播全链路的拟真演练,以及2次联合互动现场、导播台现场的活动全流程级别的彩排,另外进行了大大小小总计数十次的各类风险预案演练 。所有演练过程中发现的问题,都会进行专项解决 。
风险预案这块,包含了各类资源故障、上下行链路质量、地区性网络故障、CDN异常流量水位等在内的场景应对,其中资源故障包含了机器宕机、机架整体断电、堆叠交换机宕机、机房外网出口不可用,我们均进行了风险预案演练覆盖 。下面列举几点网易云信大型直播解决方案中的部分预案机制:
l 如果因为误操作等导致非正常解密等,网易云信可在推流不中断的情况下,动态中止流加密,客户端无任何感知影响 。
l 某家cdn在某地区运营商出现大面积故障瘫痪,该地区相应运营商线路的QoS指标会大幅度下降并触发报警,网易云信将故障cdn在该地区运营商进行黑名单处理,动态停止对其的调度,将流量调度至正常提供服务的cdn厂商 。
l 在两路热流均正常的情况下,但是正在分发的一路出现质量问题,方案可支持手动触发主备切换,让监控数据质量更好的另一路流参与分发,客户端感知时间在1s以内 。
l 因为一些不可抗因素,某机房出现大面积故障整体不可用,触发链路报警,此时我们会紧急将流切至另一机房,故障感知与恢复的时间在一分钟内 。


推荐阅读