大语言模型 “放大招”，软件交付迎来 “核变”

在当今数字化浪潮汹涌澎湃的时代，软件已然成为驱动各行各业创新与发展的核心引擎。从金融领域瞬息万变的交易系统，到支撑人们日常社交、娱乐的各类应用，软件的身影无处不在，其交付的效率、质量与可靠性更是直接关乎企业竞争力与用户体验。而在这一复杂且充满挑战的软件交付进程中，DevOps、SRE（Site Reliability Engineering，网站可靠性工程）和平台工程宛如坚不可摧的三大基石，稳稳撑起了从代码编写到最终成功上线、持续运维的整片苍穹。如今，随着大语言模型的横空出世，一场深刻变革正悄然席卷软件交付全生命周期的每一个角落，为这三大基石注入全新活力，开启软件交付迈向智能化、高效化、可靠化新纪元的大门。

1

大语言模型下的 DevOps

随着人工智能技术的发展，Ops 领域引入了更多创新技术，目前主要有两个方向，分别 是机器学习和大语言模型，最终形成了 MLOps（Machine Learning Operations）和 LLMOps。

1.1

MLOps 的来源

MLOps 是从 DevOps 演化而来的概念，是指将 DevOps 的理念和方法应用于机器学习 的开发、部署与运维环节，以提升机器学习模型的生产效率和质量。

MLOps 的概念源于企业在实际应用机器学习过程中遇到的挑战，主要涉及模型部署、 运维和监控等方面的问题。在传统的软件开发中，已形成一套成熟的 DevOps 流程，而 MLOps 则是在机器学习领域借鉴 DevOps 的经验与思想，为机器学习开发提供系统化、标 准化的解决方案。MLOps 的流程包括数据准备、模型训练、模型部署、模型监控、模型更 新等多个环节，如图 1 所示。

图 1 MLOps 的流程顺序

1.2

MLOps 的作用

在具体实践中，基于机器学习的特点，MLOps 的作用除了传统的 DevOps 能力外，还 新增了一些特定场景，如通过模型应用的方式重新定义场景、数据收集与整理、模型训练 与部署、持续监控与更新。然而，技术的迭代与更新都是为了提升软件交付的效率。

由于 MLOps 源于 DevOps，因此二者的基本理念相同，涵盖建设初期的工具化和自动 化阶段，推广过程中优化与反馈的路径也一致。然而，二者也存在一定差异，由于技术栈 的不同，导致触发对象和方式的不同。DevOps 的触发方式主要为代码的修改，而 MLOps 的触发方式不仅限于代码的修改，当数据发生变更或模型性能下降（模型衰减）时，也会触 发流水线。此外，MLOps 还包含构建和训练机器学习模型所需的额外数据和模型步骤，这 意味着 MLOps 在工作流的每个组件上存在细微差异。

此外，在工作流管理方面，DevOps 侧重于流水线的构建，而 MLOps 则更加关注机器 学习工作流的管理、自动化、模型的部署与监控。

1.3

基于 DevOps 的 MLOps 的流程

如 图 2 所示，标准的 MLOps 流程包括三个角色：数据工程师、模型工程师和 DevOps 工程师。数据工程师负责数据的标注，并确保数据的可靠性和可追溯性；模型工程 师负责模型的管理，并确保模型的可重复性和可迭代性；DevOps 工程师负责应用的部署与 监控。

1）数据阶段的主要工作为数据收集和预处理及特征工程。

●数据收集和预处理。该组件负责从各种数据源（如数据库、文件系统、API 等）中 收集数据，并对其进行预处理和清洗，以便用于机器学习模型的训练和推理。●特征工程。该组件负责将原始数据转换为可供机器学习模型使用的特征，包括特征 选择、特征变换和特征构建等步骤。

图 2 标准的 MLOps 流程

2）模型阶段的主要工作为模型训练、模型部署及模型监控和管理。

●模型训练。该组件负责利用训练数据进行模型训练，包括算法选择、模型参数调整 以及模型性能评估等步骤。

●模型部署。该组件负责将训练完成的模型部署至生产环境，以进行实时推理与预测。 它可能包括将模型打包为可执行文件、配置模型服务器及监控模型性能等步骤。

●模型监控与管理。该组件负责监控已部署模型的性能和运行状况，并根据需要进行 调整和更新。它可能包括对模型预测准确率、处理时间及资源使用情况等指标的 监控。

3）部署阶段的主要工作为软件发布。 尽管模型输出存在不确定性且难以重复，但将机器学习软件部署到生产环境的过程是 可靠且可重复的，并尽可能实现自动化。

1.4

LLMOps 的来源

LLMOps 是一组工具和最佳实践，用于管理 LLM 支持的应用程序生命周期，可视为 MLOps 的子类别，但二者之间存在一定差异。这些差异源于使用经典 ML 模型与 LLM 构 建 AI 产品方式的不同，主要影响数据管理、实验、评估和成本等方面。

