Netflix

作者：Zhi Li、Anne Aaron、Ioannis Katsavounidis、Anush Moorthy 和 Megha Manohara 术语缩写DLM - Detail Loss Metric 细节损失指标DMOS - Differential Mean Opinion Score 差分均匀意见分数DSIS - Double Stimulus Impairment Scale 双刺激伤害量表SVM - Support Vector Machine 反对向量机VIF - Visual Information Fidelity 视觉信息保真度VMAF - Video Multimethod Assessment Fusion 视频多办法评估交融 缘起在 Netflix，咱们关怀视频品质，咱们关怀大规模精确测量视频品质。咱们的办法：视频多办法评估交融 (VMAF)指数，旨在反映观众对咱们的流媒体品质的认识。咱们正在开源这个工具，并邀请钻研界与咱们单干实现这个重要的我的项目。 咱们对高质量视频的谋求咱们致力为咱们的会员提供杰出的观看体验：晦涩的视频播放，无宜人的画面伪影。思考到网络带宽和观看设施的限度，这项工作的一个重要局部是提供具备最佳感知品质的视频流。咱们通过多种致力一直朝着这个指标致力。 首先，咱们在视频编码畛域进行了翻新。流式视频须要应用 H.264/AVC、HEVC 和 VP9 等规范进行压缩，以便以正当的比特率进行流式传输。当视频压缩过多或不正确时，这些技术会引入品质侵害，称为压缩伪影。专家将它们称为“块效应”、“振铃效应”或“蚊子乐音”，但对于一般观众来说，视频看起来并不正确。为此，咱们定期比拟编解码器供应商的压缩效率、稳定性和性能，并整合市场上最好的解决方案。咱们评估不同的视频编码标准，以确保咱们始终处于压缩技术的前沿。例如，咱们在 H.264/AVC、HEVC 和 VP9 之间进行比拟，凋谢媒体联盟(AOM) 和联结视频摸索团队(JVET)。即便在既定规范内，咱们也会持续试验配方决策（参见 Per-Title 编码优化我的项目）和速率调配算法，以充分利用现有工具集。 咱们在基于云的分布式媒体管道中对 Netflix 视频流进行编码，这使咱们可能扩大以满足业务需要。为了最大限度地缩小不良源交付、软件谬误和云实例的不可预测性（瞬态谬误）的影响，咱们在管道中的各个点主动进行品质监控。通过这种监控，咱们试图在采集和管道中的每个转换点检测视频品质问题。 最初，当咱们在 Netflix 生态系统的各个领域（例如自适应流媒体或内容交付网络算法）进行迭代并运行 A/B 测试时，咱们致力确保通过零碎改良来维持或进步视频品质。例如，旨在缩小播放开始提早或从新缓冲的自适应流算法的改良不应升高流会话中的整体视频品质。 上述所有具备挑战性的工作都取决于一个基本前提：咱们能够精确无效地测量大规模视频流的感知品质。传统上，在视频编解码器的开发和钻研中，有两种办法被宽泛用于评估视频品质：1) 视觉主观测试和 2) 简略指标的计算，例如 PSNR，或者最近的 SSIM [1]。 ...

