使用DevOps强化敏捷（上）

作者 | Christopher Lee & Sean D. Mack

译者 | 温馨

如果您曾经对敏捷或DevOps的历史、结构、原则或好处有过疑问，那么您将在这篇文里找到答案，本文被拆分两篇，上篇主要介绍敏捷和DevOps的历史、差异和好处。

敏捷和DevOps从表面上看可能是不同的，但如果关注他们的目标，会发现它们其实非常相似。两者的目标都是更快地为客户创造价值并更快地改变市场需求。DevOps采用敏捷中介绍的原则，并将其扩展使用到代码以外的部署和运维操作中。

敏捷和DevOps的目标是一致的，因此在实践过程中会发现它们有所重叠。在许多方面，DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。连续测试和小批量生产等过程中更容易看到了这一点，在使工作尽量可见化的过程中，公开工作流和系统遥测，有助于确保向客户快速交付工作产品，能加速向客户传递价值。

敏捷和DevOps专注于提供客户价值，这不是为了提供更多功能，而是为了尽可能快速有效地向最终客户提供正确的增值功能。DevOps使用敏捷的概念并对其进行了扩展延伸，因此您可以通过实现DevOps实践来增强敏捷性。

什么是DevOps？什么是敏捷？

在开始研究DevOps和敏捷之间的关系之前，首先要对这些术语的含义有一个共同的理解。虽然有许多定义，但它们可以从根本上理解为一套原则，从中可以衍生出工程师文化和实践。

敏捷的存在时间比DevOps长，定义也更为成熟。首次定义于2001年2月的《敏捷宣言》，该宣言包含了以下几条定义：

• 个人和交互重于流程和工具
• 工作软件重于公共文档
• 与客户协作重于合同谈判
• 响应变化胜过遵循计划

尽管已经有了对DevOps宣言的尝试，但还没有哪一个宣言能够获得敏捷宣言所具有的那种广泛接受度。作为一个一般概念，DevOps重视协作，特别关注开发和运营团队之间的交叉功能以及这两个方面的责任。敏捷教练Anthony Gardiner说，“我测试，我编码，我部署，我在周末起床并修复错误——我让我的代码更好，所以我不必在周末起床。”DevOps可以被认为是一种为客户提供价值的方法，专注于协作和小批量，聚焦持续集成，自动化，持续测试和持续交付。

虽然没有单一的定义，Gene Kim、Kevin Behr和George Spafford在他们的开创性书籍《凤凰计划》中介绍了DevOps的“三种方法”。这三种方法是许多DevOps实践的核心。

Kim后来在《DevOps Handbook》中对这些方法进行了扩展，他与Jez Humble和Patrick Debois合著了这本手册。

这三种方法包括：

方法一	系统思维	强调整个系统的性能，而不是特定工作或部门的性能——大到可以是一个部门，小到可以是单个贡献者。
方法二	增强反馈循环	创建从右到左的反馈循环。以缩短和增强反馈为流程改进计划的目标，以便持续进行必要的修正。
方法三	持续实践和学习的文化	创造一种能促进两件事的文化：一是持续实践、冒险和从失败中学习；二是理解重复和实践是精通某件事的先决条件。

历史

追溯到20世纪90年代，敏捷已存在的时间比DevOps长得多，后者在将近20年后才出现。然而，这两套原则都源于精益制造，其历史可以追溯到20世纪40年代。虽然DevOps的流行度持续增长，但敏捷仍然比DevOps更广为人知。谷歌趋势表示“敏捷”一词的搜索量大约是“DevOps”一词的三倍。

敏捷的根源可以追溯到20世纪40年代的精益流程，其中包括看板，一种可视化丰田生产系统一部分工作流程的方法。限制理论也是后来发展起来的。然而，敏捷的软件开发方法在20世纪90年代真正起步，当时一群软件开发人员常受到瀑布式开发方法中涉及的高度严格的流程的困扰。这些常导致软件项目花费了数月甚至数年才导致失败。在20世纪80年代和90年代，诞生了几种软件迭代开发方法作为瀑布方法的替代，包括极限编程（XP）和看板。1995年，引入了敏捷开发的Scrum实践。然后，在2001年Snowbird山度假村的著名会议上，一群思想领袖齐聚一堂，共同编写敏捷宣言。敏捷发展至今，其中许多变化和实践都是从最初的宣言演变而来的，包括现代敏捷。虽然敏捷制定了总体原则，但实践敏捷原则的方法有很多，Scrum和看板是最受欢迎的两种（关于它们的区别，可阅读《Kanban VS Scrum：哪个是最好的敏捷项目管理框架》）。

DevOps是一套更为新的原则，它源于精益制造中的一些相同概念。“DevOps”一词于2009年首次推出，当时Patrick Debois在比利时举办了“Devopsdays”活动。2013年，Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰写了他们的书《凤凰计划》，其中提出的许多内容构成了DevOps的基础概念。2014年，随着DevOps企业峰会的启动，DevOps不断扩展到企业环境中。今天，DevOps继续与敏捷一起成长和发展。

关键差异

虽然敏捷和DevOps具有很多一致性，但需要注意的是它们的侧重点不同。敏捷主要关注应用程序的构建，而DevOps则将这一重点扩展到构建和运营应用程序。DevOps采用了敏捷的许多概念，并将这些概念扩展到构建过程之外并带入生产。正是这个扩展导致了真正的差异。