2

大语言模型下的平台工程

在大语言模型的推动下，平台工程的开发和应用变得更加高效和灵活。通过将模型的 强大计算能力与平台工程相结合，企业能够更好地实现自动化、标准化和可扩展性。在这 一过程中，平台工程不仅仅是基础设施的构建和维护，更是整个开发流程的全方位优化。 此外，平台工程还通过大语言模型的智能分析能力，实现了更为精确的性能监控与优化。通过对大量数据的处理与分析，平台能够自动识别潜在的瓶颈和问题，并提出解决方案，帮助企业提高运维效率。

2.1

平台工程所遇到的挑战

根据 CloudBees 发布的最新报告《2023 年平台工程：快速采纳和影响》，83% 的受访 者已经完全实施了平台工程，或正处于某个实施阶段。根据报告中的数据，开发者每周实 际上只用了 12.5% 到 30% 的时间来编写代码。这也促使 IT 组织的管理者迫切寻找新的方 法来提高开发者的生产力，因此平台工程对创新技术的需求迫在眉睫，特别是机器学习技 术和大语言模型技术。

首先随着企业数据的不断积累，当数据越来越多时，数据的隐私和安全越来越重要， 尤其在大语言模型场景中，对于特定领域的数据训练，必然给传统的平台工程带来了挑战。 尤其在管理多个大型数据集和模型方面，平台工程需要集成机器学习算法和大语言模型。 其次，平台工程必须适应新的 AI 工作流程和数据、提示，以及设计、训练和维护模型、 向量数据库和大型数据集的 AI 工程师的流水线，这些数据集会不断增长和演变。这些 AI 流 水线必须支持其工作流模式的特定要求，并与相互依赖的软件开发流水线和发布流程一致。

最后，随着企业商业模式的变化，越来越多的业务系统采取了 GPU、VPU 和高度可扩 展的 CPU，用来运算大量的数据，这种方式也给传统的平台工程带来了挑战。为了让平台 发挥更大的作用，平台工程需要主动引入更多的创新技术。

2.2

常见的实践方式

由于平台工程主要面向企业内部开发者，业务需求作为开发过程的上游节点需要格外 关注，同样，开发者自身的工具也需要被关注。

（1）对业务需求进行自动化完善、分析与收敛

在需求自动化完善方面，平台工程结合大语言模型技术，能够对用户反馈和数据进行 分析，自动识别并补充缺失的需求信息。例如，自动识别用户提出的问题并转化为需求描 述，自动补全需求的关键词和标签。 在需求的自动化分析方面，通过数据训练自带的领域知识，可以更好地评估和优化需 求，发现潜在的问题和机会，提高需求分析的效率和效果。 在需求的自动化收敛方面，结合大语言模型技术，如智能推荐、对话系统、多方协作 等，能够帮助开发者更好地进行沟通与协同，更好地收集和整合用户反馈与痛点，提升需 求的满意度和一致性。

（2）更智能的开发工具

在现有开发工具功能的基础上，需集成软件交付过程中更多的能力，如自动化代码审 查、自动化测试、自动化日志分析以及 AI 辅助编程，以显著提升开发者的开发效率，并提 供良好的使用体验。 同时，基于 LLM 的能力，开发工具还可以对开发过程中的文档和代码进行分析，构建 知识库，提供开发者智能问答的能力，简化开发人员的学习成本，降低用户认知负荷。

3

SRE

SRE 与 DevOps 和平台工程相比，SRE 在软件交付过程中为软件交付人员提供了利用工具 解决系统稳定性和可靠性问题的方法，相关 SRE 体系内容可参考《SRE 实践白皮书》。

3.1

SRE 的目标

SRE 的主要目标是通过结合软件工程和系统运维的最佳实践，提高大规模分布式系统 的可靠性、可扩展性、性能和效率，以及监控和告警、故障恢复能力。

●可靠性：SRE 的首要目标是确保服务和系统的可靠性。这包括减少故障、提高系统 的稳定性，以确保用户在任何时候都能够获得一致的高质量服务。

●可扩展性：SRE 致力于设计和实施能够随用户需求增长而扩展的系统，涉及对系统 架构和资源的优化，以在不降低性能的前提下适应实际工作负载的波动。

●性能：SRE 关注系统性能，旨在确保系统能够在合理时间内快速响应用户请求，包 括对系统瓶颈的持续监控和优化，以提升整体性能。

●效率：SRE 倡导自动化运维工作，以减少人为错误并提高效率。通过自动化，可以 更快速地部署新功能、检测和响应故障，并合理开展系统的升级和维护工作。