1、服务发现: Eureka Clients1.1. 怎么样成为Eureka客户端1.2. 注册为Eureka1.3. Authenticating with the Eureka Server1.4. Status Page and Health Indicator1.5. Registering a Secure Application1.6. Eureka’s Health Checks1.7. Eureka Metadata for Instances and Clients1.7.1. Using Eureka on Cloud Foundry1.7.2. Using Eureka on AWS1.7.3. Changing the Eureka Instance ID1.8. Using the EurekaClient1.8.1. EurekaClient without Jersey1.9. Alternatives to the Native Netflix EurekaClient1.10. Why Is It so Slow to Register a Service?1.11. Zones2. Service Discovery: Eureka Server2.1. How to Include Eureka Server2.2. How to Run a Eureka Server2.3. High Availability, Zones and Regions2.4. Standalone Mode2.5. Peer Awareness2.6. When to Prefer IP Address2.7. Securing The Eureka Server2.8. JDK 11 Support3. Circuit Breaker: Hystrix Clients3.1. How to Include Hystrix3.2. Propagating the Security Context or Using Spring Scopes3.3. Health Indicator3.4. Hystrix Metrics Stream4. Circuit Breaker: Hystrix Dashboard5. Hystrix Timeouts And Ribbon Clients5.1. How to Include the Hystrix Dashboard5.2. Turbine5.2.1. Clusters Endpoint5.3. Turbine Stream6. Client Side Load Balancer: Ribbon6.1. How to Include Ribbon6.2. Customizing the Ribbon Client6.3. Customizing the Default for All Ribbon Clients6.4. Customizing the Ribbon Client by Setting Properties6.5. Using Ribbon with Eureka6.6. Example: How to Use Ribbon Without Eureka6.7. Example: Disable Eureka Use in Ribbon6.8. Using the Ribbon API Directly6.9. Caching of Ribbon Configuration6.10. How to Configure Hystrix Thread Pools6.11. How to Provide a Key to Ribbon’s IRule7. External Configuration: Archaius8. Router and Filter: Zuul8.1. How to Include Zuul8.2. Embedded Zuul Reverse Proxy8.3. Zuul Http Client8.4. Cookies and Sensitive Headers8.5. Ignored Headers8.6. Management Endpoints8.6.1. Routes Endpoint8.6.2. Filters Endpoint8.7. Strangulation Patterns and Local Forwards8.8. Uploading Files through Zuul8.9. Query String Encoding8.10. Request URI Encoding8.11. Plain Embedded Zuul8.12. Disable Zuul Filters8.13. Providing Hystrix Fallbacks For Routes8.14. Zuul Timeouts8.15. Rewriting the Location header8.16. Enabling Cross Origin Requests8.17. Metrics8.18. Zuul Developer Guide8.18.1. The Zuul Servlet8.18.2. Zuul RequestContext8.18.3. @EnableZuulProxy vs. @EnableZuulServer8.18.4. @EnableZuulServer Filters8.18.5. @EnableZuulProxy Filters8.18.6. Custom Zuul Filter ExamplesHow to Write a Pre FilterHow to Write a Route FilterHow to Write a Post Filter8.18.7. How Zuul Errors Work8.18.8. Zuul Eager Application Context Loading9. Polyglot support with Sidecar10. Retrying Failed Requests10.1. BackOff Policies10.2. Configuration10.2.1. Zuul11. HTTP Clients12. Modules In Maintenance Mode

