大多数软件开发团队都能讲出几段“部署事故”的战争故事。正是这些故事，把我们推上了现代化交付实践的道路。
举个例子：经过数周甚至数月的功能开发、大规模重构，以及漫长的测试与稳定阶段，团队终于准备发布。开发、运维、一群经理，甚至一些高管，会聚在“作战室（war room）”。在此之前，开发与运维之间几乎没有协作；但此刻，这两个群体却要临时组成一支队伍，开始逐条勾选那份冗长的清单或“剧本”中的手工步骤。
然而，即使清单做得面面俱到，也无法保证部署万无一失。由于本次发布改动众多，部署往往复杂而高风险。正如后续章节将看到的，依赖管理极具挑战，“依赖地狱”并非虚言。团队可能会发现生产环境缺少关键依赖；又或者安装了不兼容的库版本；某个关键配置项被错误设置；迁移步骤失败或被遗忘；抑或变更导致对某个合作方服务的请求频繁失败。
任何一个小失误，都可能让本已复杂的部署彻底脱轨。紧张情绪上升、四处救火、时间被不断拉长。团队希望能在部署窗口内完成上线以及随后的人肉冒烟测试。如果部署彻底失败、无力补救，他们还得祈祷回滚到旧版本不会引发意外困难，从而进一步拉长停机时间并增加复杂度。部署终于结束时，精疲力竭的团队退场。但通常他们还得在流量恢复后的“关键观察期”保持高度警惕。接下来可能还有几天到几周的“稳定期”，在此期间开发团队暂停所有新功能，专注于热修复与打补丁。
如上故事所示，重负高压的大型生产发布让开发与运维都疲惫不堪。此类大规模上线与随后的稳定周期，分散了团队的注意力，使他们无法持续交付对业务有价值的功能。
与之相对，现代软件交付对从开发者电脑到终端用户的全过程进行了简化与加速：部署频繁、低戏剧性、低风险，并且高度自动化。但我们正步入一个超越“自动化”的新纪元——AI 原生软件交付。
AI 原生交付将 AI 编织进软件交付生命周期的每一层，使智能体能够做决策、优化流程并实时自适应。这些智能体——从代码、DevOps 到安全、测试——可自治协作、强制合规、自愈基础设施，并借助强化学习持续优化交付流水线。转变体现在：从被动治理到主动治理；从工具烟囱到统一生态；从静态自动化到动态自治。
随着 AI 生成代码、编排流水线、减少手工劳动，开发速度大幅提升。系统的韧性与安全性也随之增强——AI 能够预判问题并自主修复。同时，云成本通过智能优化而下降；借助 AI 驱动的智能体在团队间进行机器速度的协调与决策，协作规模得以扩大。
本章将回顾过去 25 年软件交付的演进；定义 DevOps 并说明 DevOps 实践如何支撑现代交付；梳理当前 DevOps 面临的诸多挑战；最后概览现代交付、DevOps 实践与 AI 原生路径如何应对这些挑战并进一步演进。
Development + Operations = DevOps
“DevOps”一词通常归功于 Patrick Debois。2009 年，他将“开发（Development）”与“运维（Operations）”合在一起，为他组织的一次会议命名，探讨如何打破开发与运维之间的传统壁垒，以更快地交付软件。造成这些壁垒的两个主要因素是：
沟通与协作不畅
开发者常常只关注写代码和做功能，然后把“完成品”隔着想象中的“墙”扔给运维。运维随后承担在生产环境中部署、运维与故障排除的责任。
优先级冲突
开发团队优先追求快速开发与快速发布新功能；而运维团队则侧重系统稳定性、安全性与避免停机。尽管优先级不同，这两个团队却天然相互关联、彼此依赖。无论代码多漂亮、基础设施多精良，不在生产环境稳定运行以服务业务目标，就没有真正的价值。
这种目标错位，有时被称为“长期慢性冲突（the core chronic conflict）”，在问题出现时常导致摩擦与相互指责。
作为回应，DevOps 原则鼓励在每个阶段进行沟通；鼓励运维尽早介入开发，并在代码部署后长期与开发共同负责其运行。
DevOps 简史
不断成熟的软件团队、新的软件方法论与新工具为 DevOps 铺平了道路。本节将简要回顾这些因素。
2000 年代的敏捷（Agile in the Aughts）
2000 年代初，组织对如何提升软件交付效率的新思路愈发感兴趣。源自精益制造思想的“敏捷（Agile）”方法论开始流行。敏捷反对强调大量前期规划、严格线性阶段的“瀑布式”交付模式；它提倡更短的开发周期与频繁发布，并能高度响应变化。多条平行路径推动了敏捷实践的成形：1995 年论文正式化了 Scrum 实践；Kent Beck 在 1999 年的《Extreme Programming Explained》（Addison-Wesley）中阐述了一套敏捷开发实践；2001 年，Beck 及其他敏捷倡导者在**《敏捷宣言》中共同表达了相似主张，强调适应性与响应性胜过对计划的僵化遵循。DevOps 借用了宣言第一条原则中的术语“持续交付（continuous delivery） ”：
“我们的最高优先级是通过尽早且持续地交付有价值的软件**来让客户满意。”¹
Jeffrey Fredrick 指出，Ken Schwaber 的三本 Scrum 著作（2001→2007）的演进，某种程度上可作为敏捷成熟度与组织渗透的晴雨表。其间 Scrum 迅速崛起为主流敏捷实践，因其结构清晰、角色规范且易于跨团队适配：
- 2001 年， 《Agile Software Development with Scrum》 （Pearson）向开发者与小团队介绍该框架；
- 2004 年， 《Agile Project Management with Scrum》 （Addison-Wesley）聚焦落地实践问题，显示其在更广泛 IT 领域的采用；
- 2007 年， 《The Enterprise and Scrum》 （Microsoft Press）回应了将敏捷扩展到企业级的需求。
这些著作反映并塑造了敏捷从边缘理念走向企业刚需的历程。
持续集成与持续交付（CI/CD）
接下来十年，技术组织愈发受到敏捷思想影响，其中一个结果是**持续集成（CI）与持续交付（CD）**实践的普及。
《敏捷宣言》催生了持续集成这一实践，它实现了敏捷的关键信条——频繁交付可工作的软件。开发者将代码变更合入共享代码库；每次合入都会触发自动化构建与测试。这一自动系统能够快速发现错误与冲突，使团队在开发早期修复问题。持续集成鼓励更小、更频繁的更新，从而加快交付、减少集成问题并保持更健康的代码库。
持续交付是持续集成的自然延伸。CD 将通过集成构建与测试的代码自动化地“推到可发布状态”，包括打包、配置、部署到预生产环境等步骤。CD 让团队能够快速、可靠地推出新功能、修复与更新，确保随时都有可发布的软件。
在每个开发周期结束时交付“潜在可发布产品（potentially shippable product） ”是另一项关键敏捷实践。所谓“潜在可发布”，意味着软件可靠、已测试、已打包，可以部署到生产。（在实践中，许多采用 CD 的组织只在内部持续交付，但仍不频繁地部署到生产。持续交付 ≠ 持续部署。）
早期 DevOps 的重要里程碑
与更侧重软件交付生命周期规划与执行环节的敏捷方法论不同，早期 DevOps 关注的是交付与运维。自 DevOps 概念出现后的数年里，这一运动迅速升温。关键里程碑之一是 2009 年首届 DevOpsDays 大会的召开，该活动汇聚了从业者，分享各自对于 DevOps 实践的经验与见解。
另一个重要事件是 2010 年 Gene Kim、Kevin Behr、George Spafford 合著的《The Phoenix Project》（IT Revolution Press）出版。该书以叙事的方式描绘了一家虚构 IT 组织所面临的挑战，以及如何通过采纳 DevOps 原则与实践实现绩效的戏剧性反转，它以技术与非技术读者都能产生共鸣的方式，为 DevOps 提供了有力论据。翌年，又有一本具有深远影响的著作问世：Gene Kim、Jez Humble、Patrick Debois、John Willis 合著的《The DevOps Handbook》，这本实践指南为众多组织开启 DevOps 之旅提供了全面的实施框架。
2013 年，Puppet Labs（今 Puppet） 发布的首份《State of DevOps》报告（作者 Kim 与 Humble）引发关注。该报告并未只关注技术指标，而是强调了 DevOps 采纳带来的业务收益：实施 DevOps 的组织发布代码的速度是同行的 30 倍，失败率降低 50% 。这把 DevOps 实践与领导者关心的业务结果直接关联起来。随后，Nicole Forsgren、Jez Humble、Gene Kim 合著的《Accelerate: The Science of Lean Software and DevOps》（IT Revolution）对这一主题做了更深入的探讨。
同在 2013 年，PaaS（平台即服务）与 Docker 的出现标志着又一个转折点，这些技术简化了应用的部署与管理，使大规模推行 DevOps 更加可行。在此之前，管理基础设施与应用的复杂性使 DevOps 难以广泛落地。2014 年，AWS Lambda 的推出以规模化的事件驱动函数执行进一步改变了格局，使开发者能够专注于编写代码而无需操心底层基础设施；与此同时，同样在 2014 年发布的 Kubernetes 为大规模编排容器化应用提供了坚实框架，确保部署可靠、高效且可扩展。
到本十年后半段，机器学习（ML） 开始渗入 DevOps 工具链，尤其是在 APM（应用性能监控）与测试领域。测试工具使用 ML 来优化测试执行、检测用户界面变化；而 Datadog、New Relic 等 APM 工具较早以“AIOps”自居，利用 ML 识别异常信号。到了 2018 年，Harness 将 ML 应用于持续交付，用于检测问题信号，从而在部署引发行问题时自动识别并触发必要的回滚。上述技术共同为现代 DevOps 打下了基础，提供了高效管理复杂软件系统所需的工具与框架，也为 AI 原生 DevOps 铺平了道路。
DevOps 1.0
DevOps 已从松散的小众概念发展为一套成熟的方法体系，可称为“DevOps 1.0”。其特征包括：
文化转型
重视文化层面的变革，使开发与运维团队目标一致、协同共进。
自动化实践
实施持续集成（CI）与持续交付（CD）等实践，简化并加速软件交付。
自动化工具
在交付流水线的各个阶段使用专门工具实现自动化——包括代码提交、测试、部署、资源配置与生产监控等。
早期采纳 DevOps 1.0 实践的组织很快就收获了成效。2010 年代早期，许多工程团队仍以季度为单位发布软件，需要耗费数周进行手工测试、协调与生产部署。这类发布流程缓慢、易错，且常需非工作时段来降低风险。随着组织开始拥抱 DevOps 的早期原则——让开发与运维更紧密合作，并对交付流水线的关键环节进行自动化——他们实现了更快的发布节奏、更高的可靠性与更少的手工工作量。对许多团队而言，这一转变使发布从季度改为双周，甚至每周，为更迭代的开发方式与更快的价值交付奠定了基础。
DevOps 1.0 面临的挑战
DevOps 1.0 提供了有价值的理念、实践与工具。不过，今天的企业在充分释放 DevOps 价值时面临新的挑战，主要来自于：
- 软件趋势带来的复杂性，迫使 DevOps 必须适配演进
- DevOps 1.0 工具链要么功能不足，要么对许多组织来说已过度复杂
下文将逐一展开。
迈向云原生与微服务架构
新的架构范式意味着要将数十个离散微服务分别部署到独立容器中。DevOps 1.0 时代的流水线并未为此类新架构的需求而生。
过去十年，出于对可扩展性、灵活性与敏捷性的追求，微服务与云原生逐步成为现代开发的事实标准，也给 DevOps 团队带来全新要求：微服务的采用导致待部署服务数量激增，每个服务都有自己的依赖与配置。如何在这些分布式服务之间编排部署并保持一致性，愈发困难。
容器（云原生的关键要素）与 Serverless 的使用，要求新的部署与管理策略，也叠加了复杂度。DevOps 团队如今需要在数十甚至上百个短暂存在的容器或函数之间进行部署，因而必须具备健壮的编排工具、覆盖容器全生命周期的自动化流程（镜像构建、推送到仓库、低停机滚动更新等），并深入理解这些新兴技术。自动化容器全生命周期是高效容器管理的关键。
开源软件的兴起
开源软件（OSS） 已成为现代开发的无处不在的组成部分。尽管开源带来诸多好处，但也给 DevOps 团队引入挑战：管理依赖、确保不同版本的兼容、为多个开源组件及时打安全补丁，都是艰巨任务。此外，团队必须严格审查引入的代码，并确保其符合组织的安全与合规标准。
数字体验的重要性与企业技术的消费化
在数字化颠覆的时代，Marc Andreessen 的论断“软件正在吞噬世界”愈发精准。企业提供的数字体验正成为客户的首要触点，直接塑造品牌感知。同时，企业技术的消费化意味着员工也期待与面向消费者应用相同的无缝体验与持续更新。这些期望给 DevOps 团队带来压力：更频繁的发布、更高的可用性，以及支持实验以驱动快速创新。
DevOps 1.0 工具链“吃不消”
自 2009 年首届 DevOpsDays 以来，我们对工具的需求已改变：交付节奏加快，同时监管负担加重。以制品仓库（artifact registries）为例：它们最初是为加速构建而引入的本地缓存，如今却成为多语言软件供应链安全的关键。为简化部署我们容器化了应用，但构建时间变长，使“持续集成”的构建不再“持续”。我们从一套配置管理工具转向更新的、云原生的声明式工具；但那些基础设施变更依然需要测试、安全与治理。与此同时，新工具层出不穷——每个都宣称能带来改进，但都需要与现有体系打通集成。对许多团队而言，现有技术栈正变得岌岌可危。
流水线会很快变得极度复杂。很多组织需要管理平均 10 个或更多不同工具来完成部署。比如，一条用于部署 Rails、Sidekiq 与 NodeJS 应用的自动化流水线，可能包含：
- GitHub Actions（运行 CI）
- 用于给 Sidekiq、Rails、Puma 打点并将应用指标推送到 Prometheus 的库
- Docker 镜像构建与 Kubernetes
- Artifactory（存储镜像与 Helm Chart）
- ArgoCD（在 Kubernetes 上进行 GitOps 部署）
- Helm（管理部署与升级）
- Terraform（管理 AWS 基础设施、角色、权限等）
- New Relic（异常捕获与监控）
- kube-state-metrics（采集容器/集群状态指标）
- Prometheus（存储指标）
- Grafana（将 Prometheus 指标可视化与可消费化）
对于资源有限的团队，这样一套工具的集成与运维是一项不小的挑战。下面看看 DIY（自建） 路径的若干痛点。
常用开源工具往往“够用但不优”
DIY 的 DevOps 常导致效率更低的流水线。一些开源工具缺少能减少开发者工作量、缩短到生产时间的功能。例如，在 Jenkins 上维持高可用与弹性扩缩需要大量资源；测试时间过长会拖慢构建；流水线复用常靠复制/粘贴，造成难以维护且成本高昂的**“流水线蔓延（pipeline sprawl）”**。第 3 章将进一步展开这些问题。
DIY 流水线导致重复与浪费
团队往往需要自行开发“管道”来把各工具与系统串起来，造成大量重复造轮子。例如，Jenkins 与 ArgoCD 是常见的 CI/CD 组合，它们功能强大，但很多基础能力（如 RBAC（基于角色的访问控制） 、审计日志、通知）需要团队从零实现与维护——这些精力本可用于为客户交付价值。
自动化常不完整，仍需手工步骤
如果大多数部署用脚本自动化，但仍需手工配置环境变量，就可能因团队成员操作不一致而导致部署差异。不完整的自动化还会在监控与反馈环上留下空白：手工步骤可能无法触发自动告警或指标采集。手工操作也引入人为失误风险，可能导致停机或安全事故。总之，不完整的自动化会带来低效、易错与难以扩展的问题。
治理常被“事后补救”
缺乏前置治理，团队可能忽视合规要求（如 GDPR），待问题暴露时不得不付出昂贵返工或罚款。一旦安全措施以“临时补丁”方式零散应用，应用就更易暴露在攻击面前。没有清晰的治理策略，云服务或基础设施资源可能被过度配置或利用不足（第 9 章将详述成本话题）。缺少统一治理的环境里，团队可能各用各的工具、流程与标准，导致集成困难与效率低下。
DevOps 2.0
DevOps 1.0 让许多公司的软件交付显著加速。但其复杂度、留存的空白以及所需投入都为改进留出了空间。于是有了我们称之为 DevOps 2.0 的愿景——以更简单的开发者体验、端到端自动化与可视化管理所有“动件”，以及贯穿全链路的 AI 能力为特征。这一演进把关注点从工具与流程，转向人及其要达成的业务结果。
DevOps 2.0 的流程与工具通过强大的新特性提升开发者体验。通过自动化搭建开发与交付工具链，开发者可在几分钟内启动新项目与新服务。开箱即用的集成让团队可以轻松创建并连接代码仓库、敏捷项目与流水线。为进一步简化流程，模板封装了组织的最佳实践，确保一致性，并在创建新服务时消除工作管理开销。团队把精力放在构建应用本身，而非繁琐的基础设施搭建。AI 智能体承担愈发复杂的 DevOps 任务，如自动诊断与修复基础设施与流水线问题、优化资源分配，并基于观测到的性能模式提出架构改进建议。
DevOps 2.0 的工具以更紧密的集成来化解 DevOps 1.0 解法的复杂度。RBAC、审计日志等关键构件被原生集成。对多种部署策略与试验方法提供内建支持，从而支撑团队所需的高频发布与快速迭代。新一代工具可在多环境大规模扩展——涵盖本地、云与混合场景。DevOps 2.0 工具将提供安全的流水线与策略强制，以尽量降低开源采纳与 AI 生成代码所固有的风险。
最后，AI 正被深度融入 DevOps 2.0 的工具与流程，贯穿整个软件交付流水线。新兴协议如 Agent Control Protocol（ACP） 、Model Context Protocol（MCP） 与 Agent-to-Agent Protocol，正帮助 AI 模型与更广泛的工具、系统、数据生态无缝交互。这些协议定义了 AI 智能体在安全护栏内与工具交互、访问数据、执行任务的标准化方式——从而实现更动态、更自治的工作流。
在现代 DevOps 环境中，这些协议充当 AI 能力与运行基础设施之间的桥梁，使 AI 不再只是“观察与建议”，而是能够采取有意义且可审计、合规的行动。随着 DevOps 2.0 拥抱愈发智能的自动化，这些协议为安全、可扩展、有效的 AI 驱动运维奠定基础，大幅加速开发者工作流。想象一下：工具可以生成代码、注释、测试与基础设施脚本，或通过自然语言搜索提取相关代码片段；同时，机器学习仅执行相关测试以加速测试周期。
借助 AI，这些工具在入职期间提供个性化指引，检测漏洞并给出修复建议或触发修复，甚至帮助编写与理解策略。通过分析可观测性遥测数据来判断何时需要回滚，提升部署可靠性。AI 还会分析功能实验以理解变更影响。这场贯穿软件开发生命周期（SDLC）的 AI 驱动变革，在提升生产力、改进质量、降低风险、优化开发者体验方面成效显著。
随着开发者在 AI 编码助手的帮助下编码速度越来越快，企业快速且安全地将变更交付到生产，并判断这些变更是否带来正向价值的能力，将成为创新的瓶颈。要做好这点，既要把 DevOps 的基本功做扎实，也要在交付的每个阶段注入前沿 AI。
总结
现代软件交付强调快速发布、无缝体验与持续创新，这推动着传统 DevOps 实践的转型。DevOps 1.0 以 CI/CD 与跨团队协作为基础，但其对分散工具链的依赖带来了阻碍。这些挑战源于应用架构复杂性的增长（微服务、容器）、开源组件的激增，以及对日益多样化工具集的管理需求。DevOps 2.0 旨在通过简化开发者体验、提供更一体化与智能的工具集，并在流水线中原生融入 AI 来解决这些问题。这一演进承诺带来更高效率、更佳质量，并把重心从“管理工具”转向“创造价值”。
此外，AI 原生软件交付用自治智能体（如代码、DevOps、安全）替代静态自动化，实现自我优化的系统与前瞻性、统一的生态。它通过自治代码生成、上下文化流水线创建、预测性故障处置与实时决策来加速开发、增强可靠性、确保合规、降低成本，并以可扩展的协作能力赋能团队。尽管这具有变革性，组织仍需正视 AI 治理、数据隐私与技能缺口，以充分释放其价值。
在第 2、3、4 章中，我们将覆盖 DevOps 自动化的“骨干”：用于高效版本管理的源码控制，支撑高效开发的持续集成构建与测试，以及用于在内部环境无缝发布的持续交付系统。我们将同时审视 DevOps 1.0 的做法 与 DevOps 2.0 带来的新机遇。
参考文献
1 Kent Beck 等，《敏捷软件开发宣言》，2001，Agile Alliance（2010 年 6 月 14 日检索）。
