【ML on Kubernetes】第 2 章：理解 MLOps

 大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流

个人主页－Sonhhxg_柒的博客_CSDN博客 

欢迎各位→点赞 + 收藏⭐️ + 留言​

系列专栏 - 机器学习【ML】 自然语言处理【NLP】  深度学习【DL】

​

 foreword

✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。

如果你对这个系列感兴趣的话，可以关注订阅哟

文章目录

将 ML 与传统编程进行比较

探索 DevOps 的好处

了解 MLOps

机器学习

开发运维

数据工程

机器学习项目生命周期

快速反馈回路

在项目生命周期内进行协作

OSS 在 ML 项目中的作用

在 Kubernetes 上运行机器学习项目

概括

进一步阅读

---

大多数具有软件工程背景的人都知道术语开发运营（DevOps）。对我们来说，DevOps 是关于软件开发生命周期( SDLC )中不同团队之间的协作和共同责任。团队不限于少数信息技术（IT）团队；相反，它涉及组织中作为项目利益相关者的每个人。构建软件（开发人员的责任）和在生产中运行它（运营的责任）之间不再分离。相反，团队拥有产品。DevOps 很受欢迎，因为它可以帮助团队提高正在开发的软件的速度和可靠性。

在本章中，我们将介绍以下主题：

• 机器学习( ML ) 与传统编程的比较
• 探索 DevOps 的好处
• 了解机器学习操作( MLOps )
• 开源软件( OSS ) 在 ML 项目中的作用
• 在 Kubernetes 上运行机器学习项目

在我们将 DevOps 应用到 ML 项目之前，我们必须首先了解传统软件开发和 ML 开发流程之间的区别。

将 ML 与传统编程进行比较

与传统应用开发，ML 项目也是一个软件项目，但它们的交付方式存在根本差异。让我们了解 ML 项目与传统软件应用程序有何不同。

在传统的软件应用程序中，软件开发人员编写的程序包含一组明确的手工规则。在运行时或预测时，构建的软件将这些定义明确的规则应用于给定的数据，程序的输出是基于编码规则计算的结果。

下图显示了传统软件应用程序的输入和输出( I/O )：

图 2.1 – 传统软件开发

在 ML 项目中，规则或模式是不完全知道，因此我们不能像在传统编程中那样在代码中明确描述规则。在 ML 中，有一个过程可以根据给定的数据样本对及其相关的预期结果来提取规则。这个过程称为模型训练。在模型训练过程中，选择的 ML 算法根据给定的数据和经过验证的答案计算规则。这个过程的输出是ML 模型。然后可以使用此生成的模型在预测期间推断答案。与传统的软件开发相比，我们没有使用明确的书面规则，而是使用生成的 ML 模型来获得结果。

下图显示了 ML 模型是在训练时生成的，然后在预测时用于生成答案或结果：

图 2.2 – 机器学习开发

尽管传统的软件开发和机器学习有着根本的不同，但是这两种方法在工程过程中有一些协同作用。鉴于传统软件开发在当前时代已经非常成熟，我们可以将其中的经验教训应用到我们的 ML 项目中。当然，首先，传统编程和 ML 都是软件。无论我们在传统世界中应用哪种流程来构建软件，例如版本控制、将软件打包为容器、自动化部署以及等等——这些可以是也适用于 ML 项目。但是，我们还必须适应 ML 中的附加流程，例如模型训练。

那么，为什么我们在 ML 项目中真的需要 DevOps？它带来了什么？让我们在下一节中看看这个。

探索 DevOps 的好处

DevOps 不是只是关于工具集。假设您有一个可以为您运行单元测试的工具。但是，如果团队没有编写测试用例的文化，那么该工具将毫无用处。DevOps 是关于我们如何在跨不同团队的任务上合作。因此，在 DevOps 中要关注的三个主要领域是：

• 人员：来自多个学科的团队，以实现共同目标
• 流程：团队合作的方式
• 技术：促进不同团队协作的工具

DevOps 建立在敏捷开发实践之上，旨在简化软件开发过程。DevOps 团队是跨职能的，他们拥有构建的自主权软件通过持续集成/持续交付( CI/CD )。DevOps 鼓励团队通过快速反馈循环进行协作，以提高正在开发的软件的效率和质量。

下图说明了传统软件开发的完整 DevOps 周期项目：

图 2.3 – 展示 DevOps 流程的 mobius 循环