Spring Cloud Netflix Eureka - 隐藏手册介绍在2015-2016，我们将单体应用程序重新设计为微服务，并选择Spring Cloud Netflix作为基础。（Spring Cloud Netflix）通过自动配置, Spring 环境以及其他 Spring 编程模型习惯用法为 SpringBoot 应用程序提供 Netflix OSS 开源软件集成。时间流逝，我们逐渐对框架更加熟悉，甚至还贡献了一些代码。我认为我已经知道了够多了, 便开始研究 Eureka 冗余和故障转移。一个概念的快速证明不起作用，当我挖掘更多时，我遇到了其他可怜的灵魂在互联网上搜索类似的信息。不幸的是, 找不到啥。值得赞扬的是，Spring Cloud 文档相当不错，而且还有 Netflix Wiki，但没有一个达到我想要的详细程度。这篇文章试图弥合这一差距。我假设您对 Eureka 和服务发现有一些基本的了解，所以如果您是新手，请在阅读 Spring Cloud 文档后再回来。基础架构Netflix 的高级架构，遵循 Apache License v2.0 许可。Eureka 有两个基本组件，服务器和客户端。引用 Netflix Wiki：Eureka 是一种基于 REST（Representational State Transfer）的服务，主要用于 AWS 云，用于定位服务，以实现中间层服务器的负载均衡和故障转移。我们将此服务称为 Eureka Server。Eureka 还附带了一个基于Java 的客户端组件 Eureka Client，它使与服务的交互变得更加容易。客户端还有一个内置的负载均衡器，可以进行基本的循环负载均衡。Eureka 客户端应用程序称为实例。客户端应用程序和 Eureka 客户端之间存在细微差别; 前者是您的应用程序，后者是框架提供的组件。Netflix 设计的 Eureka 具有高度动态性。有一般属性，也有一些专门属性用于定义了在一般属性的更新查询时间间隔。这是一种常见的做法，这意味着大多数这些属性可以在运行时更改，并在下一个刷新周期中被感知。例如，客户端用于向 Eureka 注册的 URL 可以更改，并在5分钟后被感知（可配置eureka.client.eurekaServiceUrlPollIntervalSeconds ）。大多数用户不需要这样的动态更新，但如果你想这样做，可以找到所有配置选项，如下所示：对于 Eureka 服务器配置：org.springframework.cloud.netflix.eureka.server.EurekaServerConfigBean 实现com.netflix.eureka.EurekaServerConfig。所有属性都具有eureka.server 前缀。对于 Eureka 客户端配置：org.springframework.cloud.netflix.eureka.EurekaClientConfigBean 实现 com.netflix.discovery.EurekaClientConfig。所有属性都有 eureka.client 前缀。对于Eureka实例配置：org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 实现（间接）com.netflix.appinfo.EurekaInstanceConfig。所有属性都有 eureka.instance 前缀。有关更多体系结构的详细信息，请参阅 Netflix Wiki。Eureka实例和客户在 Eureka 中通过 eureka.instance.instanceId 识别实例, 如果不存在则用eureka.instance.metadataMap.instanceId。实例发现彼此使用 eureka.instance.appName，该值在 Spring Cloud 默认使用 spring.application.name 或者 UNKNOWN 如果前者未定义。您需要进行设置，spring.application.name 因为具有相同名称的应用程序在 Eureka 服务器中聚集在一起。不需要设置eureka.instance.instanceId，因为它默认值设置为 CLIENT IP:PORT，但如果你想设置它，则appName必须在集群范围内是唯一的。还有一个 eureka.instance.virtualHostName，但它没有被 Spring 使用，并且设置为 spring.application.name 或 UNKNOWN 如上所述。如果 registerWithEureka 是 true，则实例使用给定的 URL 向 Eureka 服务器注册; 然后，它每30秒发送一次心跳（可配置 eureka.instance.leaseRenewalIntervalInSeconds）。如果服务器没有收到心跳，则在eureka.instance.leaseExpirationDurationInSeconds 从注册表中删除实例之前等待90秒（可配置），然后禁止该实例的流量。发送心跳是一项异步任务; 如果操作失败，则以指数方式后退2倍，直到eureka.instance.leaseRenewalIntervalInSeconds * eureka.client.heartbeatExecutorExponentialBackOffBound 达到最大延迟。注册 Eureka 的重试次数没有限制。心跳与将实例信息更新到 Eureka 服务器不同。每个实例都由 com.netflix.appinfo.InstanceInfo 表示，它是关于实例的一堆信息。它将 InstanceInfo 会定期发送到Eureka 服务器，从启动后40s开始（可配置eureka.client.initialInstanceInfoReplicationIntervalSeconds），然后每30秒开始一次（可配置eureka.client.instanceInfoReplicationIntervalSeconds）。如果 eureka.client.fetchRegistry 是 true，则客户端在启动时获取 Eureka 服务器注册表并在本地进行缓存。从那时起，它只是获取增量（这可以通过设置来关闭 eureka.client.shouldDisableDelta 到 false，尽管这会是浪费带宽）。注册表获取是每30秒调度一次的异步任务（可配置eureka.client.registryFetchIntervalSeconds）。如果操作失败，则按指数2倍后退，直到eureka.client.registryFetchIntervalSeconds * eureka.client.cacheRefreshExecutorExponentialBackOffBound 达到最大延迟。获取注册表信息的重试次数没有限制。客户端任务由 com.netflix.discovery.DiscoveryClient 安排, 这个类是对 Spring Cloud 的org.springframework.cloud.netflix.eureka.CloudEurekaClient 的扩展实现。为什么用 Eureka 实例需要这么长时间？大部分都是从spring-cloud-netflix＃373复制而来的。客户注册第一次心跳在启动后发生30s（如前所述），因此实例在此间隔之前不会出现在 Eureka 注册表中。服务器响应缓存服务器维护一个每30秒更新一次的响应缓存（可配置 eureka.server.responseCacheUpdateIntervalMs）。因此，即使实例刚刚注册，它也不会出现在对 /eureka/apps REST 端点的调用结果中。但是，实例可能会在注册后出现在 Eureka Dashboard 上。这是因为仪表板绕过了 REST API 使用的响应缓存。如果您知道instanceId，您仍然可以通过调用从 Eureka 获取有关它的一些详细信息/eureka/apps/<appName>/<instanceId>。此端点不使用响应缓存。因此，其他客户端可能需要另外30秒来发现新注册的实例。客户端缓存刷新Eurekac客户端维护注册表信息的缓存。此缓存每30秒刷新一次（如前所述）。因此，在客户端决定刷新其本地缓存并发现其他新注册的实例之前，可能还需要30秒。LoadBalancer 刷新Ribbon 使用的负载均衡器从本地 Eureka 客户端获取其信息。Ribbon 还维护一份本地缓存，以避免为每个请求调用客户端。此缓存每30秒刷新一次（可配置 ribbon.ServerListRefreshInterval）。因此，在 Ribbon 可以使用新注册的实例之前可能还需要30秒。最后，在新注册的实例开始接收来自其他实例的流量之前，可能需要2分钟。Eureka 服务器Eureka 服务器具有对等感知模式，在该模式下，它跨其他 Eureka 服务器复制服务注册表，以提供负载平衡和弹性。对等感知模式是默认模式，因此 Eureka 服务器也充当 Eureka 客户端向对等体上注册给定的 URL。这就是你应该如何在生产中运行 Eureka，但是对于演示或概念验证，你可以通过设置 registerWithEureka 为 false 采用独立模式运行。当 Eureka 服务器启动时，它会尝试从对等的 Eureka 节点获取所有注册表信息。对每个对等体重试此操作5次（可配置 eureka.server.numberRegistrySyncRetries）。如果由于某种原因此操作失败，则服务器不允许客户端获取注册表信息5分钟（可配置 eureka.server.getWaitTimeInMsWhenSyncEmpty）。Eureka 的对等感知意识，通过所谓的“自我保护”的概念引入一个全新水平的复杂性（可以通过设置eureka.server.enableSelfPreservation 为 false 来关闭）。事实上，在网上看，这是我看到大多数人绊倒的地方。来自 Netflix Wiki：当 Eureka 服务器启动时，它会尝试从相邻节点获取所有实例注册表信息。如果从某个节点获取信息时出现问题，服务器会尝试所有对等体直到放弃。如果服务器能够成功获取所有实例，则会根据该信息设置应接收的续订阈值。如果有任何时间，续订低于为该值配置的百分比，则服务器会停止使用实例过期机制, 以保护当前实例注册表信息。数学运算如下：如果有两个客户端注册到 Eureka 实例，每个客户端每30秒发送一次心跳，该实例应该在一分钟内收到4次心跳。Spring 为此添加了一个较低的最小值1（可配置eureka.instance.registry.expectedNumberOfRenewsPerMin），因此实例希望每分钟接收5个心跳。然后将其乘以0.85（可配置eureka.server.renewalPercentThreshold）并四舍五入到下一个整数，这使我们再次回到 5。如果 Eureka 在15分钟内收到的心跳少于5次（可配置 eureka.server.renewalThresholdUpdateIntervalMs），它将进入自我保护模式并不再让已经注册的实例过期。Eureka 服务器隐含假设客户端以每30秒固定的速率发送心跳。如果注册了两个实例，则服务器希望(2 2 + 1 ) 0.85 = 5每分钟都接收一次心跳。如果续订率低于此值，则激活自保护模式。现在，如果客户端发送心跳的速度要快得多（例如，每隔10秒），则服务器每分钟接收12次心跳，并且即使其中一个实例发生故障，也会持续接收6次/分钟。因此，即使应该是自保护模式也不会被激活。这就是改变 eureka.client.instanceInfoReplicationIntervalSeconds 不可取的原因。如果必须的话, 你可以修改一下 eureka.server.renewalPercentThreshold 的值。Eureka 对等实例不考虑预期的续约数量，但他们的心跳被计入在最后一分钟收到的续约数量。在对等感知模式下，心跳可以转到任何 Eureka 实例; 这在运行负载均衡器或 Kubernetes 服务后很重要，其中心跳以循环模式（通常）发送到每个实例。在更新超过阈值之前，Eureka服务器不会退出自我保护模式。这可能导致客户端获取不再存在的实例。请参阅了解Eureka Peer to Peer Communication.还有一件事：在同一主机上运行多个 Eureka 服务器。Netflix 代码（com.netflix.eureka.cluster.PeerEurekaNodes.isThisMyUrl）过滤掉同一主机上的对等 URL。这可能是为了防止服务器注册为自己的对等体（我在这里猜测），但由于它们不检查端口，因此除非 Eureka 主机名eureka.client.serviceUrl.defaultZone 不同，否则对等感知不起作用。这种情况的Hack解决方法是定义唯一的主机名，然后在/etc/hosts文件（或它的Windows等价物）将它们映射到 127.0.0.1 了。Spring Cloud doc讨论了这种解决方法，但没有提到为什么需要它。现在你知道了。区域和可用区域AWS Regions 和可用 Zones。Eureka 旨在在 AWS 中运行，并使用许多特定于 AWS 的概念和术语。Regions 和 Zones 是两个这样的东西。来自 AWS doc：Amazon EC2 托管在全球多个地点。这些位置由 Regions 和可用 Zones 组成。每个地区都是一个独立的地理区域。每个区域都有多个孤立的位置，称为可用Zones…每个区域都是完全独立的。每个可用 Zones 都是隔离的，但区域中的可用 Zones 通过低延迟链接连接。Eureka 仪表板显示环境和数据中心。的值被分别设置为 test 与 default，通过使用com.netflix.config.ConfigurationManager 设置 org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap。有各种查找和回退，因此如果由于某种原因需要更改它们，请参阅上述类的源代码。Eureka 客户端默认情况下更喜欢相同的区域（可配置eureka.client.preferSameZone）。来自com.netflix.discovery.endpoint.EndpointUtils.getServiceUrlsFromDNS Java doc：从DNS获取所有 Eureka 服务 URL 的列表，以便 Eureka 客户端与之交谈。客户端从其区域中获取服务 URL，然后随机故障转移到其他区域。如果同一区域中有多个服务器，则客户端会再次随机选择一个服务器。这样，流量将在发生故障时分发。Ticket spring-cloud-netflix＃203 在撰写本文时是开放的，其中有几个人谈论 Regions和 Zones。我没有验证，所以我无法评论Regions和 Zones如何与 Eureka一起使用。高可用性（HA）大部分都是从 spring-cloud-netflix＃203 中复制而来的。HA 策略似乎是一个主要的 Eureka 服务器（server1）与备份（server2）。通过配置（或 DNS 或 /etc/hosts）向客户端提供 Eureka 服务器列表客户端尝试连接server1; 在这一点上，server2坐着闲着。如果server1不可用，客户端将从列表中尝试下一个。当server1重新上线时，客户端会重新使用server1。当然server1，server2可以在对等感知模式下运行，并且可以复制其注册表。但这与客户注册正交。 ...