●监控和告警：SRE 强调对系统的全面监控，以便及时发现并解决问题。通过设置有 效的告警系统，可以在重大问题发生前迅速做出反应，从而减少对用户的影响。

●故障恢复：SRE 强调迅速而有效地恢复服务，以最小化用户体验的中断。这包括制 订和演练紧急情况的应急计划。 企业实现 SRE 核心目标的过程并不相同，落地路径也各异。SRE 相关的实践工作存在 于大量流程中，与 SRE 部门或团队在企业中的存在形式和所处位置无关。这些工作流程与 研发、测试、运维、产品运营等团队紧密地融合在一起，所有参与团队都在上述 SRE 目标 上作出各自的贡献。

3.2

SRE 团队的存在形式

在组织架构中，SRE 团队的存在形式可以各不相同，这主要取决于组织的规模、业务 需求和文化。以下是一些常见的 SRE 团队的存在形式。

●中心化的 SRE 团队：由一个专门的 SRE 团队负责支持整个组织的可靠性工作。此 模式有助于集中专业知识，确保在全组织范围内实施一致的最佳实践。

●嵌入式的 SRE 团队：SRE 团队成员嵌入到各产品或服务团队中，与开发团队紧密 合作。此模式有助于将可靠性工作更好地集成到产品开发全过程中。

●混合模式：部分组织采取混合模式，即既设有中心化的 SRE 团队，同时在一些关键 项目中嵌入 SRE 角色。此模式能够兼顾专业化和与业务紧密结合的优势。 每种存在形式都有其优势和适用场景，可根据组织的需求选择最合适的模式。不论哪 种方式，SRE 的目标都是通过自动化和工程方法提高系统的可靠性和效率。

如图 3 所示，SRE 工程组采取中心化设置，负责 SRE 体系的建设与推进，驱动 SRE 平台研发组和基础设施组，提供高效能的工具与平台产品，提升基础服务的可靠性。

图 3 中心化设置的 SRE 组织

大语言模型给软件交付领域带来颠覆性变革，为 DevOps、平台工程与 SRE 三大基石注入新动能。MLOps 与 LLMOps 融入 DevOps，完善机器学习模型生命周期的开发运维协同流程，让软件迭代更智能敏捷；平台工程借力应对挑战、探索实践，筑牢底层支撑；SRE 锚定可靠运维目标，以多样团队形式保障系统平稳。未来，三者将深度融合，大语言模型会渗透各环节，助力优化流程、攻克难题、提升应急能力，推动软件交付迈向高质量、高效率、创新性的新高度，重塑产业生态。

本文摘编于《大模型驱动的研发效能实践》（书号：9787111772347)，经机械工业出版社授权发布。

4

关于作者：

顾黄亮

资深 DevOps/研发效能专家，有多年的运维研发经验，专注企业 IT 数字化转型和落地，致力于企业智慧运维体系的打造。现在就职于某持牌金融机构。中国商联专家智库入库专家、国家互联网数据中心产业技术创新战略联盟智库专家委员会副主任委员、江苏银行业和保险业金融科技专家委员会候选专家、工信部企业数字化转型 IOMM 委员会特聘专家、中国信通院可信云标准特聘专家、中国信通院低代码/无代码推进中心特聘专家，腾讯云最具价值专家 TVP，阿里云最有价值专家 MVP。著有畅销书《DevOps 权威指南》《企业级 DevOps 实战案例：持续交付篇》《研发运营一体化（DevOps）能力成熟度模型》和《企业 IT 运维发展白皮书》核心作者，多个技术峰会演讲嘉宾。

郑清正

金融科技研究中心高级研究员，英国杜伦大学计算机系博士，英国斯旺西大学计算机软件工程硕士，曾任华为技术规划工程师、图像研究工程师。专注研究金融大数据风控、机器视觉等领域。 参与人脸识别、电信 CRM、内存数据库等系统开发；发表论文 3 篇，授权专利 3 篇。

牛晓玲

DevOps 标准工作组组长，DevOps 国际标准编辑人。长期从事开发运维方面的相关研究工作，包括云服务的运维管理系统审查等相关工作。参与编写《云计算服务协议参考框架》《对象存储》《云数据库》《研发运营一体化（DevOps）能力成熟度模型》《Y.3525　Cloud computing-Requirement for cloud service development and operation management 》《云计算运维智能化通用评估方法》等 20 余项国内标准和国际标准。参与评估 DevOps 能力成熟度评估超过 50 个项目，具有丰富的标准编制及评估测试经验。

车昕

中国信通院云计算与大数据研究所政企数字化转型部副主任，主要从事企业数字化转型成熟度模型 IOMM、可信数字化服务、数字基础设施一体化云平台、中台系列、低/无代码、组装式、安全生产、智慧运营等领域技术研究和转型咨询规划，制定相关标准、开展评估测试、组织技术实践交流等工作。