通过 DevOps，团队可以拥有明确定义和简化的开发实践，用于在生产中构建、测试、部署和监控软件。所有这些都使得快速可靠地将软件发布到生产环境中成为可能。此处介绍了 DevOps 实践带来的一些好处：

• CI / CD：CI是一个软件的阶段开发人员将其推送到代码存储库后立即进行合并和验证。CD 是一系列阶段，在这些阶段中，软件被构建、测试并以可部署的形式打包。持续部署（也称为CD）是一种部署就绪代码被挑选和部署以供最终用户使用的阶段。在 DevOps 中，所有这些过程都是自动化的。
• 基础设施即代码( IaC )：IaC 是一种自动化供应的方法和配置 IT 基础设施。这一方面使团队能够根据需要和按需请求和配置基础设施。想象一下，您的数据科学家团队需要一个图形处理单元( GPU ) 来进行模型训练。如果我们遵循配置和供应 IaC 的做法，系统可以自动满足对 GPU 的请求。在接下来的章节中，您将看到此功能的实际应用。
• 可观察性：可观察性与我们对运行系统状态的理解程度有关。DevOps 通过联合来自不同组件的日志记录、监控系统（例如中央处理器( CPU )、内存、响应时间等）并提供一种通过呼叫跟踪为给定呼叫关联系统各个部分的方法。所有这些能力共同为理解系统状态和在不更改代码的情况下帮助调试任何问题。
• 团队协作：DevOps不仅仅是技术。事实上，团队的重点关注领域是协作。协作是来自不同团队的多个人如何朝着一个共同目标努力。业务、开发和运营团队协同工作是 DevOps 的核心。对于基于 ML 的项目，团队将在上述角色之上配备数据科学家和数据工程师。对于这样一个多元化的团队，沟通对于建立集体理解和对既定结果的所有权至关重要。

那么，我们如何才能将 DevOps 方法的好处带到 ML 项目中呢？答案是 MLOps。

了解 MLOps

MLOps是一个新兴的利用现有软件开发流程的成熟度的领域——换句话说，DevOps 与数据工程和 ML 学科相结合。MLOps 可以简化为将 DevOps 应用于 ML 项目的工程实践。让我们仔细看看这些学科如何构成 MLOps 的基础。

机器学习

机器学习项目涉及传统编程中不存在的活动。您在图 2.3中了解到ML 项目中的大部分工作不是模型开发。相反，它更多的是数据收集和处理、数据分析、特征工程( FE )、流程管理、数据分析、模型服务等等。在事实上，根据D. Sculley 等人的论文Hidden Technical Debt in Machine Learning Systems ，只有 5% 的工作是 ML 模型开发。正因为如此，MLOps 不仅专注于 ML 模型开发任务，而且主要关注全局——整个 ML 项目生命周期。

与 DevOps 一样，MLOps 关注人员、流程和技术。但是有一些复杂性是 MLOps 必须解决的，而 DevOps 则不必。让我们在这里更详细地了解其中一些复杂性：

• 首先，与传统编程不同的是，您的唯一输入是代码，在 ML 中，您的输入既是代码又是数据。在模型开发阶段产生的机器学习模型高度依赖数据。这意味着即使您不更改代码，如果您使用不同的数据集训练 ML 算法，生成的 ML 模型也会有所不同，并且性能也会有所不同。谈到版本控制，这意味着您不仅要对有助于模型训练的代码进行版本控制，还需要对数据进行版本控制。与代码不同，由于需要大量数据，因此很难对数据进行版本化。解决这个问题的一种方法是使用 Git 使用数据的哈希来跟踪数据集版本。然后将实际数据存储在远程存储中的某个位置，例如简单存储服务( S3 ) 存储桶。一个名为数据版本控制( DVC )的开源工具可以做到这一点。
• 其次，机器学习项目涉及更多角色，需要更多协作。您拥有与软件工程师、业务分析师和运营团队合作的数据科学家、ML 工程师和数据工程师。有时，这些角色非常多样化。数据科学家可能不完全了解生产部署的真正含义。另一方面，运维人员（有时甚至是软件工程师）并不了解 ML 模型是什么。这使得 ML 项目中的协作比传统的软件项目更加复杂。
• 第三，模型开发阶段的增加为生命周期增加了更多的支点。这使整个过程复杂化。与传统的软件开发不同，您只需要开发一套工作代码。在 ML 中，数据科学家或机器学习工程师可能会使用多种 ML 算法并生成多个生成的 ML 模型，并且由于只有一个模型会被选择部署到生产环境中，因此这些模型会在性能方面与其他模型属性进行比较。MLOps 适应这种复杂的测试、比较和选择要部署到生产的模型的工作流程。

