第 1 章：通往 AI 原生 DevOps 之路
大多数软件开发团队都能讲述部署失败的惨痛经历。正是这些故事，促使我们走上了现代化交付实践的道路。
这里有一个例子：经过数周或数月的特性开发、大量的重构以及漫长的测试和稳定阶段后，一个团队准备进行部署。开发人员、运维团队成员、一群经理，甚至可能还有一些高管，聚集在“作战室”中。在此之前，开发和运维之间的协作微乎其微。然而，现在这两个团队作为一支统一的团队协同工作。他们开始逐一核对一份冗长的手动步骤清单或操作手册。
然而，即使详尽的清单也不能保证部署万无一失。鉴于本次发布中改动的数量，部署可能复杂且风险高。正如我们将在接下来的章节中看到的，依赖管理充满挑战，“依赖地狱”可能真实存在。因此，团队可能会发现生产环境中缺少了一个关键依赖项。团队可能会发现安装了不兼容的库版本，或者某个关键设置配置错误，或者迁移步骤失败或被遗忘，或者更改导致对合作服务的请求失败。
任何数量的失误都可能使本已复杂的部署脱轨。紧张气氛会加剧，救火行动随即展开，时间一分一秒地过去。团队希望在部署窗口内完成部署和随后的手动冒烟测试。如果部署不可挽回地失败且无法挽救，团队则希望回滚到上一版本不会导致意外困难，从而延长停机时间和复杂性。当部署最终完成时，筋疲力尽的团队才得以撤离。通常，团队需要在流量恢复后的“关键护理期”内保持警惕。随后可能会有几天或几周的稳定期，在此期间，开发团队可能会暂停所有特性开发，专注于热修复或补丁。
正如这个故事所示，高强度、高风险的部署对开发和运维团队都造成了巨大的消耗。这些大型生产部署，以及随后的稳定化工作周期，使团队无法继续构建增加业务价值的功能。
相比之下，现代软件交付简化并加速了将软件从开发人员的计算机交付给最终用户的整个过程。部署频繁、低风险、低戏剧性，且高度自动化。但我们正在进入一个超越自动化的新时代。下一个前沿是 AI 原生软件交付。
AI 原生交付将 AI 融入软件交付生命周期的每一个层面，使智能代理能够做出决策、优化工作流程并实时适应。这些代理——从代码和 DevOps 到安全和测试——自主协作、强制合规、自我修复基础设施，并利用强化学习持续优化软件交付管道。这一转变标志着从被动治理到主动治理、从孤立工具到统一生态系统、从静态自动化到动态自治的转变。
随着 AI 生成代码、编排管道并减少手动繁琐工作，开发速度加快。系统变得更具弹性和安全性，AI 能先发制人地识别问题并自主解决。同时，通过智能优化，云成本得以降低，协作规模得以扩大，因为 AI 驱动的代理以机器般的速度处理跨团队协调和决策。
在本章中，我们将描述过去 25 年软件交付是如何演进的。我们将定义 DevOps 并描述 DevOps 实践如何实现现代软件交付。我们将探讨 DevOps 现状面临的诸多挑战。最后，本章将概述现代软件交付、DevOps 实践和 AI 原生方法如何演进以应对这些挑战。
开发 + 运维 = DevOps
“DevOps”这个术语通常归功于 Patrick Debois，他在 2009 年将“开发”（development）和“运维”（operations）这两个词组合起来，命名了他组织的一次会议，旨在探讨如何打破开发和运维团队之间的传统壁垒，以更快地交付软件。造成这些壁垒的两个主要因素是：
沟通和协作不畅
开发人员通常专注于编写代码和功能，然后将完成的产品基本上“扔过一道墙”给运维团队。运维团队随后承担在生产环境中部署、维护和故障排除代码的责任。
优先级冲突
开发团队优先考虑快速开发和新功能的快速发布，而运维团队则专注于系统稳定性、安全性和防止停机。尽管他们的优先级不同，但这些团队本质上是相互关联和相互依赖的。无论你的代码或基础设施多么令人印象深刻，除非它被部署并在生产中运行以服务于你的业务目标，否则它没有真正的价值。
这种目标不匹配，有时被称为“核心慢性冲突”，可能在问题出现时导致摩擦和相互指责。
作为回应，DevOps 原则鼓励在每个阶段进行沟通。它们鼓励运维在开发早期参与，并在代码部署后长期与开发人员保持持续合作。
DevOps 简史
日益复杂的软件团队、新的软件方法论和新工具为 DevOps 铺平了道路。在本节中，我们将探讨这些因素。
千禧年后的敏捷
21 世纪初，组织对如何提高软件交付效率的新思路产生了浓厚兴趣并乐于接受。基于精益制造思想的新“敏捷”方法论开始流行。这些方法论反对强调大量前期规划和严格线性独立阶段序列的“瀑布”式软件交付模式。相比之下，敏捷提倡短开发周期和频繁发布，以高度响应变化。许多并行努力将新的敏捷实践标准化。1995 年的一篇论文将 Scrum 实践形式化。Kent Beck 在他的 1999 年著作《极限编程解析》（Addison-Wesley）中描述了一套用于软件开发的敏捷实践。2001 年，Beck 和其他有影响力的敏捷流程倡导者在《敏捷宣言》中阐述了类似的主题，该宣言提倡适应性和响应性而非僵化地遵守计划。DevOps 借用了宣言第一条原则中的“持续交付”名称：“我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。”
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) 实践。
《敏捷软件开发宣言》催生了持续集成实践，它实现了敏捷的一个关键宗旨：频繁交付可工作的软件。开发人员将其代码更改合并到共享仓库中。通过持续集成，每次合并都会触发自动构建和测试过程。这个自动化系统能够迅速发现错误和冲突，让团队在开发周期的早期进行修复。持续集成鼓励更小、更频繁的更新，从而实现更快的交付、减少集成问题并拥有更健康的 codebase。
持续交付是持续集成的自然延伸。CD 自动化了将已通过集成构建和测试的代码准备好发布到生产环境的过程。这包括打包、配置和将软件部署到预发布环境等步骤。CD 使团队能够快速可靠地推送新功能、错误修复和更新，确保可部署的软件始终可用。
在每个开发周期结束时交付“潜在可发布产品”是另一个关键的敏捷实践。潜在可发布仅仅意味着可靠、经过测试、已打包且可以部署到生产环境的软件。（实际上，许多采用 CD 的组织只在内部进行交付，并继续不频繁地部署到生产环境。持续交付并不等同于持续部署。）
早期 DevOps 的里程碑
敏捷方法论倾向于关注软件交付生命周期的规划和执行部分，而早期 DevOps 则侧重于交付和运维。在 DevOps 兴起之后的几年里，这场运动获得了显著的势头。一个关键的里程碑发生在 2009 年，首届 DevOpsDays 大会举行。这次活动汇集了专业人士，分享他们在 DevOps 实践方面的经验和见解。
另一个重要的发展是 2010 年 Gene Kim、Kevin Behr 和 George Spafford 合著的《凤凰项目》（IT Revolution Press）出版。这部小说描述了一个虚构 IT 组织所面临的挑战，以及 DevOps 原则和实践的采用如何使其性能发生了戏剧性的转变。它以一种技术和非技术受众都能产生共鸣的方式阐述了 DevOps 的案例。第二年，另一部有影响力的出版物《DevOps 手册》由 Gene Kim、Jez Humble、Patrick Debois 和 John Willis 发布。这本实用指南通过提供一个实施 DevOps 的综合框架，帮助许多组织开始了他们的 DevOps 之旅。
2013 年，Kim 和 Humble 发布的初始 Puppet Labs（现为 Puppet）“DevOps 现状”报告引起了关注。该报告不仅关注技术指标；它强调了 DevOps 采用的业务效益，表明实施该方法的组织可以比同行快 30 倍地发布代码，同时失败率降低 50%。这直接将 DevOps 实践与领导者关心的业务成果联系起来。Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《加速：精益软件与 DevOps 科学》（IT Revolution）一书更详细地探讨了这一主题。
2013 年平台即服务（PaaS）和 Docker 的引入标志着另一个关键时刻，因为这些技术简化了应用程序的部署和管理，使得 DevOps 实践可以在更大规模上实现。在此之前，基础设施和应用程序管理的复杂性使得 DevOps 的广泛采用充满挑战。2014 年 AWS Lambda 的推出通过开创大规模事件驱动函数执行进一步改变了格局，允许开发人员专注于编写代码而无需担心底层基础设施。同时，同样于 2014 年引入的 Kubernetes 提供了一个强大的框架，用于大规模编排容器化应用程序，确保部署的可靠性、高效性和可扩展性。
到了本世纪后半叶，机器学习 (ML) 技术开始渗透到 DevOps 工具链中，尤其是在应用程序性能监控 (APM) 和测试领域。测试工具会利用 ML 来优化测试执行和检测用户界面的变化。同时，Datadog 和 New Relic 等 APM 工具很早就将自己品牌化为“AI Ops”，因为它们使用 ML 来识别问题信号。到 2018 年，Harness 将 ML 应用于持续交付，以检测问题信号，使系统能够识别部署何时导致问题并触发必要的回滚。这些技术共同为现代 DevOps 奠定了基础，通过提供必要的工具和框架来高效管理复杂的软件系统，为 AI 原生 DevOps 铺平了道路。
DevOps 1.0
DevOps 已从一个松散的、小众的概念发展成为一套完善的思想，我们可以称之为“DevOps 1.0”。其属性包括：
文化转型
认识到文化转变对于协调软件开发和运维团队的重要性
自动化实践
实施持续集成和持续交付等实践，以简化软件交付
自动化工具
利用特定工具自动化软件交付管道的各个阶段，包括代码提交、测试、部署、供应和生产监控
DevOps 1.0 实践的早期采用者获得了立竿见影的成功。在 2010 年代初，许多工程团队每季度发布一次软件，投入数周精力进行手动测试、协调和生产部署。这些发布流程缓慢、容易出错，并需要下班时间安排以最大限度地降低风险。随着组织开始采用早期 DevOps 原则——使开发和运维团队更紧密地协作并自动化交付管道的关键部分——他们实现了更快的发布周期、更高的可靠性和更少的手动工作。对于许多组织来说，这种转变使他们能够从季度发布转向双周甚至每周发布，为更迭代的开发和更快的价值实现奠定了基础。
DevOps 1.0 的挑战
DevOps 1.0 提供了有价值的概念、实践和工具。然而，由于以下原因，今天的公司在充分实现 DevOps 的效益方面面临新的挑战：
- 软件趋势引入了需要 DevOps 适应的复杂性
- DevOps 1.0 工具集要么功能不足，要么对于许多组织来说变得过于复杂
以下章节将详细探讨这些挑战。
云原生和微服务架构的采用。 新的架构模式涉及数十个部署到独立容器的离散微服务。DevOps 1.0 管道无法满足这些新架构的要求。
在过去的十年中，微服务和云原生架构已成为现代软件开发的实际标准，其驱动力是软件系统对更高可扩展性、灵活性和敏捷性的需求。这些架构为 DevOps 团队带来了重大的新要求。微服务的采用导致要部署的服务激增，每个服务都有自己的依赖项和配置。协调部署和在这些分布式服务中保持一致性变得越来越具有挑战性。
容器（云原生系统的一个关键特性）和无服务器架构的使用需要新的部署和管理策略，并增加了另一层复杂性。DevOps 团队现在必须处理跨数十甚至数百个瞬时容器或无服务器函数的部署，这需要强大的编排工具、用于构建和管理容器生命周期的自动化流程，以及对这些新兴技术的深入理解。自动化容器的整个生命周期——从构建镜像、推送到仓库，到以最小停机时间推出更新——对于高效的容器管理至关重要。
开源软件的兴起。 开源软件（OSS）已成为现代软件开发中无处不在的一部分。虽然 OSS 提供了许多好处，但它为 DevOps 团队带来了新的挑战。管理依赖项、确保与不同版本的兼容性以及维护跨多个 OSS 组件的安全补丁可能是一项艰巨的任务。此外，团队必须仔细审查代码，并确保其符合组织的安全性合规标准。
数字化体验和企业消费化的重要性。 在这个数字化颠覆的时代，Marc Andreessen 关于软件正在吞噬世界的预言被证明越来越准确。公司提供的数字化体验正成为客户的主要接触点，塑造着他们体验品牌的方式。此外，企业技术的消费化意味着员工期望获得与面向客户的应用程序相同的无缝体验和持续更新。这些期望给 DevOps 团队带来了压力，要求他们提供更频繁的发布、保持高可用性并支持实验以推动快速创新。
DevOps 1.0 工具集力不从心
自 2009 年首届 DevOpsDays 大会以来，我们对工具的需求已经发生了变化。交付节奏加快，而监管负担却增加了。以制品仓库为例：它们最初是作为本地缓存引入以加速构建的，现在它们对于在多种语言中保护软件供应链至关重要。为了简化部署，我们进行了容器化，而我们的构建时间变得更长，使得我们的持续集成构建不再那么“持续”。我们从一套配置管理工具转向了更新的、云原生的声明式工具。
但我们仍然需要测试、保护和管理那些基础设施的更改。与此同时，新工具层出不时——每个都承诺改进，但也需要与所有其他工具连接起来。对于许多团队来说，当前的堆栈正在崩溃。
管道很快变得非常复杂。组织平均管理着 10 种或更多不同的工具来部署软件。例如，一个部署 Rails、Sidekiq 和 NodeJS 应用的自动化管道可能包含以下工具：
- GitHub actions 用于运行 CI
- 用于检测 Sidekiq、Rails 和 Puma 并将应用程序指标推送到 Prometheus 的库
- Docker 镜像构建和 Kubernetes
- Artifactory 用于存储镜像和 Helm chart
- ArgoCD 用于 Kubernetes 上的 GitOps 部署
- Helm 用于管理部署和升级
- Terraform 用于管理 Amazon Web Services (AWS) 基础设施、角色、权限等
- New Relic 用于异常捕获和监控
- Kube-state-metrics 用于收集容器指标
- Prometheus 用于存储指标
- Grafana 用于使 Prometheus 指标易于消费
这个工具集的集成和管理对于资源有限的团队来说可能构成相当大的挑战。让我们来看看 DIY 方法的一些挑战。
广泛使用的开源工具通常不是最优的。 DevOps 的 DIY 方法通常会导致效率较低的管道。一些开源工具缺乏能够减少开发人员工作量并缩短生产时间的特性。例如，维护 Jenkins 的正常运行时间和扩展性需要大量资源。漫长的测试时间可能导致构建缓慢。最后，重用管道的模式是复制/粘贴，导致“管道蔓延”，这可能难以维护且成本高昂。第三章将更详细地讨论这些问题。
DIY 管道导致重复和浪费的工作。 团队通常必须实现“管道”来将工具和系统连接起来。这导致大量的重复造轮子。例如，Jenkins 和 ArgoCD 是常用的 CI/CD 工具。这些工具为自动化软件开发和部署过程提供了强大的功能，但它们需要团队从头开始构建基本结构，如基于角色的访问控制（RBAC）、审计日志和通知。
实施和维护这是一项本可以用于为客户创造价值的工作。
自动化通常不完整，需要手动步骤。 一个团队在大部分部署过程中使用自动化脚本，但需要手动干预来配置环境变量，这可能导致部署不一致，如果不是所有团队成员都遵循相同的程序的话。不完整的自动化可能导致监控和反馈回路的空白，因为手动步骤可能不会触发自动化警报或指标收集。手动步骤引入了人为错误的风险，这可能导致停机或安全漏洞。因此，DevOps 中不完整的自动化可能导致效率低下、错误和可伸缩性问题。
治理是事后才考虑的。 如果没有前期治理，团队可能会忽视合规要求（例如符合通用数据保护条例[GDPR]标准），导致问题后期被发现时，需要昂贵的返工或面临罚款。如果安全措施不一致或作为事后诸葛来应用，应用程序将容易受到攻击。如果没有明确的治理政策，云服务或基础设施等资源可能会被过度配置或未充分利用，导致成本浪费（我们将在第九章中讨论此话题）。如果缺乏监督，团队可能会使用不同的工具、流程和标准，导致集成挑战和效率低下。
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 控制协议（ACP）、模型上下文协议（MCP）和 Agent-to-Agent 协议等新兴协议正在帮助实现 AI 模型与更广泛的工具、系统和数据生态系统之间的无缝交互。这些协议定义了 AI 代理与工具交互、安全访问数据并在护栏内执行任务的标准化方式——从而实现更动态和自主的工作流程。
在现代 DevOps 环境中，这些协议充当了 AI 能力与操作基础设施之间的桥梁，使 AI 不仅仅是观察和建议；它们赋予 AI 采取有意义行动的能力，同时保持可审计性和合规性。随着 DevOps 2.0 拥抱日益智能的自动化，这些协议为安全、可扩展、高效的 AI 驱动操作提供了基础，从而极大地提升了开发人员的工作流程。想象一下，工具可以生成代码、注释、测试和基础设施脚本，或者使用自然语言搜索提取相关代码片段。此外，ML 通过仅执行相关测试来加速测试周期。
利用 AI，这些工具提供个性化的入职指导，检测漏洞并提供修复建议或启动修复，甚至帮助编写和理解策略。通过分析可观测性遥测数据来识别何时需要回滚，从而提高了部署的可靠性。AI 分析功能实验以了解变更的影响。这种 AI 驱动的软件开发生命周期（SDLC）转型正在提高生产力、改善质量、降低风险，并增强整体开发人员体验。
随着开发人员能够借助 AI 编码助手越来越快地编写代码，企业快速安全地将更改交付到生产环境并了解这些更改是否有利的能力，将成为创新的限制因素。要做好这一点，既需要做好 DevOps 的基础工作，也需要在交付的每个阶段融入前沿 AI。
总结
现代软件交付强调快速发布、无缝体验和持续创新，这推动了传统 DevOps 实践的变革需求。尽管 DevOps 1.0 通过 CI/CD 和初步的跨团队协作奠定了基础，但其对由不同解决方案构建的复杂工具链的依赖造成了障碍。这些挑战源于应用程序（微服务、容器）日益增长的架构复杂性、开源组件的激增以及管理日益多样化工具集的需求。DevOps 2.0 旨在通过简化开发人员体验、提供更集成和智能的工具集，并将 AI 原生融入到管道中来解决这些问题。这种演进有望带来更高的效率、增强的质量，并将重点放在交付价值而非仅仅管理工具上。
此外，AI 原生软件交付用自主代理（例如代码、DevOps、安全）取代静态自动化，以实现自我优化系统和主动统一的生态系统。它通过自主代码生成、上下文管道创建、预测性故障解决和实时决策，加速开发速度、增强可靠性、确保合规性、降低成本并促进可伸缩的协作。尽管这具有变革性，但组织必须解决 AI 治理、数据隐私和技能差距，才能充分利用其优势。
在第二章、第三章和第四章中，我们将涵盖 DevOps 自动化的骨干。这包括用于有效版本控制的源代码管理、使用持续集成进行高效开发的构建和测试，以及使用持续交付系统在内部进行部署以实现无缝软件发布。我们将探讨 DevOps 1.0 的方法以及 DevOps 2.0 带来的机遇。