云运维演进为三层堆栈：IaC定义状态，平台提供护栏和行为管理，AI代理实现日常操作自动化。新模式提升效率、安全与弹性。
译自：The New Operational Stack: From IaC to Platforms to AI Agents
作者：Fahmid Kabir
基础设施即代码（IaC）成为云资源配置的支柱已经十年了。Terraform、CloudFormation、Pulumi 和 Ansible 为我们提供了定义基础设施状态的结构化方式。它们也为我们提供了思考版本变更的方式，并使云环境可复现。
简而言之，IaC 带来了整个 DevOps 成熟度时代。
但如今，很多事情都已改变。系统变得极其复杂。我们拥有更多：
- 微服务
- SaaS 集成
- 托管服务
- 云功能和边缘计算
当然，IaC 本身也开始显现其局限性。
现在，团队依赖于数十个相互连接的服务。配置、安全和 运行时行为无法纯粹以代码形式捕获。与此同时，开发者期望自助服务和运营速度。而这些期望只会不断提高。
为此，我们现在拥有了一个新的运维堆栈来向前推进。
它由三个不同层的组合构成：
- IaC
- 平台/编排层
- 用于日常运维的 AI 代理
这些层并非替代品，而更多是现有事物的演进。每一层都解决了运维问题的不同部分。它们共同定义了未来十年团队如何操作云基础设施的现代模式。
1. IaC 时代：资源配置是第一个大挑战
事情是这样的：IaC 给混乱带来了秩序。
它通过解决三个基础性问题做到了这一点：
- 声明式配置： 工程师描述他们想要什么，而不是如何构建它。
- 版本控制： 变更通过 Git 流动，而非经验主义知识。
- 可复现性： 环境匹配，因为代码匹配。
当然，对于静态或缓慢变化的基础设施来说，这运行得非常完美。
但现代云并非静态的。
IaC 在今天的困境
随着系统增长，团队很快意识到 IaC 并不能完全解决以下问题：
- 状态漂移和配置错误。
- 轮换密钥或身份和访问管理 (IAM) 更新。
- 临时环境创建。
- 事件修复。
- 可观测性的依赖项连接。
- 合规性强制执行。
- 身份范围和网络边界。
- 操作调试。
- 需要序列、审批或上下文的多步骤工作流。
底线是 IaC 从未旨在处理如此多的事物。它无法处理运行时行为、自适应工作流或持续操作。
毕竟，它描述的是对象，而不是动作。
幸运的是，下一层及时出现填补了这一空白。
2. 平台时代：护栏、标准化和上下文
大约在 2018-2020 年，工程组织开始构建内部开发者平台 (IDPs)。目标不是取代 IaC，而是将其封装在一个一致的运维模型中。
平台是一组协调系统，提供：
- 身份边界： 一致应用的 IAM 角色和策略。
- 网络边界： 受控的入口/出口和微分割。
- 合规性护栏： 针对 SOC 2、HIPAA、NIST、PCI 的控制。
- 自动化连接： 日志、指标、追踪、仪表盘、警报。
- 环境模板： 一键式环境或命名空间创建。
- 服务目录： 数据库、队列、API 的一致配置。
平台层位于 IaC 之上，但低于开发者工作流。
但 IaC 仍然是资源的权威描述。
现在，平台成为运维如何工作的权威描述。
平台为何出现
三个结构性转变使其成为必然：
- 微服务产生指数级复杂性： 每一个新增服务都会增加监控要求、IAM 角色、网络规则、部署工作流、服务水平目标 (SLOs) 和策略表面。
- 合规性要求持续证据： 现代审计需要持续监控，而非年度快照。IaC 可以定义安全策略，但平台必须强制执行它们。
- 开发者速度不能依赖专家： 开发者需要自助服务环境和服务。平台将云原语抽象为可预测的工作流。
平台 ≠ 平台即服务 (PaaS)
与普遍的看法相反，平台并不隐藏云。它组织云。
它围绕身份、网络和生命周期自动化创建了 IaC 无法单独强制执行的观点。最重要的是，它引入了逻辑边界，如租户（本系列第 2 部分将详细介绍），护栏可以附着在这些边界上。
这种平台化为下一个时代奠定了基础。
3. AI 时代：自动化日常运维
云运维的下一个重大转变发生在 AI 能够做到以下几点时：
- 关联日志、指标和追踪
- 理解自然语言请求
- 将症状映射到根本原因
- 应用运行手册式修复
- 生成基础设施变更
- 编排多步骤工作流
它的职责不是取代 DevOps 工程师，而是取代通常让 DevOps 工程师不堪重负的重复性任务。
AI 代理实际做什么
运维中的 AI 代理可以：
- 使用跨系统的信号诊断事件。
- 修复已知模式（如重启、配置补丁、扩缩容）。
- 创建或销毁临时环境。
- 强制执行合规性或安全策略。
- 为新基础设施生成 Terraform 或 YAML。
- 提出变更建议并附带解释，请求人工审批。
这些任务遵循 AI 可以可靠识别的模式。
但有个陷阱：没有护栏的 AI 是危险的
一个不受约束的 AI 代理就像一个没有上下文的 root 用户。
原因如下：
- 它可能生成不安全的 IAM 变更。
- 它可能修改不应该看到的资源。
- 它可能尝试违反合规性要求的修复。
- 它可能由于漂移或部分可见性而误解拓扑结构。
这就是为什么 AI 层不能直接位于 IaC 或原始云 API 之上。
AI 需要：
- 可预测的身份模型
- 范围化的权限
- 一致的网络边界
- 审计日志
- 漂移检测
- 已知拓扑
- 审批工作流
换句话说，AI 需要一个紧邻它的平台。它需要一个带有护栏的结构化层。没有这个，代理就无法安全地行动。
4. 三层模型
第 1 层：IaC
定义状态。
资源配置、模板、版本控制。
第 2 层：平台/编排器
定义行为。
护栏、边界、身份、网络、合规性、编排。
第 3 层：AI 代理执行层
定义行动。
故障排除、修复、环境管理和工作流自动化。
这个分层堆栈反映了软件的演进：
- IaC = 代码。
- 平台 = 操作系统。
- AI 代理 = 作用于系统的运行时进程。
- 没有操作系统，进程就没有结构。
- 没有 IaC，操作系统就无物可编排。
5. 组织影响
- DevOps 瓶颈缩小： 最重复、最容易被打断的任务转移给 AI 代理。
- 开发者获得真正的自助服务： 他们与平台交互，而不是与单个云 API 交互。
- 合规性持续化： 检查在平台边界内运行，AI 帮助维护控制。
- 生产环境更具弹性： AI 代理在人类发现问题之前捕获它们。
- DevOps 人员较少的团队也能像大型团队一样运作： 规模从人力劳动转向分层自动化。
总结
IaC 为团队提供了声明式基础。
平台为团队提供了结构和护栏。
AI 代理现在为团队提供了操作执行能力。
这就是新的运维堆栈。它不是一个简单的工具趋势。相反，它是一个结构性转变。
认识并采纳这种三层架构的组织将能够更快、更安全地运作，并大大减少运维摩擦。
不再需要通过增加人员来扩缩 DevOps，因为现在你可以通过结构来扩缩。
无需依赖英雄主义和经验主义知识。你可以依赖平台和自动化。
AI 不必是一个冒险的实验。将其部署为一个受身份、策略和上下文约束的受控执行层。
这种三层组合将定义未来十年的云运维。
在 DuploCloud，我们很高兴能成为 AI 进步的一部分，不断学习、摸索、再学习，最重要的是，创造并参与塑造未来的创新。
我们诚挚邀请您试用我们的 AI DevOps 代理沙盒。
