《DevOps权威指南》电子试读版-第一章-DevOps的工具链框架

1.5.1  DevOps工具的发展特性

谈到DevOps，不得不提软件开发；谈到软件开发，不得不提工具。在DevOps实践落地的过程中，我们不难发现，方法论是一种思想，而工具是“骨架”。对于工具，其具备较为标准的使用特性和选型原则，而工具链则是通过流程规范和价值流向给予工具的赋能。

1．DevOps的发展历程

首先必须明确的是，DevOps的受欢迎程度是随着软件工具的发展而不断上升的。我们重温一下DevOps的发展历程。

2009年，DevOps被定义为一组过程、方法和系统的统称，主要以打通“部门墙”的形式来跨越研发人员和运维人员的沟通鸿沟，促进信息的传递。

2011年，DevOps增加了相应的敏捷属性，具备快速响应业务的需求的特性，通过行为科学来改善IT组织各能力子域的沟通和信息传递方式，提高IT组织的交付效率，快速交付软件产品和软件服务。

2015年，DevOps提出了沟通、协作和工具一体化的概念，这是一种突破，表明将工具正式纳入DevOps文化的范畴，帮助IT组织快速进行软件交付，并涵盖了软件质量和产品稳定性需求，重点强调了通过工具来提升软件交付和变更的效能，建立一种组织级的文化，可以更频繁和更稳定地进行软件交付。

2016年，DevOps提出了“全链路交付”概念，同时增加了“全局的流水线”概念，将流水线嵌入业务交付的流程，具备稳定支撑业务发展的能力。在局部领域，通过业务属性的耦合帮助企业降本增效。

2018年，技术运营横空出世，IT组织不再是价值的贡献者，而逐步上升到价值的生产者。更多的理念被管理者接受。业务的高耦合使得业务目标更容易被实现。在IT组织内部，软件构建、软件集成、软件测试和软件部署正式成为标准的最小单元。

我们用一张图描述DevOps的发展历程，如图1-10所示。

2．软件开发的发展路径

软件开发作为DevOps的能力输出载体，也有相应的发展路径，我们简单描述一下。

瀑布开发是发展最为温和的一种软件开发模型，不仅为软件开发人员带来了众多好处，还有利于大型软件开发过程中软件团队的管理，有利于软件开发方法和工具的研究，从而提高大型软件项目开发的质量和效率。在软件开发领域，软件开发具备完整的生命周期，具有起点和终点。在瀑布开发模型中，必须完整和谨慎地经历这个周期中的每一个关键节点阶段，通过对里程碑的应用，过程管理更容易被软件开发管理者和软件开发对象所识别。在瀑布开发的整个过程中，需求和设计有严格的管控，相关的文档也被纳入管控范围，在最大范围内符合软件工程学的分层设计，有效地确保软件产品的质量。但是，瀑布开发模型也存在一些缺点，如客户需求在中途发生变化，导致软件开发过程中产生不可靠的因素，成本和时间的估算较为困难且不可靠，软件的架构设计变更会随着项目的推进变得成本很高和异常困难。

图1-10

敏捷开发是一种以人为核心，以迭代为方式，以循序渐进为理念的开发方式，也是互联网企业中常见的软件开发模型。敏捷开发最初是企业为了业务快速上线而促使软件开发团队具备快速工作和响应的能力而提出的，在互联网的开发实践中，形成了Scrum、特征驱动、动态系统开发和实用编程等不同分支和流派。与传统的瀑布开发不同的是，敏捷开发团队更扁平化且富有活力，能够适应开发过程中需求和设计的变化，更能输出高质量软件。在此期间，强调面对面的沟通，端对端的协作，因此更为注重团队成员的技术和文化。

DevOps开发是更为激进且更具备过程管理和过程优化的敏捷开发模型，在追求合作和响应变化的基础上，更加追求价值。DevOps开发将软件开发过程转变为对协作管理的挑战，追求数据反馈的快速沟通，按照价值交付流水线的方式，将团队成员的成果形成合力。与敏捷开发不同的是，DevOps开发更注重效能的度量和质量的管控，更加面向业务对象，需求的达成率和核准率的比例不再耦合，大大简化了文档的输出，采取智能式的推进手段给予管理者更大的帮助。

