近日，Mux 与 Touchstream、Datazoom 以及 Fastly 联合发布了一份白皮书，其中部分内容详细讨论了如何完美的举行如超级碗、世界杯等大规模赛事的直播活动。

文 / Mux

译 / 汤宸宇

原文 / https://mux.com/blog/white-pa…

1) 监控 QoE，做出准确的判断

当我们在直播一场大规模地活动时，需要深入地了解观看直播的用户的体验——这就是所谓的用户体验质量(QoE)。这不仅仅是综合监控与服务质量(QoS)，我们可以处理和聚合每一份 CDN 日志，以及来自编码器、打包程序和存储的每一项数据，但这并不能准确地反映观众正此时的实际体验，在用户当前使用的设备上收集指标是获得真实用户体验数据的唯一方式。

QoE 工具如 Mux Dat 等能够支持实时监视用户的体验。它不仅仅能让我们查看用户体验的变化情况，而且还能帮助我们深入了解产生这些变化的根本原因。

一般来说，现场活动直播需要关注的 5 个关键指标是：

1. 播放失败率——观众流失败的比率是多少?

2. 开播前退出率——在播放开始前，观众关闭页面或应用程序的比率是多少?

3. 再缓冲率——用户缓冲的频率，缓冲的时间如何?

4. 视频启动时间——需要多长时间视频才能开始播放?

5. 同时观看人数——在特定的时间段内有多少人在同时观看直播?

其中，“同时观看人数”在技术上并不是一个 QoE 指标而是一个用来衡量参与度的指标，但是它非常重要。尽管其他指标在监视体验质量时应该被关注，但我们认为“同时观看人数”是直播时应被时刻关注的重要指标，而这些都能够在 Mux 数据仪表板上实时显示。

这些指标中的任何一个出现尖峰或低谷都表明传输链的某个地方存在问题——但这只反映在堆栈中发生的一些变化带来的影响。要真正理解发生了什么变化，我们得深入到图表中的每一个数据点来查明问题所在：问题是由于一个特定的 ISP？一个特定的 CDN？还是一个特定的设备？没有快速深入检索分析 QoE 数据的能力，就无法如我们所愿地对任何明显更改做出明智的决策——例如将更多的观众路由到另一个 CDN。

一个优秀的 QoE 工具不应该只是跟踪这些数据点，更应该以一种企业里所有人都能理解的方式呈现这些数据——为最重大的直播活动构建一个“战情室”是十分必要的。“战情室”是运营大型活动必不可少的关键，一个优秀的、易于理解的 QoE 工具可以促进客户支持、运营和工程团队在战情室中的协同工作。最好的 QoE 工具还能够让我们以编程方式实时访问这些数据，并且能够根据来自观众的数据进行 multi-CDN 切换等操作。

展望下一代的 QoE 工具，我们期望看到 QoE 数据收集点分散在整个媒体拍摄制作与传输的工作流中，就像现有的 QoS 工具已经开始探索的那样。这将有助于 VMAF、SSIM 或 PSNR 等对参考图片质量进行的自动分析的落地以及对音频 / 视频同步的无监督验证，从而始终保持从源到最终用户设备的体验质量。

2) 根据内容和观众调整 ABR 编码阶梯

虽然 per-title 的解决方案正在成为按需视频流的标准，我们仍然需要一个从统一方法过渡到 per-scene 的编码策略，该策略可以很好地进行跨平台实时视频流。而优化的 ABR 编码阶梯也至关重要。

对于大规模的流媒体直播活动，我们有机会在活动之前根据测试内容计划 ABR 编码阶梯——从编码器的角度看，根据之前的比赛内容优化下一张比赛的 ABR 编码阶梯十分必要。

然而，在 2019 年及以后，我们应该更深入地了解内容，从内容角度决定 ABR 阶梯应该是什么样的。我们需要知道观众是如何浏览内容的，从而对阶梯布局做出有根据的决定——这包括考虑基于观众的带宽能力分布以及他们正在观看的设备情况。