构建传统代码以生成可执行二进制文件通常需要几秒钟到几分钟的时间。但是，当您使用某些深度学习( DL ) 算法时，训练 ML 算法以生成 ML 模型可能需要数小时或数天，有时甚至数周。这使得设置敏捷迭代有时间限制的节奏有点复杂。启用 MLOps 的团队需要处理其工作流程中的这种延迟，一种方法是在等待其他模型完全训练的同时开始构建另一个模型。如果数据科学家或 ML 工程师使用自己的笔记本电脑训练他们的 ML 算法，这很难实现。这就是使用可扩展基础架构派上用场的地方。

• 最后，由于 ML 模型的性能依赖于训练期间使用的数据，如果这些数据不再代表真实世界的情况，模型的准确性就会下降，从而导致预测性能不佳。这称为模型漂移，需要及早发现。这通常被纳入 ML 项目生命周期的监控过程的一部分。除了您在生产中收集的传统指标外，使用 ML 模型，您还需要监控模型漂移和异常值。然而，异常值检测实现起来要困难得多，有时需要您训练和构建另一个 ML 模型。异常值检测是关于检测生产中的输入数据，这些数据看起来不像模型训练的数据：您不希望您的模型为这些不相关的问题提供不相关的答案。另一个原因是这可能是攻击或企图滥用系统。一旦检测到模型漂移或异常值，您将如何处理这些信息？它很可能只是发出警报，或者它可能会触发其他一些自动化过程。

由于复杂与传统编程相比，ML 添加了解决这些复杂性的需求，这导致了 MLOps 的出现。

开发运维

按照部署，思考关于您在 ML 项目中编写的所有代码集：执行数据处理的代码、促进模型训练和 FE 的代码、运行模型推理的代码以及执行模型漂移和异常值检测的代码。所有这些代码集都需要构建、打包和部署以供大规模使用。该代码一旦在生产环境中运行，也需要进行监控和维护。这就是 DevOps 的 CI/CD 实践有帮助的地方。自动化软件打包、测试、保护、部署和监控的实践来自 DevOps。

数据工程

每个 ML项目涉及数据工程，而 ML 项目处理的数据比代码多得多。因此，您的基础架构必须包含数据处理功能，并且可以与组织中现有的数据工程管道集成。

数据工程是一门庞大的学科——可以写一整本书。但我们在这里要强调的是那个 MLOps与数据工程相交实践，特别是在数据摄取、数据清洗、数据转换和大数据测试中。事实上，您的 ML 项目可能只是一个小型 ML 分类模型，它是更大的数据工程或数据分析项目的子部分。MLOps 采用数据工程和分析方面的最佳实践。

的代表下图中提供了 MLOps：

图 2.4 – MLOps 作为 ML、数据工程和 DevOps 的交集

换句话说，如图 2.4所示，MLOps是ML、DevOps和专注于在生产中运行 ML 的数据工程学科的融合。它还涉及将 ML 项目封装在高度可扩展、可靠、可观察的基础架构中。最后，它还涉及为团队建立可重复的流程，以执行成功交付 ML 项目所需的任务，如图 2.4所示，同时支持彼此的协作。

有了对 MLOps 的基本了解，让我们深入挖掘一下 ML 项目的生命周期。我们开始通过定义 ML 项目的一般阶段是什么。

机器学习项目生命周期

与DevOps，其中提供了一系列可以在 DevOps 周期中执行的活动，您可以在图 2.5中看到可用于将您的 ML 项目从开始到结束的一系列步骤。这些步骤或阶段将成为您的 ML 项目生命周期的一部分，并提供一种将您的 ML 项目投入生产的一致方式。您在本书中构建的 ML 平台是允许您实施此流程的生态系统。在本书后面的章节中，您将使用此流程作为平台的基础。ML 项目的各个阶段总结如下：

图 2.5 – 机器学习项目生命周期

这是上图中显示的项目生命周期的每个阶段的定义：

