RecSysOps: 大规模推荐系统运维最佳实践

运维大规模系统总会面临很多挑战，本文介绍了 Netflix 在运维大规模推荐系统时总结出的最佳实践。原文: RecSysOps: Best Practices for Operating a Large-Scale Recommender System

运维大规模推荐系统是一项复杂的工作，这样的系统有高可用性和吞吐量的需求，涉及众多服务和团队，环境时刻都在变化，新成员或新项目可能随时进入服务，新代码和新机器学习模型经常需要部署到生产环境中。因此，我们在 Netflix 需要解决的问题是，如何确保推荐系统在这样一个动态环境中健康运行？

本文将介绍 RecSysOps，这是一套最佳实践，是我们在 Netflix 运维大规模推荐系统时学到的经验教训。这套最佳实践帮助我们保持系统健康，同时 1)减少灭火时间，2)专注于创新，3)与利益相关者建立信任。

RecSysOps 有四个关键组件: 问题检测、问题预测、问题诊断和问题解决，接下来我们将回顾每个组件并分享相关经验。

问题检测(Issue Detection)

在 RecSysOps 的四个组件中，问题检测是最关键的一个，它会触发其余步骤。缺乏良好的问题检测设置就像闭着眼睛开车一样。

从形式上讲，问题检测非常简单，如果生产中出现问题，需要能够快速检测到。然而，事情出错的方式有无数种，其中许多问题我们可能还没有遇到过。以下是我们在增加问题检测覆盖率方面学到的一些经验。

第一步是整合相关学科中所有已知的最佳实践。因为创建推荐系统涉及软件工程和机器学习，包括所有 DevOps 和 MLOps 实践，如单元测试、集成测试、持续集成、数据量检查和模型度量检查。幸运的是，有许多可用的资源(如The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction一文所言)，其中包含检查列表，可用于检查机器学习系统并确定其缺陷。

第二步是从工程师角度对系统进行端到端监视。在大规模推荐系统中，经常有许多团队参与其中，从机器学习团队角度来看，既有上游团队(提供数据)，也有下游团队(使用模型)。我们从中学到的是，不要只依赖合作伙伴团队的审计，最好是审计(从我们自己角度)所有的输入和输出，包括模型以及由模型生成的分数。例如，我们可能对上游团队生成的数据的特定部分感兴趣，而该部分的更改可能不会在团队整体审计中显示出来。另一个例子是，如果某个团队对使用我们的模型进行预测感兴趣，我们可以一起记录模型预测的细节，例如对于一小部分流量的特性，从我们自己的角度进行审核。这种类型的端到端审计可以帮助我们发现上下游的许多问题，特别是在涉及到有新数据源的新项目开始的时候。

实现全面覆盖的第三步是了解利益相关者的关注点，这是增加问题检测组件覆盖率的最佳方法。在我们的推荐系统中，有两个主要视角: 成员和项目。

• 从成员角度来看，问题非常简单。如果某个成员选择了一个在服务排名模型中排名不高的项目，就会产生潜在的问题。因此，监测和分析这些案例对于发现问题非常重要，也是未来创新的灵感来源。

• 从项目角度来看，需要确保与负责项目的团队接触并理解他们的关注点。在 Netflix，这些团队表示了对项目冷启动和潜在生产偏差的担忧。这些都是 RecSys 社区中活跃的研究领域，但首先，我们需要帮助这些团队围绕关注点定义指标，并构建监控这些指标的工具。我们还需要帮助他们了解每个项目是否出现了这些问题，并将这些工具直接集成到问题检测组件中。从而使我们能够 1)扩大问题检测范围，2)主动解决与项目相关的关键问题，并与利益相关者建立信任。

总结:

实现所有已知的最佳实践

以我们自己的方式监控端到端系统

理解利益相关者的关注点

问题预测(Issue Prediction)

能够快速发现生产问题当然很好，但如果能够预测这些问题并在投入生产之前修复那就更好了。例如，因为每个项目只启动一次，因此项目的冷启动(如新电影、新节目或新游戏)在 Netflix 非常重要。所以我们想知道是否可以预测某个项目是否会在发布日期前出现冷启动问题。这需要预测未来的生产模式，这是一项很有挑战性的工作。基于历史数据点，我们可以建立模型，预测产品模型在发布当天的行为统计数据。该模型使我们能够提前一周或更长时间捕捉到与项目冷启动相关的潜在问题，这使我们有时间在项目真正发布之前修复问题。