好消息是，做出这些决策所需要的数据点与监视体验质量而观察的数据点是一样的——如果我们能够正确地分析数据，在直播中根据合适条件判断 ABR 编码阶梯策略，我们就能够做出一些更加明智的决定。在接下来的几年里，我们还是希望看到更多解决方案的出现，以实现能够随着观众观看条件的变化灵活改变的 ABR 编码阶梯。

3) 利用 multi-CDN 保护源

在重要直播活动的业务中使用单个 CDN 的日子已经结束了。客户期望的是在处于任何地理位置的任何平台上，任何事件的任何一秒钟都能完美地传输。这对于单个 CDN 供应商来说是不可能的。众所周知，一些 CDN 在某些区域和某些 IPS 中表现得很好，而另一些 CDN 在其它一些区域表现得更好。除此之外，使用 multi-CDN 能够在特定范围内大幅度提升传输系统对一个或多个 CDN 合作伙伴的容错性。

现代 multi-CDN 解决方案的体系结构非常强大——例如 Citrix(启用前原名 Cedexis)智能交通管理平台，可以利用来自各种数据源的数据 (包括 Mux 的数据!) 高精度地控制请求路由，从而实现将分段请求在精确的时刻路由到对于终端用户最好的 CDN 上。这就是所谓的“Mid-stream”CDN 交换，它能使请求绕过特定 ISP 或窄点上的拥塞，以及常见的 CDN 故障。然而，multi-CDN 和 CDN 切换面临着两大挑战——成本和原点缩放。

成本: 当选择使用多个 CDN 时，现有的成本模型将受到两大挑战。首先，与特定 CDN 协商数据速率的能力将受到限制。随着提交量的增加，大多数 CDN 在定价上更加灵活，所以当使用更多的 CDN 时，CDN 在大容量上提交的能力就受到了限制；另一个更大的挑战来自原始数据的输出空间。因为有更多的 CDN 回到原点，这将导致成倍的数据从那个点出去。与 edge delivery 相比，每 GB 的数据输出速率往往要高出一个数量级。

同样值得注意的是，使用多个 CDN 会产生巨大的财务成本，同时，团队对其的管理与操作也会产生巨大的操作开销。这种人力成本不应该被低估，当我们决定在大型活动中使用多少 CDN 合作伙伴时，应该考虑到这一点——请记住，团队规模可能是一个限制因素。

原点缩放：由于现在有多个 CDN 返回到原点来查找缓存丢失，原点需要适当的进行缩放。起初，这听起来并不是个大问题，但如果原始版本需要扩展 5 倍(如果使用 5 个 edge CDNs)，这将变得非常昂贵，并为这些服务引入新的扩展挑战。

值得庆幸的是，针对这些挑战有一个越来越流行的解决方案——利用 origin shield。origin shields 是位于 CDN 和源之间的缓存层，在源级别将来自多个 edge CDN 的传入请求折叠成一个请求。Fastly 的 Media Shield 是一个很棒的产品，它是目前为数不多的完全支持构建 origin Shield 的解决方案之一。一个好的 origin shield 可以减少 70% 到 80% 的源负载，即使它前面有一个性能良好的 edge CDN。

利用 originshield 的最大问题是会在传输基础设施中引入单个或少量故障点。我们应该通过测试找到减轻这种风险的最好方法——可能包括将 CDN 原点请求分成两个 shield 数据中心而不是一个，或一个自动或手动回退策略，也就是在 origin shield 的失败的情况下，CDN 将会切换至使用直接传输端口。

4) 拥有冗余设计的内容摄取、编码和传输路径

正如我们所讨论的，multi-CDN 对于传输大规模实时事件至关重要，但是 multi-CDN 只在传输的最后一英里出现故障时提供帮助。对于大规模的直播活动，我们需要为高弹性构建端到端流堆栈。这意味着从编码器、存储到打包程序、网络链接以及能想到的所有流程环节步骤都需要加入冗余设计。

受限于活动的规模，冗余设计显然是有限制的。我们会为 CEO 圆桌会议租用多余的卫星上传链路和发电机吗？可能不会！那如果是为了超级碗或者世界杯？完全必要！

在网络冗余设计方面，控制流量并合理路由是一件十分困难的事情，而摄取的过程也充满挑战。虽然可能有两个冗余的编码器，但是如果我们不能通过不同的 Internet 路径将输入的数据传输到它们，那么我们就无法解决网络中断或拥塞问题。通常，最好的解决方案是在信号发出时与不同的供应商建立多个光纤连接，并确保它们通过不同的 Internet 交换到达最终目的地。

对于编码器冗余设计，同步它们的时间码并锁定输入是很重要的。冗余的编码器需要采用相同编码决策，从而使得来自编码器 A 和编码器 B 的片段有一段连续时间码和 B / P 帧引用能够按需切换，在编码链被改变时观众不会有视觉不连续的体验。

如果要在云上构建主工作流，一定要记住需要在不同的区域 (而不仅仅是可用性区域) 运行冗余编码器、打包程序和存储。值得庆幸的是，大多数现代云平台都提供了简单的工具来实现这一点，但是要小心——有些云产品可能存在地区限制，企业在评估供应商时一定要检查这一点!

我们在业界看到的一种比较流行的方法是充分利用跨区域的打包和存储架构，其中每个编码器不仅将视频块输出到自己的区域，还输出到冗余区域，反之亦然。这种冗余设计非常棒，因为这能够通过打包程序访问来自冗余区域的内容从而构建一个完全冗余的打包链。

如果您已经构建了一个完全冗余的流程链，那就太好了！但是不应该在出现故障时才第一次使用它——如果有两个冗余链，那么在平时的使用中我们应该平衡两条链之间所有观众的负载。这不仅能够确保冗余服务按预期工作，还能够为每个冗余区域保持缓存的活跃，以保证当突发故障出现需要转移工作链路时系统不会遭受级联故障。

5) 建立并促进合作共赢的供应商关系

供应商关系是建立可靠灵活直播业务的基础，需要注意的有以下几个部分。

首先，在最基本的层面上，供应商关系需要合作而不是竞争。双方都需要明白在大规模的现场活动中彼此处在一种合作双赢的局面。这可能是一个具有挑战性的情况，因为说到底这些都是业务关系，而成本在建立关系的过程中扮演着重要角色。一般来说，将成本谈判与正在进行的工程关系分离是一个好主意，这能确保工程级别的协作交互万无一失，而这对大规模直播活动的成功而言至关重要。

其次，对于大型活动，可能会有多个提供相同服务的供应商相互竞争（如果没有，想想刚才提到的第三点）。在比赛转播时，将这种共负盈亏的态度发展到传统厂商之间的竞争关系中是至关重要的。例如，当一个 CDN 供应商遇到特定 ISP 的问题时，迅速路由其流量到竞争对手以维护终端观众的 QoE 应该是可接受的。

第三，我们需要与供应商协调并积极推动直播活动。对于如何组织一个足够大的活动来吸引供应商，业界有各种各样的观点，一些人认为只有数以万计的观众人数有效，另一些人则认为千兆数字的流量更能吸引供应商。然而，对于大型且关键的直播业务，我们需要确保所有供应商都了解您的流量计划并在当天积极参与已建立的、经过测试的升级路由。

在某些情况下，购买 CDNs 的冗余容量是一个好主意，但如果不使用该容量，那么当需要冗余时代价可能会非常昂贵。同时，我们也很难准确地估计需求，因为随着网络环境变得拥挤，用户的带宽可能会突然改变，这使得所有的估计都没有意义。理解骨干网络上可能存在的关键点也很重要——这通常是 ISP 和交换供应商需要充分理解的事情。

如果我们已经成功地与供应商构建了良好的协作环境，那么我们更希望构建一个战情室环境来应对世界上最大规模的活动直播。我们应该让来自所有供应商的技术代表在同一个房间中一起工作来解决问题，同时我们应该监视供应商的服务。需要注意这是在同一间屋子里，所以培养人际关系非常重要，没有电话沟通，没有人互相交谈，房间里的每个人都想确保活动的成功。

6) 为最坏的情况制定应对方案

不管我们的应急保障机制和冗余模型设计得有多好，总有可能出现灾难性的错误。例如如果观众人数是预期的两倍，并且此时得知 CDN 合作伙伴无法处理该问题，那么我们该怎么办?

