1 导言

在 Netflix，我们每月管理着上千个全球内容发布项目，每年的投资额高达数十亿美元。确保每部影片在我们平台上的成功和可发现性是我们的首要任务，因为我们的目标是将每个故事与合适的受众联系起来，让我们的会员满意。为了实现这一目标，我们致力于建立强大的系统，提供全面的可观察性，使我们能够对我们服务中的每个标题负全责。

2 可观测性的挑战

作为工程师，我们习惯跟踪错误率、延迟和 CPU 利用率等系统指标，但对标题的成功至关重要的指标呢？

不同的 Netflix 主页示例

主页样本 A：

样本主页 B：

对于一个基本的推荐系统，这两个示例页面可能看起来等同，只要浏览者观看顶部标题即可。但其实这两个页面却截然不同。每个标题都代表了无数小时的努力和创造，我们的系统需要尊重这种独特性。
咋弥合这种差距？咋才能设计出认识到这些细微差别的系统，让每个职称都能发光发热，为会员带来欢乐？

3 个性化系统的运行需求

Netflix Originals 的早期，我们的发布团队会在午夜时分聚集在一起，手动验证影片是否出现在所有正确的位置。虽然这种亲力亲为的方法对少数作品有效，但很快就发现它无法扩大规模。随着 Netflix 在全球范围内的扩张和片头发布量的激增，维持这种手动流程所带来的运营挑战已成为不争的事实。

在为全球流媒体服务运营个性化系统的过程中，需要处理大量有关特定时间和地点为何会出现或不会出现某些标题的询问，如：

• 为什么标题 X 没有显示在某个会员的 "即将推出 "行中？
• 为什么巴西的搜索页面缺少标题 Y？
• 标题 Z 是否按预期在所有产品体验中正确显示？

随着 Netflix 规模的扩大，我们面临着越来越大的挑战，即如何为有关标题性能和可发现性的日益复杂的查询提供准确、及时的答案。这导致了一套分散在各个团队的零散脚本、运行手册和临时解决方案–这种方法既无法持续，也不高效。

要确保每个标题都完美无瑕地发布，赌注就更大了。元数据和资产必须正确配置，数据必须无缝流动，微服务必须无差错地处理标题，算法必须按预期运行。这些操作需求的复杂性凸显了对可扩展解决方案的迫切需求。

4 自动化操作

随着时间的推移，我们逐渐发现，我们需要实现业务自动化，以便随着业务的扩展而扩展。当我们进一步思考这个问题和可能的解决方案时，出现了两个明确的选择。

4.1 日志处理

日志处理为监控和分析标题启动提供了直接的解决方案。通过记录所有标题的显示过程，我们可以处理这些日志以识别异常情况并深入了解系统性能。这种方法有以下几个优点：

1. 对现有系统造成的负担小：日志处理对现有基础设施的改动极小。通过利用常规操作中已经生成的日志，我们可以在不对系统进行重大修改的情况下扩展可观测性。这样，我们就可以专注于数据分析和问题解决，而不是管理复杂的系统变更。
2. 使用真相来源：日志提供了系统事件的全面记录，是可靠的 “真相来源”。通过日志，我们可以验证标题是否按预期呈现，并调查任何差异。这种能力对于确保我们的推荐系统和用户界面正常运行、支持成功发布标题至关重要。

但也带来挑战：

1. 提前发现问题：日志记录主要是针对启动后的情况，因为只有在向会员展示标题后才会生成日志。为了主动发现问题，我们需要提前模拟流量并预测系统行为。一旦产生人工流量，丢弃响应对象并完全依赖日志就会变得效率低下。
2. 适当的准确性：全面记录要求服务记录包含和排除的标题，以及排除的原因。这可能导致记录的数据呈指数增长。使用概率记录方法可能会影响准确性，使人难以确定记录中缺少的标题是由于排除还是偶然。
3. 服务水平协议和成本考虑：我们现有的在线日志系统不支持标题粒度级别的日志记录。虽然可以重新设计这些系统，以适应这一额外的轴，但会增加成本。此外，这些调查具有时间敏感性，因此不能使用冷存储，因为冷存储无法满足严格的 SLA 要求。

4.2 个性化系统中的可观察终端

为了优先考虑标题发布的可观察性，我们可以采用集中式方法。通过在所有系统中引入可观察性端点，我们可以将实时数据流引入标题发布可观察性专用微服务。这种方法可将可观察性直接嵌入到管理标题发布和个性化的服务结构中，确保无缝监控和洞察。主要优势和策略包括

1. 实时监控：Observability 端点可对系统性能和标题位置进行实时监控，使我们能够在问题出现时及时发现并解决。
2. 主动问题检测：通过模拟未来的流量（我们称之为 “时间旅行”）并提前捕捉系统响应，我们可以在潜在问题影响会员或业务之前先发制人地发现它们。
3. 增强准确性：可观察性端点提供有关标题包含和排除的精确数据，使我们能够对系统行为和标题可见性做出准确的断言。它还为我们提供了修复已发现问题所需的高级调试信息。
4. 可扩展性和成本效益：虽然初始实施需要一定的投资，但这种方法最终为管理 Netflix 规模的标题发布提供了一种可扩展且具有成本效益的解决方案。

选择这一方案也会带来一些折衷：

1. 初期投资巨大：一些系统需要创建新的端点并重构代码库，以采用这种新的方法来确定启动的优先级。
2. 同步风险：这些新端点可能无法准确反映生产行为，因此需要有意识地确保所有端点保持同步。

下一页

通过采用全面的可观察性策略（包括实时监控、主动问题检测和真实源调节），我们大大增强了确保在 Netflix 上成功发布和发现影片的能力，丰富了会员的全球观看体验。在本系列的下一部分，我们将深入探讨我们是如何实现这一目标的，并分享关键技术见解和细节。

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&券等营销中台建设
• 交易平台及数据中台等架构和开发设计
• 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
• LLM Agent应用开发
• 区块链应用开发
• 大数据开发挖掘经验
• 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

参考：

• 编程严选网