我们用一张图描述一下瀑布开发、敏捷开发和DevOps开发，如图1-11所示。

图1-11

3．DevOps工具的发展路径

通过上面的描述，我们可以发现，软件工具、DevOps和软件开发是以线性方式进行发展的，三者呈现耦合的发展态势。因此，随着DevOps和软件开发模型的不断发展，工具的种类和功能也趋于规模化和复杂化。DevOps工具的发展路径大致如下。

（1）商业化的技术移植阶段，处于DevOps发展初期。由于缺乏相应的开源技术支撑，软件开发和交付流程较为宽松，因此，对于DevOps的需求，更多的是处在打通研发和运维的“部门墙”阶段。这个阶段的工具的选择面较为狭窄，一般采取商业化软件来进行支撑信息的传递和资源的交付，典型的特征是采用商业软件和运维脚本组合的方式。

（2）开源软件的“野蛮生长”阶段，处于DevOps的中期“爆发”阶段。由于DevOps文化的加持，开源环境进一步得到发展，相应的DevOps工具应运而生，尤其得到云计算发展的助推，呈现“野蛮生长”的态势，集中于持续构建、持续集成、持续交付和自动化测试领域。在这个阶段，开源软件层出不穷，版本迭代不断加快，但功能却趋于雷同。随着同种类的工具越来越多，加快了企业实践的DevOps过程，同样带来了弊端，如工具的选型缺乏合理性导致整个工具链的重构。

（3）趋于聚焦的精细化分工阶段，处于DevOps的中期稳定阶段。在企业的DevOps实践过程中，随着组织架构的不断合理和对文化认知的不断加深，IT组织的价值输出呈现不一样的聚焦，主要集中在业务聚焦和科技聚焦层面。随着更多的技术革新，大数据、人工智能的技术赋能，使得企业在DevOps工具的选型上有了更深层次和更为持续性的考虑，因此DevOps工具也趋于聚焦的精细化分工，基于企业更聚焦的选择。

（4）继续“生长”和完善阶段，处于DevOps的后期稳定阶段。随着DevOps的转型和Aiops的逐步推进，精细化分工的工具聚焦点亟需技术的重新赋能。与“野蛮生长”阶段不同的是，该阶段的目标更为明显，工具的继续“生长”和完善更多遵循工具自身的发展趋势和价值输出范围。

1.5.2  DevOps工具的选择

1．工具的驾驭

从本质上来说，工具的驾驭是工具的文化。在DevOps工具选型过程中，有些人存在一个误区，认为工具的选择和DevOps的实践是两回事，因此导致一种严重后果，那就是工具文化和DevOps实践脱节。在DevOps文化中，鼓励沟通和交流，这便于锚定价值输出，同时可以更快、更好地输出优质的产品和服务。

在工具的选择过程中，工具的驾驭更多地体现在根据现有团队的规模和IT组织成员的技术能力选择对应的工具。DevOps的实践是分阶段的，在不同阶段，要选择不同的工具，同时要做好衔接。对于工具，尽量使用我们熟悉且自动化程度高的工具，这样有利于我们尽快掌握工具的使用。

2．工具的价值

工具的价值和软件开发的价值是相互促进的。如果DevOps是一种软件开发模式，或者当企业的开发模式已经通过DevOps方法进行实践时，那么DevOps工具是价值输出时一个不可或缺的载体。当交付风险管理、可视化、需求管理、成本复盘和审计控制成为价值输出链路中不可或缺的一部分的时候，就应该考虑工具的选择和工具的价值是否可以测算。

3．工具的赋能