• 编码问题并定义成功指标：在这个阶段，团队评估是否给定的业务问题可以使用 ML 来解决。请注意这里的团队一词，它将由数据科学家和至少是业务主题专家( SME )。然后，团队将定义一个成功标准来评估模型的预测。
• 摄取、清理和标记数据：在此阶段，团队将评估训练模型所需的数据是否可用。该团队将扮演一个额外的角色，即数据工程师，在这个阶段及以后帮助推动项目。该团队将构建组件以从各种来源获取数据，清理捕获的数据，可能标记数据并存储它。这些数据将构成机器学习活动的基础。
• FE：FE 是将原始数据转换为与给定问题更相关的特征。假设您正在构建一个模型来预测泰坦尼克号上的任何给定乘客是否会幸存下来。想象一下你得到的数据集包含乘客的票号。你觉得票号跟乘客的生死有关系吗？一家中小企业可能会提到，票号可能能够提供客户在船上属于哪个舱位，而头等舱乘客可能更容易使用船上的救生艇。
• 模型构建和调整：在这个阶段，团队开始尝试不同的模型和不同的超参数。团队将针对给定的数据集测试模型并比较每次迭代的结果。然后，团队将为给定的成功指标确定最佳模型，并将模型存储在模型注册表中。
• 模型验证：在此阶段，团队根据训练时不可用的一组新数据验证模型。这个阶段很关键，因为它决定了模型对于未见过的数据足够泛化，或者该模型仅适用于训练数据而不适用于未见过的数据——换句话说，避免过度拟合。模型验证还涉及识别模型偏差。
• 模型部署：在这个阶段，团队选择模型注册表中的模型，对其进行打包，并将其部署以供使用。在这里可以使用传统的 DevOps 流程将模型作为服务提供。在本书中，我们将关注模型即服务（MaaS），其中模型是可作为代表性状态传输( REST ) 服务使用。但是，在某些情况下，可以将模型打包为库以供其他应用程序使用。
• 监控和验证：在此阶段，将持续监控模型的响应时间、预测的准确性以及输入数据是否与训练模型的数据相似。我们已经简要介绍了异常值检测。在实践中，它的工作原理是这样的：假设您已经针对公共交通系统的高峰时段空置训练了您的模型，并且训练模型所针对的数据是公民使用公共交通系统一年多的地方。周末、公共假期和任何其他事件的数据都会有差异。现在，想象一下，如果由于 COVID-19 封锁，不允许任何人进入使用公共交通系统。与我们的模型训练所依据的数据相比，现实世界并不相同。自然，我们的模型对于这个变化的世界并不是特别有用。我们将需要检测这种异常并生成警报，以便我们可以在可能的情况下使用新数据集重新训练我们的模型。

您刚刚了解了机器学习项目生命周期。虽然这些阶段可能看起来直截了当，在现实世界中，在某些情况下，您需要回到之前的阶段有几个很好的理由。

快速反馈回路

敏锐的观察者可能已经注意到，我们在第一章中介绍的敏捷和跨职能团队的一个关键属性在本章到目前为止介绍的阶段中不可用。现代 DevOps 都是关于在项目生命周期的早期进行快速反馈循环以纠正课程。同样的概念将为 ML 项目带来更多价值，因为 ML 项目比传统的软件应用程序更复杂。

让我们看看我们可以在哪些阶段评估和评估团队的进展情况。评估后，团队可以决定通过返回较早阶段或进入下一阶段来纠正路线。

下图显示了 ML 项目生命周期，其中包含来自各个阶段的反馈检查点，用绿色箭头表示：

图 2.6 – 带有反馈检查点的 ML 项目生命周期

让我们在这里更详细地看一下：

