科技DevOps复杂，AI难胜任，开发者厌恶。Stakpak致力于让AI可靠处理非编码DevOps任务，解决安全、工具碎片和知识共享难题，提升自动化。
译自：Self-Driving DevOps? How Stakpak Tackles Infrastructure Complexity
作者：Meredith Shubel
科技领域的一切似乎总是在以惊人的速度变化——除了 DevOps 基础设施。
实际上，Stakpak 的联合创始人兼首席执行官 George Fahmy 表示，管理基础设施正变得越来越困难——尽管人工智能浪潮汹涌。或者，也许正是因为人工智能？
“自从大型语言模型（LLM）问世以来……我们意识到它们在编程方面非常出色——而且大多数开发人员实际上很喜欢编程，”他评论道。“但对于开发人员必须处理的所有其他事务，它们却一塌糊涂。”
这正是他与 Stakpak 团队致力于改变的：“让大型语言模型在开发人员实际上不喜欢做的所有事情上都变得可靠。”
开发人员不喜欢做（且人工智能无法处理）的“事情”
Fahmy 认为现在是时候对 DevOps 基础设施 进行全面改革了，他指出，即使是自动驾驶汽车在近年来的进展也超过了基础设施工具。
正如他所说：“我们正努力让基础设施实现自动驾驶，这样开发人员就能有更多时间……构建实际产品。”
那么，开发人员不喜欢做的这些“事情”到底是什么呢？
这很难定义。DevOps 已经变成了一堆杂乱的职责，它超越了编码，涵盖了设置本地机器、配置云环境以及管理部署流水线和生产系统等任务。
正是这种包罗万象的混合使得 DevOps 对于大型语言模型来说成为了一个 尴尬的领域。
“对于编程任务，你只需生成代码并运行……但对于 DevOps，除了编程之外，还有数百万件事情……而大型语言模型在这方面表现不佳，”Fahmy 说。更糟糕的是，开发人员“讨厌做所有这些事情”。
两端都存在问题。DevOps 任务不仅对开发人员来说是出了名的繁琐，执行这些任务所需的技能也让行业感到匮乏。在 Linux 基金会发布的《2024 年技术人才状况报告》 中，51% 的组织将 DevOps 列为“优先配置人员的关键技术领域”之一，而填补这些职位的平均时间接近六个月。
“在全球市场上，关于这类知识和专业技能存在巨大的技能差距，”Fahmy 证实。“人们一直在努力招聘 DevOps……和 DevSecOps……但他们找不到人才。”
如今，当时间紧迫和熟练劳动力短缺时，自动化——更具体地说是人工智能——被寄予厚望，希望它能填补空白。但 Fahmy 表示，这对基础设施来说并不奏效：
“我们看到编码代理……它们擅长编码，但它们并非为这种基础设施工作而构建。”
在他看来，这归结为三个核心挑战。
挑战 1：保护生产系统和秘密信息
DevOps 需要在实时系统上工作并处理敏感数据——但 Fahmy 表示，目前大多数 AI 代理 依赖的工具在生产级安全性方面并不达标。
“这就是为什么我们开始重建这个工具层并将其开源，”他解释说，“因为我们希望设定一个标准，以确保这些工具足够安全，能够处理生产工作。”
他指的是 Stakpak，这是一个 完全开源的 DevOps 代理，旨在帮助开发人员安全地部署、维护可用于生产环境的基础设施。
根据 Fahmy 的说法，Stakpak 通过让大型语言模型在不暴露秘密的情况下与敏感系统交互来解决这个安全挑战：“我们负责编辑敏感信息和秘密，并允许大型语言模型处理敏感数据，而无需看到实际的敏感数据。”
挑战 2：防止跨碎片化工具的破坏性操作
安全性并非唯一阻碍开发人员安全自动化基础设施工作的障碍。基础设施管理工具数量的增长也带来了麻烦。
“有数百种不同的工具和数百种不同的方法来做同一件事，”Fahmy 解释说，“所以你可以使用三四种不同的工具……或者你可以将它们堆叠起来。”
这听起来很方便：更多的选择，更大的灵活性。但实际上，铺天盖地的工具（以及随之而来的所有相互冲突的观点）只会带来更多的混乱、摩擦和风险。
当人工智能代理——那些本应帮助开发人员管理工具的代理——最终却制造了新问题时，麻烦就更大了。
Fahmy 回忆起现在臭名昭著的 Replit 惨败，其中一个代理意外地清除了某家公司的整个代码库。
“这些代理和模型——它们都超级有创造力，”他说。“它们可以找到许多不同的方法来做同一件事……对于试图控制它们的人来说，这是一场噩梦。”
他声称，Stakpak 可以通过 Warden 来消除这场噩梦，Warden 是一个护栏系统，可以阻止代理执行破坏性操作。
怎么做到的？Fahmy 说，它将编码代理封装在一个沙盒中，其中明确的安全规则会阻止不安全的操作：“例如，你可以在 AWS 中列出你的资源，但无论你使用什么工具来处理 AWS，你都不能删除它们。”
他解释说，这与他声称无效的典型代理控制方法截然不同：“你不能用一个代理来阻止另一个代理搞破坏。”你也不能简单地列入黑名单或白名单特定的操作，那样就创建了手动枚举每种可能场景的不可能任务。
相反，Warden 提供了一种确定性的方法来阻止代理执行破坏性操作，无论它使用何种工具。
诚然，Fahmy 表示这对于编码来说并不是特别有价值。但他肯定这对于操作任务来说是一个游戏规则改变者，比如数据库迁移、更新或其他基础设施变更，在这些任务中“一个错误的命令就能让整个系统崩溃”。
挑战 3：教会代理学习、共享和记忆知识
Fahmy 毫不隐瞒地指出：“大型语言模型在基础设施工作方面表现糟糕。”
他将这很大程度上归因于碎片化：DevOps 团队沉浸在各种工具中，但每种工具都使用不同的语言。大型语言模型只会可靠地处理最常见的编程语言，这使得情况变得更糟。
这就是为什么 Fahmy 说 Stakpak 将大量研发投入到大型语言模型的知识空白领域：“教授大型语言模型使用它们从未训练过的新工具……；获取它们以前从未见过的新知识……这超级具有挑战性。”
与可以通过创建新规则文件来添加知识的编码代理不同，DevOps 代理需要一个共享的知识库才能有效运作——Fahmy 表示 Stakpak 正在通过集中的规则手册和共享内存来实现这一点：
“我们认为这将是一个游戏规则改变者，因为基础设施领域不缺乏大量的工具……它缺乏一种学习新知识然后传达新知识的有效方式。”
Stakpak 通过定义标准操作程序的集中式规则手册以及衡量一致性的内部评估基准来实现这一点，以确保代理在适应每个环境时始终遵循正确的程序。
这只是等式的一部分。同时，共享内存允许代理从过去的会话中学习。当团队成员完成一项任务时，推理模型会提取关键记忆，这样当 代理被另一位团队成员使用时，它就会记住并应用所学到的知识。
这个共享内存池打破了知识孤岛，Fahmy 将其描述为 DevOps 中最大的障碍：“平台或基础设施团队可能已经创建了一些东西，但开发人员仍然不知道……或者不知道它能让他们的生活更轻松。”
下一个挑战
当然，这并不是基础设施自动化的终点。Fahmy 表示 Stakpak 已经开始着手下一个阶段：让代理实现自我改进。
“如果你能获取好或坏的示例，并将其反馈给系统，帮助它微调自己的参数，从而在使用过程中变得更好，那会怎么样？”
随着自动化的进步，DevOps 基础设施可能终于开始迎头赶上——对于厌倦了处理所有这些“事情”的开发人员来说，这是一个受欢迎的升级。