工具的赋能是一个新的命题。IT组织的各能力子域具备相应的职能，因此工具的赋能要实现多个能力子域之间的数据交互并解决冲突问题。站在运维的角度，运维的核心职能是维护系统的稳定，在更深层次方面，就是保证产品的稳定。项目管理的核心职能是推进产品尽快上线，更深层次地捕捉产品交付过程中的风险。因此，在工具的赋能方面，需要搭建技术、文化和信息的价值输送通道，工具的赋能取决于选型的高度。

4．工具的本质

工具的本质是迭代，这一点可以通过“进化”来体现。因此，在选择工具时，不要被工具“绑架”。在企业规模和业态不断变化的今天，从一个团队负责一个产品的交付生命周期到多个团队共同负责多个产品的交付生命周期，这种突然的转变会带来新问题，高度的自动化、更快速的工具支撑和更好的无缝协作方式将会考验工具的迭代能力和解耦方式，因此，避免被工具“绑架”的快捷方式就是不断迭代工具。

1.5.3  DevOps工具的种类

我们将在第2章详细介绍DevOps工具，在此仅列出工具类型。由于每种类型的工具涉及的工具较多，因此本书仅列出较为常见的工具，见表1-1。常见的工具组链方式如图1-13所示。

表1-1

续表

图1-13

1.5.4  DevOps工具的发展现状

《中国DevOps现状调查报告（2020年）》中关于DevOps工具的描述如下。

由此可见，通过DevOps工具选型，大多数企业在DevOps的实践和落地方面已经进入中期稳定阶段。在工具的选择过程中，企业更多地关注工具的自动化程度、功能的易用性和工具自身的安全性，并会对工具进行二次开发和工具链的整合管理。

1.5.5  工具链简介

工具链是工具的有机结合，更是工具价值的有机集合。工具链框架遵循DevOps的核心价值。

在工具链框架体系中，应该以全局的链路交付为基础，从产品和需求的管理开始，逐步进入架构、资源、开发、构建、测试、部署、交付和运维环节，而项目后评价和成本复盘作为后置介入方式构成全局的闭环，同时，在安全管理方面，采取核心节点或旁挂节点作为补充，具体流程如图1-14所示。

图1-14

全局工具链以多个局部工具链为基础，以工具嵌入的方式进行局部工具链分段实施。局部工具链包含以下几种。

（1）信息流转工具链，主要实现IT组织各能力子域的沟通，以信息流转的方式促进信息的交流和传递，同时促使团队成员保持对信息的敏感和警惕，保证交付过程中的信息留痕和交付后的业务连续性。具体以对接IM（即时通信）工具实现内外部信息流转，对接监控和用户反馈工具用于问题发现。

（2）持续构建、集成和部署工具链，主要实现制品的自动化交付。这是局部工具链中比较常见的一种，在实践和落地过程中，具有代表性。

（3）自动化测试工具链，主要实现制品的自动化测试，同样是具有代表性的局部工具链。随着和其他局部工具链的整合，服务范围与输出对象涵盖运营组织和项目管理组织等能力子域，更有利于自动化识别风险区域。

（4）资源交付工具链。在传统的软件工程理念中，资源交付是一个前置阶段，随着交付能力不断提升，资源交付成为交付链路上新的制约因素。资源交付工具链通过工具的集成，实现“基础设施即能力”，将计算、网络和存储等资源交付能力不断下沉。

（5）数据流转和汇聚工具链，采取数据处理工具对各局部工具链进行数据的采集、汇聚、处理和存储，并按照数据使用场景进行相应的数据输出。

（6）云原生工具链，以Docker和Kubernetes为代表的云原生工具，采取工具集成的方式，实现快速的服务交付，具备快捷接入的能力，是一种更为全面的服务化能力。

（7）度量和反馈工具链是数据流转和汇聚工具链的下联工具链组织，包括IT组织和业务运营组织等职能部门的使用场景，能够及时地对信息进行分析，提供给管理者进行参考和判断。

（8）安全管理工具链，提供安全和审计闭环的自动化输出能力。

（9）可视化工具链，同样是数据流转和汇聚工具链的下联工具链组织，以无编码的方式进行数据的汇聚展示，所见即所得。