• 摄取、清理和标记数据阶段的检查点：阶段 1完成后，您已开始按照第二阶段的定义处理数据。您可能会发现实际数据不完整或不正确。您可以利用此反馈来提高您对数据的理解，并且可能需要重新定义项目的成功标准，或者在更糟糕的情况下，由于所需数据不可用而停止项目。在许多情况下，团队会寻找额外的数据源来填补第二阶段确定的数据空白。
• 模型构建和调整阶段的检查点：在此阶段，团队可能会发现可用于训练模型的特征可能不足以获得所需的指标。此时，团队可能决定投入更多时间来寻找新功能或重新访问原始数据以确定是否需要更多数据。
• 模型验证阶段的检查点：在此阶段，模型将针对模型从未见过的新数据集进行验证。在这个阶段糟糕的指标可能会触发模型的调整，或者您可能决定返回寻找更多特征以获得更好的模型性能，
• 模型监控和验证阶段的检查点：模型投入生产后，必须对其进行持续监控，以验证模型是否仍然与现实和不断变化的世界相关。您需要确定模型是否仍然相关，如果不相关，如何使模型更有用。其结果可能会触发生命周期中的任何其他阶段；正如您在图 2.6中看到的，您最终可能会使用新数据重新训练现有模型或完全使用不同的模型，甚至重新考虑是否应该解决这个问题由 ML 解决。关于您最终处于哪个阶段，没有明确的答案；就像现实世界一样，它是不可预测的。然而，重要的是重新评估和重新评估的能力，以及继续为业务创造价值的能力。

您已经了解了 ML 项目生命周期的各个阶段以及您做出决定的反馈检查点是继续下一个阶段还是回到前一个阶段。现在，让我们看看每个阶段所涉及的角色及其协作点。

在项目生命周期内进行协作

我们定义了一个简化了构建模型的过程。让我们尝试定义一个具有不同角色和能力的团队将如何在此模型上进行协作。回想一下上一章，构建模型需要不同能力的不同团队的努力。需要注意的是，在较小的项目中，同一个人可能同时代表不同的角色。例如，在一个小型项目中，同一个人可以同时是数据科学家和数据工程师。

下图显示了一个包含反馈点和角色的 ML 项目生命周期：

图 2.7 – 具有反馈检查点和团队角色的 ML 项目生命周期

您组织内的 ML 项目在第一阶段需要数据科学家和业务 SME 之间的协作。想象一下，团队想要根据一张图片来预测某种皮肤病的概率。

• 在这个阶段，需要数据科学家和医生（本案例中的 SME）合作来定义问题和绩效指标。没有这种合作，这个项目就不会成功。
• 在第二阶段——数据摄取和清理阶段——数据工程师需要与中小企业了解哪些数据可用以及如何正确清理和标记数据。中小企业将在此阶段带来的知识至关重要，因为这有助于为未来阶段创建有用的数据集。
• 在第三阶段，数据科学家、数据工程师和中小企业将协作处理第二阶段的基础数据并对其进行处理以从中提取有用的特征。数据科学家和中小企业将就可以提取哪些数据提供指导，数据工程师将为此编写处理逻辑。
• 在第四和第五阶段，大部分工作将由数据科学家完成，以根据给定的标准构建和调整模型。但是，根据模型是否成功地实现了定义的指标，团队可能会决定回到之前的任何阶段以获得更好的性能。

模型构建完成后，DevOps 团队专家可以将模型打包、版本化和部署到正确的环境。

• 最后一个阶段至关重要：团队使用可观察性功能来监控模型在生产环境中的性能。在监控现实世界中的模型性能并根据反馈后，团队可能会再次决定返回之前的任何阶段，以使模型对业务更有用。

现在您已经很好地理解了我们强调的挑战以及如何使用 ML 生命周期克服这些挑战，下一个阶段是拥有一个支持该生命周期的平台，同时为每个组件提供解决方案在全局中定义（参见第 1 章，机器学习中的挑战），具有自助服务和自动化功能。在与开源社区合作的同时，还有什么更好的方式来开始一段旅程？

OSS 在 ML 项目中的作用

现在你清楚地了解什么问题ML平台有望解决，让我们看看为什么开源是最好的起点。我们应该从一些定义开始设置基础，对吗？

免费 OSS 是用户可以自由运行、复制、分发、学习、更改和改进软件的地方。

我们

有关 OSS 的更多信息，请参见以下链接：

What is Free Software?- GNU Project - Free Software Foundation

OSS无处不在。Linux 是最常见的操作系统，在数据中心运行并为世界各地的云提供动力。Apache Spark 和相关的开源技术是一系列组织大数据革命的基础。打开TensorFlow 和 MLflow 等基于源的人工智能( AI ) 技术处于人工智能发展的前沿，并被数百家组织使用。开源容器编排平台 Kubernetes 已成为容器平台的事实标准。

计算领域的顶级参与者——例如亚马逊、苹果、Facebook、谷歌、微软和红帽等等——都为主要的开源项目做出了贡献并拥有了这些项目，并且不断有新的参与者加入。世界各地的企业和政府都依赖关于开源以支持关键任务和高度每天都有可扩展的系统。

云计算领域最成功的开源项目之一是Kubernetes。Kubernetes成立于 2014 年年中，随后在 2015 年年中发布了 1.0 版。从那时起，它已成为容器编排的事实标准。

此外，云原生计算基金会( CNCF ) 是由Linux 基金会创建的使云计算无处不在的使命。CNCF 通过汇集世界顶级工程师、开发人员、最终用户和供应商来做到这一点。他们还举办世界上最大的开源会议。该基金会是使用Kubernetes作为种子项目创建的。这就是 Kubernetes 设置云原生标准定义的方式。在撰写本文时，该基金会拥有 741 个成员组织和 130 个经过认证的 Kubernetes 发行版和平台，并且已经毕业了 16 个非常成功的开源项目。在这些项目中，当然有Kubernetes，还有Operator Framework，您将在下一章中了解更多信息。

在大数据和云计算爆发之前，ML 项目大多是学术性的。他们很少离开学院和大学的界限，但这并不意味着人工智能、机器学习和数据科学没有向前发展。学术界实际上已经创建了数百个用于数学、科学和统计计算的开源 Python 库。这些库已成为构建现代 ML 框架的基础。在撰写本文时，最流行的机器学习框架——TensorFlow、PyTorch、scikit-learn 和 Spark ML——都是开源的。当今最流行的数据科学和机器学习开发环境——Jupyter Notebook、JupyterLab、JupyterHub、Anaconda 等等——也都是开源的。

ML 是一个不断发展的领域，它需要超越任何单一组织的更大社区的愿景。以社区为基础的工作流程实现了 ML 项目所需的协作和创造力，而开源是 ML 以惊人速度发展的重要部分。

你现在有一个基本了解 OSS 在人工智能和机器学习空间。现在，让我们仔细看看为什么应该在 Kubernetes 上运行 ML 项目。

在 Kubernetes 上运行机器学习项目

用于建筑可靠且可扩展的机器学习系统，你需要一个坚如磐石的基础。Kubernetes为构建可扩展且可靠的分布式系统以及我们平台所需的自助服务功能奠定了基础。Kubernetes 抽象硬件基础设施并将其作为一个单元使用的能力对我们的平台有很大的好处。

另一个关键组件是基于 Kubernetes 的软件能够在任何地方运行，从小型本地数据中心到大型超大规模（亚马逊网络服务（AWS）、谷歌云平台（GCP）、Azure）。这个功能将使您能够在任何您想要的地方运行您的 ML 平台。它为您的平台消费者带来的一致性非常出色，因为团队可以在云上试验极低的初始成本，然后为您企业中更广泛的受众定制平台。

选择 Kubernetes 的第三个也是最后一个原因是它能够运行不同类型的工作负载。您可能还记得在上一章中，一个成功的 ML 项目不仅需要 ML，还需要基础设施自动化、数据生命周期管理、有状态组件等等。Kubernetes 为运行不同类型的软件提供了一致的基础组件为业务用例创建端到端( E2E ) 解决方案。

以下屏幕截图显示了 ML 平台的各个层。Kubernetes 提供了构建 ML 平台的扩展和抽象层。Kubernetes 提供了抽象底层基础设施的自由。由于这种灵活性，我们可以在各种云提供商和本地解决方案上运行。您将在本书中构建的 ML 平台允许在 ML 项目的三个更广泛领域（FE、模型开发和 DevOps）中实现操作和自助服务：

图 2.8 – 基于 OSS 的机器学习平台

好了：您的机器学习平台将基于 OSS，并将使用 Kubernetes 作为主机根据。开源 Kubernetes 社区的力量将帮助您使用随着该领域不断成熟而发展的最佳技术。

概括

在本章中，我们定义了术语MLOps，并提出了一个协作并提供早期反馈的 ML 项目生命周期。您已经了解到，通过这个项目生命周期，团队可以持续为业务创造价值。您还了解了基于 OSS 构建平台的一些原因以及社区驱动软件的好处。

这完成了本书关于设置上下文、了解为什么需要一个平台以及发现它期望解决什么样的问题的部分。在下一章中，我们将研究作为机器学习平台核心的 Kubernetes 系统的一些基本概念。

进一步阅读

有关本章所涵盖主题的更多信息，请查看以下资源：

• DevOps：打破开发运营障碍 What is DevOps? | Atlassian