如果说存在不同，那么主要在于聚焦点的不同。敏捷教练Martin Corbett表示，“敏捷专注于分解工作，以尽快为客户提供更多价值，而DevOps专注于将代码从构建扩展到部署的项目，例如持续部署。”此外，敏捷专注于构建工作软件以及开发和QA之间的协作，而DevOps则专注于开发、QA和运营之间的协作。

虽然许多人都在寻找敏捷与DevOps之间的差异，但实际情况是，这两种方法具有非常相似的目标和基础原则，并且最终具有比差异更多的相似性。

DevOps是敏捷的延伸

在许多方面，DevOps可以被视为敏捷的延伸，甚至是敏捷的自然演变。在瀑布开发流程中，有一个明确的交接（它是强制执行的过程）。敏捷作为一个持续的过程，需要一种新的方法，DevOps有助于实现这种方法。

为了实现精益和敏捷最佳实践的核心小批量发布，在DevOps中普及的全栈工程师的概念是这种需求的最佳答案。为了减少交接，工程师必须悉知系统的所有部分，以便团队中的任何成员都能理解操作要求，而无需交付给其他团队。同样，跨职能团队必须成为常态，以便小型，独立的团队可以提供功能齐全的产品，而无需向运营团队进行额外的交接。

此外，敏捷的持续流程需要一定程度的构建和部署自动化。其中大部分都是在DevOps的CI / CD实践和工具中提供的。CI / CD需要快速部署经过全面测试并且功能齐全的代码给客户。因此，很容易看出CI /CD是敏捷实践所必需的自然演化。这些做法持续发展，使发布周期时间进一步缩短，从数周到数天甚至数小时。

从另一个角度考虑，如果您有一个只有在开发完成后才能开始的为期两周的QA周期，那么在一两周内就很难将代码推出。同样，诸如变更审批、释放资源、硬件购买和安装等需要耗费时间的事情，都会影响你按时推出代码。更不用说，您可能还有很多的交接工作，或者有一个周期长又繁重的发布过程。如何进行为期两周的迭代并进行为期两个月的发布过程？对此的明显答案是DevOps。

这并不是说没有DevOps就无法实现敏捷。敏捷在DevOps之前很久就存在，并且肯定有敏捷团队不遵循许多DevOps实践。正如Noah Cantor所说，“你可以做敏捷实践和DevOps实践，但你不能采用敏捷原则或DevOps原则，因为它们太相似而不能分开。”并不是说它们不可分割，只是敏捷作为DevOps的前身，同时激发了DevOps的影响力。

好处

精益一直是DevOps的核心，就像敏捷是从精益中生长出来的一样。DevOps也是如此，所以这两者有很大的共同点并不奇怪。DevOps采用Agile中的概念，并将其扩展到代码部署之外。DevOps采用这些概念并将其应用于应用程序和服务的管理。它利用并优化了敏捷的原则，并且沿用了敏捷组织早已意识到的长处。

并不是说为DevOps而做DevOps，或者说为敏捷而做DevOps。2017年DevOps状态报告显示，高性能DevOps团队的部署速度提高了46倍，交付时间缩短了44倍，更改失败率降低了5倍，平均恢复时间缩短了96倍（MTTR）。在具有成熟DevOps实践的组织中，这些数字显然被低估了。

当我们查看敏捷和DevOps重叠的每个区域时，DevOps放大了敏捷实践，我们希望您能够采取一些具体措施来推动组织的发展。构建协作的最关键步骤之一是制定共同目标。有了共同的目标，您可以确保开发，运营，QA都一致朝着同一目标努力。

小批量交付为推动DevOps实践加速组织提供了另一个绝佳机会。在Scrum或看板等流程中，要将操作任务和操作思想集成到工作中。如果您正在使用Scrum，您也可以考虑使用看板，它更容易适应操作流程。

无论使用哪种方法进行小批量交付，您都可能希望确保使用相同的系统来跟踪整个团队的工作。通过统一跟踪系统，您可以确保不积压工作，并真实反应所有计划内和计划外工作，让您更容易地使工作可见。作为敏捷的一个关键原则，我们还可以扩展使工作可见的概念，以显示运营工作、系统操作和架构支持等工作。组织还可以通过信息辐射体（比如看板）跨团队分享这些信息。

当您着眼于构建更具协作性的文化时，要把每一次失败都当作组织学习的机会。在这个文化中建立一些仪式，比如无可指责的事后反思、黑客马拉松和失败奖励等。

对于本文中讨论的重叠，存在组织上的含义。在敏捷和DevOps中包含QA意味着我们必须开始构建跨职能团队，并培养具有广泛知识技能的人员。这种重叠是随着“全堆栈工程师”的概念而发展起来的。虽然每个人都知道一切可能不现实，但我们当然可以努力确保团队中的每个人都有共同的责任和目标，包括质量和运营，如果他们乐于负责和学习的话。

有许多方式可以采用敏捷原则并使用DevOps强化它们，但最重要的是组织文化的一致性。如果团队在目标上没有保持一致，那么敏捷中规定的团队方法将不能扩展到部署以外的操作中使用。如果所有技术交付团队都遵循相同的目标，即可立即开始打破这些组织之间的孤岛。如果我们可以通过敏捷开始打破组织孤岛并通过DevOps强化这项工作，我们将拥有真正的高性能组织。

『由于篇幅原因，本文被拆分两篇，下一篇主要将介绍DevOps和敏捷之间的几个共性，欢迎大家持续关注。』