技术摘要：面向多服务环境的规范驱动型 DevOps

问题陈述

随着利用大语言模型（LLM）从代码仓库制品生成可执行软件环境的应用日益广泛，一个关键差距也随之显现：功能上的可执行性并不等同于符合部署意图。 虽然 LLM 通常能够成功合成并运行 Dockerfile 和 Docker Compose 配置，但它们往往无法重建开发者意图中隐含的架构、安全、工作流及生产约束。

现有研究主要集中在单容器环境，或假设基础设施意图已通过自然语言提示（prompt）显式提供。然而，在多服务环境中，关于网络分段、端口暴露策略、构建策略（如多阶段构建）、密钥管理机制以及开发与生产模式等关键决策，往往并未在源代码中进行显式编码。本研究调查了前沿 LLM 是否能仅通过仓库制品可靠地推断出这些“仅存在于意图中”的约束，并提出了一种**规范驱动型 DevOps（Specification-Driven DevOps）**方法，以弥合可观测的运行时事实与显式部署策略之间的鸿沟。

研究方法

本研究采用基于仓库驱动的生成实验，涉及三个异构的多服务应用：

1. example-voting-app： 一个异构技术栈（Python, Node.js, .NET），包含 Redis 和 PostgreSQL。
2. react-rust-postgres： 一个 React/Rust/PostgreSQL 技术栈，具有隐藏的代理配置且输入中缺失凭据。
3. react-java-mysql： 一个 React/Java/MariaDB 技术栈，采用基于文件的密钥机制（db/password.txt）。

实验约束：

• 输入： 仅包含源代码、依赖清单、配置文件及辅助制品。现有的 Dockerfile 和 docker-compose.yml 文件被明确排除在外。
• 模型： 通过 GitHub Copilot 使用 GPT Codex 5.3。
• 平台： Apple M1 Pro (ARM64)。
• 验证：
  • 功能预言机（Functional Oracle）： 通过确定性的端到端 HTTP 请求，验证完整的多服务流水线（例如：投票提交通过 worker 传播至数据库的过程）。
  • 结构对比： 通过人工分析将生成的制品与开发者编写的基准真相（ground truths）进行对比，以评估其在安全性、工作流和生产就绪性方面的保真度。

形式化框架：
本研究将转换过程形式化为 $T_M: R \to E$，其中 $R$ 代表仓库，$E$ 代表生成的环境。研究区分了：

• 功能正确性 ($E_G \equiv_F E_D$)： 环境可以运行并通过预言机测试。
• 部署意图保真度（Deployment-Intent Fidelity）： 生成结构的结构与开发者架构及策略决策的匹配程度。

核心贡献

1. 经验边界定义： 本研究建立了一个 DevOps 知识分类法，将其分为：
   • 可观测/可推导项： 服务拓扑、端口、依赖关系和后台工作进程（成功推断）。
   • 欠定项（Underdetermined）： 特定的凭据值或兼容的镜像版本（虽有推断，但可能与基准真相不一致）。
   • 仅存在于意图中： 网络分段、端口暴露策略、构建策略及生产服务模式（一致性地被忽略或采用了默认设置）。
2. 规范驱动型 DevOps 模型： 本文提出了一种混合生成模型 $E = G(R, S_{min})$，其中 $S_{min}$ 是最小显式部署规范。该规范仅包含无法从仓库中可靠推断出的不可还原意图，从而避免了与源代码中已有信息的重复。
3. 评估框架： 提出了“可执行正确性”与“结构保真度”的区别，引入了一个多维评估模型，将安全性、工作流、可移植性和生产就绪性与功能执行分开进行评估。
4. 最小规范模板： 推导出了一个用于解决观察到的遗漏问题的概念性 YAML 模板，涵盖了部署上下文（开发/生产）、网络分段、构建策略（多阶段构建）、密钥机制和平台约束。

结果

功能成功率：

• 在解决了一个基础镜像版本冲突（Rust 1.85 至 1.88）后，所有三个生成的环境均实现了功能性运行状态（成功率 100%）。
• LLM 成功重建了复杂的服务拓扑，包括后台工作进程、隐藏的代理配置以及基于文件的密钥机制。

结构与意图缺陷：
尽管功能成功，但生成的环境在部署意图方面表现出系统性的遗漏：

• 网络分段： 所有环境均被生成为扁平网络（0/3），未能实现后端服务与公共访问的隔离。
• 端口暴露： 在 2/2 个适用案例中，后端端口都被不必要地暴露给了宿主机，违反了严格的安全策略。
• 构建策略： 未生成任何多阶段构建或优化的依赖层缓存（0/3）。
• 生产服务： 前端服务使用了开发服务器而非生产就绪的 Nginx 配置（2/2 适用案例中均为 0/2）。
• 工作流： 缺少用于开发的实时重载（live-reload）卷挂载（0/3）。

可追溯性：
研究表明，虽然运行时依赖是可观测的，但负向约束（例如“不要暴露此端口”）和策略决策（例如“使用 Docker secrets”）无法仅从源代码中可靠地推断出来。

意义与主张

本文谦虚地声称已识别出一个实际边界，即哪些内容可以从仓库制品中推断，而哪些内容必须显式指定。

• 非通用解决方案： 作者明确指出，研究结果适用于所评估的三个仓库，并不声称对任意微服务生态系统具有普遍可靠性。样本量较小，且仓库的选择可能引入了熟悉度偏差。
• 分析性推导： 所提出的最小规范和混合生成模型 ($G(R, S_{min})$) 是通过观察到的差距进行分析性推导得出的。本研究并未通过使用该规范重新运行生成过程来实验性地验证该规范的有效性，而仅提出了该框架。
• 核心洞察： 主要贡献在于对“信号差距”的形式化。研究结论认为，仓库证据足以重建运行时需求，但不足以重建部署意图。因此，为了确保生成的环境不仅是可执行的，而且是安全的、可维护的且符合生产策略，采用规范驱动型方法是必要的。

本文将自身定位为一项探索性可行性研究，旨在强调在 DevOps 背景下，显式的、机器可处理的规范对于补充 LLM 驱动的代码生成的重要性。