对于最坏的情况，如无法顺利地恢复传输流，我们应该有一个应对计划。正如 Donald Rumsfeld 曾经说过的，毕竟还有“未知的未知”。

我们可以通过一系列举措降低这些风险：当多个合作伙伴的带宽都耗尽时，如果需要我们应该准备降低直播视频的比特率——历史上许多大型直播事件都是这样解决临场出现的带宽资源不足问题，而随着我们进入超高清直播时代，这样的操作会愈来愈屡见不鲜。在一些超高清直播试验中，BBC iPlayer 等平台也曾尝试只让少数用户使用超高清版本的流媒体以确保其服务的所有用户的 QoE 都能得到保证。

随着低延迟流媒体将成为直播体育赛事的主导力量，我们很可能也会开始看到平台在大型赛事期间动态控制终端用户的延迟以提高负载时的缓存能力。特别是在未来几年中，低延迟方法的不断发展将不可避免地在可放缩性、延迟和实时体育赛事的弹性之间带来具有挑战性的权衡。

在这里，考虑客户端的行为也很重要。如果确实发生了灾难性的错误，服务在几秒钟或几分钟内运行了 500 次，应用程序将如何处理这种中断？当服务已经过载时，它会向服务发送请求吗？它会彻底让应用程序崩溃吗？对用户来说，它看起来只是缓冲吗？由于糟糕的客户端行为和已经陷入困境的 web 服务交互，许多大型软件的故障已经像滚雪球一样地增长，因此考虑这一点很重要。

如果出现服务宕机，还应该花时间考虑如何与用户进行沟通。很多平台都有服务状态页面，但是很多用户不知道在哪里可以找到它们。像 Twitter 和 Facebook 这样的平台也是与用户交流的好途径，但我们也应该考虑在应用程序内显示服务相关问题。设想用横幅的方式呈现：“不是您，是我们（的服务出现了问题）”。

7) 熟能生巧

当我们在进行世界上规模最大赛事的直播活动时，很难有机会去进行现场练习。在世界杯、超级碗、板球世界杯或英超决赛等重大赛事中，前几周的准备活动往往比正式的赛事要小一个数量级。

那么如何测试正式赛事的规模呢? 老实说，我们无法如我们所愿地实际测试第一层活动请求的数量。这并不是说负载测试不是构建大型业务关键视频平台的关键部分，它绝对是；但是以实际的规模测试达到所有 CDN 边缘是不现实的。但是，我们绝对可以使用大量公开可用的 SAAS 和自承载负载测试工具，以有参考价值的规模测试我们的源、origin shields 和编码器。

除此之外，我们能做的还有在小型直播活动中试错。

如果从未实践过这种行为，那么拥有完全冗余设计的传输链就没有任何意义。Netflix 在 2011 年首次谈到了“chaosmonkey”的概念，它会破坏云基础设施的组件用以测试冗余模式。虽然在实际应用中，一个可导致冗余编码链重启的应用程序可能看起来有点可怕，但“chaos monkey”将是行业未来几年的发展方向。在现实世界中，这可能不是我们现在想要其自动完成的事情，但是在筹备直播项目期间，手动测试弹性模型是非常重要的。

尝试测试添加冗余的每个点。如果有多个编码器，重新启动一个，流是否会冻结？用同样的方法处理包装器和 CDN。确保在组件发生实际故障时，流仍在继续运行。我们还应始终牢记，在执行此操作时，要密切关注物理流程环节来判断是否存在问题，而不是依赖于 QoE 的集中监视。虽然这些工具对于查看缓冲或分段获取失败等情况非常有效，但它们目前并不擅长检查视频帧内的视觉损坏，尤其是在 DRM 内容上。

虽然在实际事件上测试之前我们应该单独测试这一套方法，但是在任何准备事件中尝试这个方法都是非常有价值的，我们至少可以看到网络基础设施在某些负载下是如何恢复的。同样重要的是，要充分利用准备阶段或测试活动的机会，让团队熟悉他们将在比赛转播当天使用的工具和流程。杀死一个编码器是一个很好的测试，但是我们不应该让团队知道发生了什么，而是让他们检查监视、工具、运行本和流程，从而准确地找出出现故障的那个部分并妥善解决。