总结:

尝试在问题发生之前预测问题，而不是在问题进入生产环境后发现问题

问题诊断(Issue Diagnosis)

一旦用检测或预测模型确定了问题，下一阶段是寻找其根本原因。首先需要独立复现问题。然而，大型推荐系统是非常动态的，可能无法通过简单的重新运行代码来重现问题(例如，底层输入数据或特征值可能已经更改)。因此，为了再现该问题，需要预先设置适当的日志记录，包括记录项目候选项、上下文、特征、服务模型 id 或再现问题所需的任何东西。为了降低成本，只记录一小部分流量的相关信息。在这种情况下，需要仔细设计抽样方法，从而能够充分覆盖所有重要的流量部分。

再现问题之后，下一步是确定问题是与机器学习模型的输入相关还是与模型本身相关。为了了解问题是否与输入数据有关，需要验证输入是否准确有效。虽然某些特征值可以追溯到它们的原始事实并进行验证，但可能有许多特征涉及复杂的数据处理或特征本身就是机器学习模型。因此，在实践中验证输入值是一个具有挑战性的问题。

一个简单的解决方案是将特征值与可比较的项目或成员的对应值进行比较，从而使我们能够确定特征值是否在预期范围内。这种方法虽然简单，但对于标记异常非常有效。例如，在某种情况下，该方法标记了与语言特征值相关的异常值，经过进一步的调查发现，该项目的语言在上游数据库中没有被正确配置。

如果所有输入特征都是正确的，下一步就是深入挖掘机器学习模型及其训练数据，以找到问题的根本原因。有许多用于模型检查和模型解释的工具，例如Shap和Lime。基于模型的体系结构(例如，可视化决策树节点或神经网络层)，还可以开发自定义工具来检查所期望的属性。这种类型的分析曾经帮助我们确定处理缺失值时的错误，或者帮助我们确定训练数据的错误部分。

总结:

设置日志记录以再现问题

开发工具来检查输入的有效性

开发工具来检查机器学习模型的内部组件

问题解决(Issue Resolution)

一旦确定了问题的根本原因，下一步就是修复问题。这部分类似于典型的软件工程，我们可以提供短期的修复程序或长期的解决方案。然而，为机器学习模型应用热修复程序很具有挑战性。因为这些模型是高度优化的，可能需要一段时间来训练，任何手动修改都可能导致次优推荐。那么，我们如何在将生态系统其他部分的成本降至最低的同时修复这个问题呢？解决方案需要领域洞察力和创造力，而这高度依赖于产品、平台和利益相关者。由于每个热修复程序都有自己的利弊，所以最好提前准备一个热修复解决方案列表，从而使我们能够针对每种情况快速选择和部署最合适的方案。

除了修复问题，解决问题的另一个阶段是改进 RecSysOps 本身。例如:

• 是否有可能更快检测到问题？或者预测出问题？

• 是否有可能改进工具来更快诊断问题？

最后，重要的是要使 RecSysOps 尽可能不产生额外成本，使操作更加顺畅，系统更加可靠。例如:

• 确保检测或预测组件在定期、自动运行。

• 如果在某些步骤中需要人的判断(例如诊断或解决方案)，确保相关人员已经获取所有需要的信息，从而使他们能够迅速做出明智的决定

• 确保部署热修复程序非常简单，只需单击几下即可

总结:

是否准备了一组热修复策略，并量化与每个策略相关的利弊

每一次事件都让 RecSysOps 变得更好

使 RecSysOps 尽可能不产生额外成本

总结

在这篇文章中，我们介绍了 RecSysOps，以及在 Netflix 学到的一套最佳实践和教训。RecSysOps 由四个部分组成: 问题检测、问题预测、问题诊断和问题解决。我们认为这些模式对于任何真实世界运行的推荐系统都是有用的，可以让它保持良好运行并随着时间的推移不断改进。为大规模推荐系统开发这样的组件是一个迭代的过程，有其自身的挑战并且未来需要不断迭代。例如，可能需要不同类型的模型来进行问题检测和预测。对于问题诊断和解决，需要对机器学习体系架构和设计假设有更深的理解。总的来说，将这些方面组合在一起帮助我们显著减少了问题，增加了与利益相关者的信任，并使我们可以专注于创新。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind