下载掌阅APP，畅读海量书库
立即打开
MLOps借鉴了很多DevOps实现原则和实践，并应用在人工智能系统研发和运维实践中，所以MLOps和DevOps有很深的关系。本节将详细讲解两者之间的关系。
什么是DevOps？
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序、软件工程开发）、技术运营和质量保障部门之间的沟通、协作与整合。它是一种重视软件开发人员（Dev）和IT运维人员（Ops）之间沟通合作的文化，通过软件交付和架构变更流程自动化，使得软件构建、测试、发布更加快捷、可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
笔者这里总结一下DevOps的优点。
1.打破软件研发和IT运维之间的部门墙
在传统研发模式下，软件研发人员和IT运维人员之间协作不顺畅。我们这里来看看Google SRE对DevOps的解读。
软件研发人员和IT运维人员的工作关系如图1-5所示。
图1-5 Google SRE描述研发和运维的关注点以及部门墙的存在
在传统研发模式下，软件研发人员和IT运维人员分属于不同的团队，两者之间存在部门墙（专业术语叫Silos）。软件研发人员关心敏捷，即产品功能的快速迭代；IT运维人员更关心整个系统的稳定性。从部门分工和岗位职责来看，软件研发人员希望更多、更快的代码修改和上线，以实现更多软件功能；IT运维人员则希望更少的代码修改和上线，以保持系统的稳定性。两者的关注点完全不一样，相互冲突。
软件研发人员交付产出物给IT运维人员的过程如图1-6所示。
可见，软件研发人员做好代码开发和测试之后，把生成的软件包交给IT运维人员。这个移交过程在某些公司做得比较规范，会设定一定的准入门槛，例如需要清晰完整的测试报告、完整详细的上线文档（包括如何回滚）等，基本上是为了运维方便。在这种模式下，研发人员不关心线上稳定性，只关心快速完成功能并完成内部测试。
图1-6 Google SRE描述软件研发人员把产出物交给IT运维人员的过程
IT运维人员收到软件研发人员交付的产出物之后的动作如图1-7所示。
图1-7 Google SRE描述IT运维人员收到软件研发人员交付的产出物之后的动作
可见，IT运维人员在收到软件研发人员交付的软件包之后，将其部署到线上环境并在线上生效。他们负责系统的稳定性，可能采用从小流量部署过渡到全流量部署的方式，也可能采用异地多活等方式。
通过图1-5、图1-6和图1-7，我们能清楚地看到软件研发人员和IT运维人员之间的合作关系和关注点。显然，两者存在天然的矛盾。
但是在需要越来越快地进行业务更新的情况下，两者的矛盾是一个很大的阻碍。DevOps的出现打破了软件研发和IT运维之间的部门墙，促使软件开发人员和IT运维人员顺畅协作，因此产生了很多DevOps落地实践，体现在团队组织、研发与运维代码管理、运维任务管理上。例如在团队组织管理上，提倡构建更小的敏捷团队、开发运维一体化；在研发与运维代码管理上，提倡运维配置代码化、研发和运维人员共享彼此代码权限；在运维任务管理上，提倡运维任务共享、线上值班等。
2.将流水线扩展到运维环节
DevOps实践包括CI和CD。DevOps之前的工程实践为敏捷开发，往往只有CI，只覆盖了代码开发、代码编译、代码测试、代码打包环节，并没有覆盖部署环节。
DevOps双环流水线模型如图1-8所示。
图1-8 DevOps双环流水线模型
该DevOps双环流水线模型的左半边集中在软件研发阶段，从产品需求定义到编写代码、编译代码，再到测试代码，最后生成、发布软件包；右半边集中在软件部署阶段，从获得软件包开始到部署到生产环境、执行各种线上运维操作，再到监控线上服务。两个环构成DevOps完整的流水线。该流水线的运转是持续的，左半边流水线一般被称为持续集成，右半边流水线一般被称为持续部署。
显然，该流水线运转的速度说明了研发和运维团队的工程能力。在保证一定质量的前提下，运转速度越快，意味着更多的功能迭代，一般也意味着更强的团队工程能力。当然，部署频率也不是越快越好，每次迭代都要有明确的业务目标。
3.利用工具实现自动化，并构建工具链生态
DevOps工具链生态如图1-9所示。
可以看出，DevOps流水线上的每个环节都有多个工具支持协作，这里有开源的软件（如Git、GitLab、Gradle、Jenkins），也有商业软件和服务（如Azure和AW S）。
DevOps的推广和运营如此成功，之后又衍生出很多类似的名词，包括DevSecOps、GitOps、DataOps、ModelOps、AIOps、NoOps、MLOps等。各种XOps都包含相应的流程和工具（即通过工具自动化来完成流程执行），也都涉及相应的角色，不同的是具体应用在哪个业务领域，是哪些任务的自动化，有哪些工具和角色参与其中。MLOps被认为是DevOps在机器学习领域的扩展，既对DevOps的优点进行了延续，又有相对DevOps独特的地方。
图1-9 DevOps工具链生态
1. MLOps同样打破了部门墙
如果说DevOps打破了软件研发和IT运维之间的部门墙，推动两个部门高效地协同工作，则MLOps打破了人工智能系统研发（AI科学家）和运维（AI工程师）之间的部门墙。
AI科学家的职责是利用数据训练出较好的模型，工作重点是改进模型从而达到用户所预期的准确率、召回率等性能指标。AI科学家往往是通过Jupyter Notebook完成工作，擅长构建模型和特征处理，但是并不关心模型大小、训练和预测的成本、预测服务的延时、预测服务的QPS等指标。
AI工程师的职责是在线上部署AI科学家训练好的模型，然后对用户请求或者下游系统提供预测服务，从而实现商业价值。AI工程师对最终服务负责，关心产品成本、性能、稳定性、客户满意度等指标，需要花费大量精力提升产品可扩展性和自动化水平，往往需要长期维护一个产品。
这两个角色都是人工智能系统在企业内落地过程中必不可少的角色。但是在如今的人工智能系统研发和运维流程中，其职责和目标不同，导致协作非常不顺畅，降低了人工智能模型训练和部署的效率。
所以，MLOps也需要跟DevOps一样，打破人工智能系统研发和运维之间的部门墙，让AI科学家和AI工程师紧密协作。这两个角色的合作问题详见第2章。
2. MLOps同样有流水线
流水线是自动化操作的集合，能极大地加速开发和运维的运转。
MLOps双环流水线模型如图1-10所示。
除此之外，MLOps还有三环流水线模型，笔者个人比较倾向双环模型，这里不再对三环流水线模型赘述。
在MLOps双环流水线模型中，左半边是人工智能模型训练过程，目标是基于数据训练出比较好的模型来找出数据间的规律，包括EDA（Exploratory Data Analysis，数据探索和数据分析）、数据准备和特征工程、模型开发与调试、模型训练和重训等；右半边是人工智能模型的部署过程，包括模型评估、模型部署、模型预测、模型性能监控和服务监控。
图1-10 MLOps双环流水线模型
（资料来源：Databricks官网）
3. MLOps同样利用了各种平台和工具
DevOps已经发展出成熟、丰富的工具链生态，MLOps的发展还处于早期，但是也有各种各样的工具链来支持人工智能系统的研发和运维。
Google Cloud推荐的MLOps成熟形态的工具和平台架构见图1-11。
从图1-11可以看到，MLOps高成熟度的实现需要如下平台和工具的支持。
● Feature Store（特征平台）：存放在线业务和离线业务所需要的各种特征。
● Model Store（模型平台）：存放模型的各种版本和版本相关的各种信息。
● Model Monitoring（模型监控）：专门用来监控模型性能。
● Metadata DB（元数据的数据库）：存放模型、数据的各种元数据信息。
图1-11 Google Cloud推荐的MLOps成熟形态的工具和平台架构
其中，特征平台、机器学习元数据平台、模型注册中心都是比较重要的工具。
DevOps和MLOps存在较大差异，在流水线部分就有很多不同的地方。DevOps和MLOps的不同点如表1-2所示。
表1-2 DevOps和MLOps的不同点
虽然上文描述了MLOps和DevOps的不同之处，但两者在最基本的目标和实践理念上是一致的。
（1）基本目标相同
无论DevOps还是MLOps，它们的目标都是提升系统的研发和运维效率，更快、更好、更省地为客户提供价值。如果没能达到给客户提供价值的目标，各种实践的推行、各种工具的采纳就都毫无意义。
（2）基本实践理念相同
两者在实践理念上保持一致，主要体现在两点：两者都希望尽可能实现作业的自动化，用流水线把各种工作任务串联起来，尽可能用机器代替人来执行；两者的改进原则都是系统思考、尽快反馈、持续改进。系统研发和运维团队在推行DevOps或者MLOps时，都不能是头痛医头，脚痛医脚，而是需要整体思考，对改进的每一步都要进行及时反馈，且改进是持续的。
2010年，时任百度高级架构师的乔梁预测DevOps会在之后的10年风靡起来，成为业内软件研发的默认词。笔者认为，随着企业数字化转型逐渐深入，人工智能系统将在企业内大量落地并发挥关键作用，MLOps也会成为热词，并在未来10年内，成为业内人工智能系统落地的默认词。