有个很常见问题是：“为什么需要机器学习来提高流媒体质量？”这是一个非常重要的问题，在这篇文章中，Netflix描述了视频流所面临的一些技术挑战，以及如何通过统计模型和机器学习技术来克服这些挑战。Netflix现在在全球拥有超过11700万名会员。超过一半的成员居住在美国以外的地方，为全球观众提供高质量的流媒体体验是一项巨大的技术挑战。其中很大一部分是在全球范围内安装和维护服务器所需的工作，以及用于将内容从这些服务器流式传输到用户设备的算法。随着Netflix迅速扩展到具有不同观看行为的观众，在具有各种功能的网络和设备上运行，流媒体视频的“一刀切”解决方案变得越来越不理想。举个例子：移动设备上的查看/浏览行为与智能电视上的不同蜂窝网络可能比固定宽带网络更不稳定某些市场中的网络可能会遇到更高程度的拥塞由于硬件之间的差异，不同的设备组具有不同的互联网连接能力和保真度。Netflix需要针对这些不同的，经常波动的条件调整方法，以便为所有会员提供高质量的体验。在Netflix会实时观察网络和设备状况以及能够为每个会话提供的用户体验（例如视频质量），使Netflix能够在此领域利用统计建模和机器学习。以下是我们在设备方面面临的一些技术挑战。网络质量特性和预测网络质量是比较难以预测的。虽然网络支持的平均带宽和返回时间是众所周知的网络质量指标，但其他特性（如稳定性和可预测性）在视频流方面有很大差异。对网络质量进行更丰富的特性分析将有助于分析网络（用于定位/分析产品改进），确定初始视频质量/或在整个回放过程中调整视频质量（更多内容见下文）。以下是在真实观看会话期间测量的网络吞吐量的一些示例。可以看到它们非常嘈杂并且在很大范围内波动。在最近15分钟的数据中，可以预测未来15分钟的吞吐量会是什么样的。我们如何整合有关网络和设备的长期历史信息？我们可以从服务器提供哪种数据，以让设备能够以最佳方式进行调整？即使我们无法准确预测网络丢失何时会发生（突发情况众多），我们是否至少可以特定分析吞吐量的分布我们希望看到给定的历史数据？由于Netflix正在大规模地观察这些数据，因此有可能建立更复杂的模型，将时间模式识别与各种上下文指标相结合，以更准确地预测网络质量。如何判断一个网络预测的APP是否有用，其中一个重要标准就是他能够帮助我们在播放期间调整视频质量，下文会具体讲述。播放期间的视频质量自适应电影和电视节目通常以不同的视频质量编码来支持不同的网络和设备功能。 自适应流媒体算法会根据当前网络和设备条件来调整在整个回放过程中流式传输的视频质量。下图说明了视频质量自适应的设置。 我们是否可以利用数据来确定优化体验质量的视频质量？其实可以通过多种方式测量用户体验的质量，包括等待视频播放所花费的初始时间，用户体验的整体视频质量，播放暂停以将更多视频加载到缓冲区的次数（“rebuffer”） ，以及播放期间可察觉的质量波动量。上面是视频质量适应问题的插图。 视频以不同的质量编码（在这种情况下有3种品质：绿色高，黄色中等，红色低）。 视频的每个质量版本被划分为固定持续时间的块（灰色框）。 决定为下载的每个块选择哪种质量。这些指标可以相互折衷：我们可以选择积极主动并传输高质量的视频，但会增加rebuffer的风险。 或者我们可以选择预先下载更多视频，并以增加等待时间为代价来降低rebuffer风险。 用户决策的反馈信号一般是延迟的同时也会比较少。 例如，积极切换到更高质量可能不会立即产生影响，但可能逐渐耗尽缓冲区并最终导致某些情况下的rebuffer事件。 当学习最优控制算法时，这种“信用分配”问题是众所周知的挑战，而机器学习技术具有解决这些问题的巨大潜力。预测性缓存统计模型可以改善流媒体传输体验的另一个方式是预测用户将播放的内容，以便在用户点击播放之前将全部或者部分内容缓存在设备上，从而使视频能够更快地启动或以更高的质量启动。 例如，一直在观看特定剧集的用户很可能会播放下一个未观看过的剧集。 通过将他们的观看历史的各个方面与最近的用户交互和其他上下文变量相结合，可以将其制定为监督学习模型，通过这个学习样本，我们希望最大可能性模拟用户缓存可能性以及他最后可能在哪个内容节点上结束观看，同时注意缓存以及带宽的资源约束。 Netflix已经看到在使用预测缓存模型以后用户等待视频开始所花费的时间大幅减少。设备异常检测Netflix可在超过一千种不同类型的设备上运行，从笔记本电脑到平板电脑，从智能电视到手机。新设备不断进入这个生态系统，现有设备通常会更新其固件或与Netflix应用程序中的更改进行交互。这些通常没有障碍但是在很容易引起用户体验问题 - 例如，应用程序将无法正常启动，或者播放的视频质量被降级。此外，随着时间的推移，设备质量也会逐渐增加。例如，连续的UI改版可能会逐步降低特定设备上的性能。检测这些变化是一个极具挑战同时劳动密集型的工作。Alerting frameworks 可以帮我们去抓取或者发现一些潜在问题，但是一般情况下这些潜在问题却很难被界定为是个特别实际需要去解决的问题。“liberal”触发器可能引发很多误报，导致团队进行大量不必要的手动调查，但是非常严格的触发可能会错过真正的问题。但是事实上我们可以将过往触发警报的历史，以及对应问题梳理出来。然后我们可以使用它来训练一个模型，这个模型可以用来预测在一定测量条件造成事故的可能性。即便我们确信在观察的情况一定是个bug存在，但确定根本原因通常也很困难。发生这个事故的原因是是因为特定ISP还是特定地区的网络质量波动？是因为内部A B test？还是因为设备制造商发布的固件更新？如果可以通过统计建模还可以通过控制各种协变量来帮助我们确定根本原因。从Netflix成功实践来看，通过采用预测建模来做设备异常检测，我们已经看到整体警报量大幅减少，同时保持可接受的低错误率，极大提高了我们团队的效率。统计建模和机器学习方法可以大幅度改善现有技术水平，但依然会有很多困难要去客服：数据量巨大（全球超过11700万成员）数据是高维的，并且很难为特定问题手工制作最小的信息变量集数据中结构异常丰富，因为本身产品带来复杂情况（例如偏好，设备硬件水平）为了在在日益多样化的网络和设备条件下传输视频，解决这些问题将是Netflix的战略核心。本篇文章翻译自【Netflix Techblog】，想要获取更多产品干货、技术干货，记得关注网易云信博客。