公众号回复：干货，领取价值58元/套IT管理体系文档

公众号回复：ITIL教材，领取最新ITIL4中文教材

更多专业文档请访问 www.itilzj.com

第 1 章认识 DevOps

1.1 DevOps 基础

1.1.1 DevOps 的概念

DevOps （ development 和 operations 的组合词）是一组过程、方法与系统的统称，用于促进软件开发（应用程序或软件工程）部门、技术运营部门和质量保障（ Quality Assurance ， QA ）部门的相互沟通、协作与整合，如图 1-1 所示。软件行业从业人员日 渐认识到：为了按时交付软件产品或服务，软件开发人员和运营人员必须紧密合作。企业 必须 重视软件开发人员和运维人员的沟通，并通过自动化流程使得软件的构建、测试和发布更加快捷、可靠。

图 1-1

近年来， DevOps 在不同业态、不同领域和不同规模的企业落地，取得了较好的实践效果。对于企业的精益运营和 IT 精益运行， DevOps 的原生理念已经不能满足需求，颠覆式的发展和变革应运而生。提升组织级的效能和质量成为 DevOps 发展阶段中能力输出的新方向。因此， DevOps 的发展除原生地促进部门沟通以外，还将应用的全生命周期管理提升到一个新的高度。同时，相对应的文化协同和流程驱动也随着数据的衍生能力向前推进，实现了技术运营和价值交付的高度协同目标。

对于企业级用户，什么是 DevOps 、 DevOps 的核心目标是什么、应该具备什么能力这 3 个问题必须解释清楚，因为这关系着企业级实践和落地。作者曾与业内多个相关组织的成 员和个人进行过讨论，尽管得到的反馈不同，但核心价值是确定的，就是如何通过 DevOps 实现最终的价值交付和输出。

1.1.2 DevOps 与企业和 IT 组织的关系

1 ． DevOps 和企业的关系

企业的发展需要具备相应的目标，而企业的发展目标一般通过经济效益来评价。经济效益包括产能、营业额、利润率和投资回报率。企业的发展目标可以分解为以下 4 个方面进行讲解。

（ 1 ）企业对社会的贡献目标。对于不同类型和业态的企业，企业对社会的贡献目标体现在企业的产品效应和产品效益上。

（ 2 ）企业的市场目标。它决定了企业能否生存。提高企业产品的创新水平和企业产品的快速上线能力，以及产品的市场占有率是达成企业的市场目标的重要手段。

（ 3 ）企业的开发目标。这是企业提高生产力水平的重要目标。它通过扩大企业规模，增加固定资产、流动资金，提高生产能力，增加品种、产量和销售量，提高企业人均生产力，以及提高自动化程度来实现。

（ 4 ） 企业的利益目标。在经营过程中，企业通过“降本增效”实现企业的利益目标的最大化。“降本增效”可以通过企业自身的产品调整和内部管理调整来实现，调整的依据是内外部的数据分析和支撑。

DevOps 在企业发展过程中的定位更偏向于为企业“锦上添花”，而不是让企业“绝处逢生”。在进行企业级 DevOps 落地的过程中，管理者要注意，无论企业是在经历业态转型、数字化转型，还是品牌经营转型，均需要利用先进的信息技术来提升自身的管理水平，增加企业的竞争力，这是 DevOps 提供的价值和能力。

对于企业的核心价值输出， DevOps 的作用是“催化剂”，这一点和企业的发展目标是不相悖的。因此，无论 DevOps 的落地成功与否，都不能让企业发生“质”的变化，但可以给企业带来商业上的成功。

2 ． DevOps 和 IT 组织的关系

IT 组织是 DevOps 企业级实践的载体。对于企业，其日常经营离不开 IT 组织的配合和支撑。一般来说， IT 组织是企业实现可持续经营不可或缺的一部分，它拥有的属性包括信息化和数字化。在企业的日常经营活动中， IT 组织需要具备以下两种核心能力。

（ 1 ）以企业的战略目标为导向，通过信息化和数字化的手段对企业战略进行支撑。

（ 2 ）在信息化总体规划的指导下，建设信息化和数字化的基础设施、应用系统，为企业经营提供技术保障。

IT 组织和 DevOps 的“纠葛”来源于 IT 组织的自我革新。在大多数企业中， IT 组织的压力分为内部压力和外部压力。内部压力主要来自内部管理和协调，外部压力主要来自业务部门的服务需求。当外部压力需要通过内部管理来释放时， DevOps 的原生能力并不能覆盖所有。现今，越来越多的企业将目光投向 DevOps ，除利用 DevOps 提升效能，维持高标准和高效率的能力输出以外，还要保证外部压力释放的合理性。国内一些大型互联网企业在这方面的实践中取得了较好的效果。

随着规模和能力的变化， IT 组织从“单兵模式”发展到“集团军模式”，于是出现了职责的分工和工作流的衔接，这就是我们通常所说的 IT 组织的能力子域，如交付链路的项目管理、需求管理、产品管理、架构管理、开发管理、测试管理、运维管理和安全管理等。在交付链路上，能力子域是以单个节点的形式存在的，在衔接配合的同时也存在职责以外的目标矛盾。

因此，在 IT 组织的内部， DevOps 要实现 IT 服务流程的贯通，解决各能力子域的矛盾。这是对 DevOps 原生能力的一种拓展。这里的重点在于跨部门和跨团队的线上协作，通过 DevOps 理念，实现交付流水线的信息传递。举个例子，在用传统的方法进行系统上线部署时，可能需要一个冗长的说明文档，而在用 DevOps 的方法进行系统上线部署时，通过标准运行环境的选择、环境的设置、部署流程的编排，实现自动化部署。另外，对于这样的部署方法，操作人员可以理解，机器能够执行，部署的过程也可以被追踪和审计。

化解能力子域的矛盾是基础，连通应用全生命周期管理和价值交付是进阶。举个例子，从项目立项、需求整理、架构设计、代码开发、集成构建、代码测试、持续部署、代码配置和上线监控的工具集成，到形成工具链的一体化连通和输出方式，最终实现 IT 组织能力的变现。

IT 组织需要通过 DevOps 的能力实现“科技输出”和“技术运营”，这有两个特点，一是 IT 组织具备业务属性， DevOps 能够生产价值；二是 IT 组织不具备业务属性， DevOps 能够贡献价值。

1.1.3 DevOps 究竟是什么

DevOps 究竟是什么？从表面上来看， DevOps 是指“开发和运维一体化”，这也是 DevOps 的原生能力，即通过工具辅助开发人员完成运维人员的部分工作，减少成本。但在我们深入理解了 DevOps 与企业和 IT 组织的关系后，就会发现， DevOps 其实是一种方法，即面向组织的效能和质量管理方法论。在交付链路能力子域， DevOps 消除了隔阂；在项目和需求子域， DevOps 实现了精准的过程控制和风险管理；在软件研发和测试子域， DevOps 帮助研发和测试团队在保证质量的前提下提高交付效率；在运维子域， DevOps 提高了产品发布的效率和线上质量反馈的速度。

同时，利用交付链路的工具让数据落地，通过度量来管理过程，通过反馈来回检优化，最终实现组织级的效能和质量的提升。

1.2 DevOps 的发展轨迹和特点

1.2.1 DevOps 的起源

1 ．原始的 DevOps

提起 DevOps ，不得不说 DevOps 的载体——程序。

在计算机刚出现的时候，软件开发只是少数人的“特权”，在此期间，从业者具备高学历的特征。在那个时期，只有 “程序”（ program ），没有“软件”（ software ），因此，当时编写程序的人员被称为“程序员”（ programmer ）。学习编程的基本材料只是计算机设备厂商附送的产品使用手册。因此，一些企业只能先购买设备，再自己培养编程人才。图 1-2 中的女人是格蕾丝·霍珀（ Grace Hopper ），她是编程界的传奇人物。（图 1-2 引自《宽带：创造互联网的女性的不朽故事》。）

图 1-2

在计算机发展的早期，最先购买计算机的是科研单位、军队、政府，以及少数大型企业。它们组建了新的部门，如信息技术部（ IT department ），或者称为信息化办公室（ IT office ）。在中国，有些单位直接将这类部门称为“电脑部”。这类部门专门管理计算机，并且组织成员学习软件编程技术，利用程序帮助其他部门解决相关问题。这是 IT 运维的雏形。在这个时期，没有 Dev 和 Ops 之分，它们统称为 programmer 。由于这个时期的开发工作和运维工作由同一批人来做，即自己维护自己开发的程序，因此我们可以将这种形式看作原始的 DevOps 。在这个时期，计算机系统和出现的问题较简单，开发和维护并不复杂，无须进行专业分工。

2 ． Dev 的出现

随着计算机的成本不断下降，尤其是以 IBM PC 为代表的微型计算机（ micro computer ）的普及，企业开始大规模使用计算机进行办公。由于软件开发人员的数量仍然很少，加之需求旺盛，因此专业软件开发人员的人工成本依然高昂。随着软件的扩展，当初为个人目的（ personal purpose ）而开发的软件渐渐开始走通用化的路线，慢慢形成了软件产品。接着，专门从事软件开发的公司出现，并逐渐形成了一个产业。与此同时，软件开发工程师（ Developer ，简称 Dev ）出现。

在这个时期，软件开发仍然是专业人员从事的一种工作，企业的 IT 部门开发软件的成本依然很高。于是，大部分单位、组织和企业通过购买的形式获得软件。IT 部门逐渐成为负责信息化采购和软硬件基本操作培训的部门。此外，由于信息化加速，针对各个行业的软件层出不穷，加之从事软件开发的企业越来越多，因此 IT 部门不得不通过更广泛的学习来了解技术的变化。

3 ． Ops 的出现

随之而来的问题是，无论企业购买多少软件，仍然无法完全满足企业的信息化需求。计算机中的数据成为企业的信息“孤岛”。虽然软件解决了信息的分析和存储问题，但只是实现了无纸化办公，没有让部门间的信息有效流动起来。一些大型企业最先发现这些问题并且给出了最初的解决方案，这使得企业级软件开发和系统集成（ system integration ）逐渐成为一个热门领域。企业级软件系统的显著特点是通过计算机网络解决了企业内部的信息“孤岛”问题，但这样的系统无法在 PC 上运行，因为需要专业的工作站、服务器和网络设备。企业的 IT 部门理所当然地承担了对这些设备的管理职责。

随着软硬件技术的发展，特别是针对企业级应用开发的经验不断积累，设备的采购成本和软件的开发成本进一步降低。一些大型 IT 厂商开始瞄准企业级应用市场，如 IBM 、 Oracle 和 EMC 相继推出了相应的产品。这使得定制化软件开发的成本不断下降。随着软件开发人员越来越多，开发成本逐渐降低，企业定制化软件开发出现了，同时还出现了 MIS 和 ERP 这样的应用，以及 J2EE 这样的企业级软件开发框架。

在这个过程中， IT 运维的概念逐渐产生。IT 运维（ IT operation ）的职能是为内部和外部客户的应用部署提供平滑的基础设施和操作环境，包括网络基础设施、服务器和设备管理，计算机操作， ITIL 管理，以及作为组织的 IT 帮助中心。对于企业的 IT 部门，其职能不仅是维护计算机和网络设备，还要维护运行在这些设备上的软件系统，尤其是定制化的企业级软件产品。因此，在企业定制化软件从乙方交付甲方时，就需要一系列的技术审查以确保质量，这就对原本不需要关心软件是如何开发的企业的 IT 部门提出了更高的要求。企业的 IT 部门必须提高专业技能水平以应对这样的变化。同时，企业的 IT 部门需要重新思考整个 IT 部门的服务的管理和设计。随着 IT 部门在知识和服务专业度方面的提升，催生出了 ITIL （ Information Technology Infrastructure Library ，信息技术基础设施库）这样的最佳实践库，使得“系统维护工程师”（ Ops ）更加专业。在这个时期， Dev 和 Ops 的矛盾主要体现在由 Dev 所代表的乙方和由 Ops 所代表的甲方在定制化软件产品交付质量上的要求不一致。

4 ． DevOps 被正式推出

随着企业级软件开发日趋完善和成熟，形成了以 RUP （ Rational Unified Process ， Rational 统一软件开发过程）为代表的方法。RUP 描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级方法（也称为厚方法学），因此，特别适合大型软件团队开发大型项目。后来，随着互联网企业的成功，不断颠覆很多人过往的认知，对 IT 产业影响很大。

首先，相较于最多万人的用户访问规模，来自互联网的千万级甚至亿级的访问规模是以前企业级应用不曾面临的。这给软件开发、主机管理和网络架构带来了很大挑战。

其次，企业级应用和互联网应用面对的问题是不一样的。“康威定理”中提到：设计系统的组织产生的设计和架构等价于组织间的沟通结构。相较于有清晰等级和部门分工的组织，互联网产品的沟通结构更加复杂。

此外，互联网应用由互联网企业自开发、自维护。从表面上来看，虽然没有了甲方和乙方之分，但开发和运维相互分离的工作流程和考核方式在沿用，职能上的对立依然存在。Dev 的职能是给应用系统增加新的功能和修复软件的 bug ，这一系列价值的产生是通过应用系统变更实现的。一般的组织会用代码 / 功能的贡献数量作为业绩考核的依据，以激励 Dev 的工作产出。Ops 的职能则是让应用系统保持稳定和高性能，即在最大程度上缩短“死”机时间并能够提升应用系统的性能，同时，将这两点作为 Ops 的考核指标（ KPI ），以激励 Ops 通过维护工作使应用系统能够按照预期稳定地产出价值。

而市场环境的瞬息万变和资本的集中化使得互联网软件产品的生存状态非常脆弱。一方面，快速变化的市场难以预测。因此，基于经验的重量级软件开发方法不再适用，取而代之的是强调适应性、拥抱变化的敏捷方法。互联网软件必须通过频繁增加 / 修改功能来提升自身对市场的适应程度。另一方面，互联网软件的变更给企业带来的风险和损失是难以度量的。因此，互联网软件有更加严格的交付标准，需要做更多的质量保证。而基于经验的系统运维实践并没有找到合适的方法来应对这种挑战。因此，在这个时期， Dev 和 Ops 的主要矛盾是面向适应的敏捷软件交付和面向经验的传统运维之间的矛盾。

1.2.2 DevOps 的发展路径

DevOps 的发展路径如图 1-3 所示。

图 1-3

对于 DevOps 的历史，我们要从比利时的一个 IT 咨询师说起。这位名为 Patrick Debois 的 IT 咨询师喜欢从多种角度研究 IT 组织。2007 年， Patrick Debois 参与了比利时政府的一个下属部门的大型数据中心迁移项目。在这个项目中，他负责测试和验证工作。因此，他不但需要和开发团队（ Dev ）一起工作，而且需要和运维团队（ Ops ）一起工作。于是，他第一天在开发团队以敏捷的节奏工作，第二天在运维团队以传统的方式维护这些系统。这种在两种工作氛围来回切换的方式令他非常沮丧。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异。开发团队和运维团队“生活”在两个不同的“世界”，而彼此又坚守着各自的利益，因此，这两者在工作上经常发生冲突。作为一个敏捷的拥护者，他渐渐明白了如何在这种状况下改进自己的工作方式。

2008 年 6 月，在美国加利福尼亚州的旧金山市， O’Reilly 公司举办了一场名为 Velocity 的技术会议。这场会议主要围绕 Web 应用程序的性能和运维话题展开。这场会议被设计用来分享构建和运维 Web 应用时性能、稳定性和可用性方面的最佳实践。这场会议吸引了来自奥斯汀（ Austin ）的几个系统管理员和开发人员。他们对会议中分享的内容感到非常激动，于是记录了所有的演讲内容，并决定新开一个博客以分享这些内容和自己的经验。他们同样意识到敏捷在系统管理工作中的重要性。于是，一个名为 The Agile Admin 的博客诞生了。

2008 年 8 月，在加拿大多伦多市召开的 Agile Conference 2008 （敏捷会议 2008 ）上， Andrew Shafer 提交了一个名为“ Agile Infrastructure ”的临时话题。由于对这个临时话题感兴趣的人不多， Andrew Shafer 认为没人会对如何跨越 Dev 和 Ops 之间的鸿沟这个话题感兴趣。于是，当开始讨论这个话题的时候，作为话题提交人的 Andrew Shafer 并没有出现，仅有一个人出席，这个人就是上文提到的 IT 咨询师 Patrick Debois 。Partrik Debois 在这次会议上分享了自己的话题：如何在运维工作中应用 Scrum 和其他敏捷实践。他特别想把这些经历和别人分享。后来， Patrick Debois 在会议厅的走廊里找到了 Andrew Shafer ，并与他进行了一场漫长的讨论。他们意识到，在这次会议之后，会有很多人想要继续探讨这个广泛而又系统化的话题。在召开这次会议时，尽管持续集成的流行已使敏捷实践慢慢走向落地，但是这仍然把运维工作和开发工作完全割裂。于是，他们决定在 Google Group 上建立一个名为 Agile System Adminstration 的讨论组并继续讨论这个话题。虽然在这个讨论组中有一些话题和参与者，但是访问者寥寥。

在 2009 年 6 月召开的第二届 Velocity 会议上，最大的亮点是一个题为 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr 的演讲。后来，几乎所有与 DevOps 相关的资料都会引用这个演讲的内容。这个演讲的内容可以被视为 DevOps 萌发的标志。在这个演讲中，提出了关于 DevOps 的“一个中心，两个基本点”，即以业务敏捷为中心，构造适应快速发布软件的工具（ tool ）和文化（ culture ）。Patrick Debois 在网络上看到了这个演讲的视频，感到很兴奋，因为这就是他一直致力于研究的领域。于是，他在 Twitter 上询问如何才能参加 Velocity 会议。其中有个人回复：嗨， Patrick ，你想在比利时召开自己的 Velocity 吗？我们都会去参加，这一定会很棒。

于是， Patrick Debois 就想通过 Twitter 召集开发工程师和运维工程师在比利时举办一个类似 Velocity 的会议。如果要召开一个会议，就得有一个会议名字， Patrick Debois 首先想到了 Dev 和 Ops ，加上这个会议持续两天，因此他加上了 Days ，于是有了 DevOpsDays 这个会议名称。由于 Twitter 对发布的内容有 140 个字符的限制，因此他想用 DOD 作为 DevOpsDays 的缩写以提醒自己“死在交付上”（ Dead On Delivery ），但不知什么原因，最后他没有这样做。虽然这是一届社区版“ Velocity 会议”，但这次会议出乎意料地获得了成功。2009 年 10 月，人们从世界各地蜂拥而至，除开发工程师和运维工程师以外，还有 IT 管理人员和工具爱好者等。两天的会议结束后，参与 DevOpsDays 的人把这次会议的内容带回到世界各个角落。虽然会议已经结束，但关于 DevOpsDays 的讨论仍在 Twitter 上继续。由于 Twitter 对发布的内容有 140 个字符的限制，因此大家在 Twitter 上讨论时去掉了 Days ，只保留了 DevOps 。于是， DevOps 这个称谓正式诞生了。

2010 年，在第二届 DevOpsDays 会议之后， DevOps 被越来越多的人熟知并迅速得到了大多数人的认可。很多人认为这正是 IT 部门的正确运作方式， DevOps 成为了一种促成开发部门和运维部门合作的运动。很多人在不同的场所和活动中分享自己的经验和见解，并催生了很多工具和实践。但是，每个人对 DevOps 的理解不同，争议在所难免。这些争议促使 DevOps 社区（如 Cloud & DevOps World 、 Continuous Lifecycle 和 DevOpsDays ）统一 DevOps 的不同见解。于是，在 The Agile Admin 上，发布了一篇名为“ What is DevOps ”的文章。该文给出了详细的 DevOps 的定义，并且依据敏捷的体系构造了 DevOps 的体系：它包括一系列价值观、原则、方法、实践，以及对应的工具。该文同时梳理了 DevOps 的历 史并对 DevOps 的一些误解进行了澄清。现在，我们通过 Google 搜索 DevOps ，会发现“ What is DevOps ”仍然排在搜索结果的第二位（第一位是维基百科对 DevOps 的解释）。

2010 年，《持续交付：发布可靠软件的系统方法》的作者 Jez Humble 参加了第二届 DevOpsDays 会议并做了关于“持续交付”的演讲。从本质上来说，《持续交付：发布可靠软件的系统方法》中提到的一些论点和实践能够解决 Patrick Debois 和 Andrew Shafer 所遇到的问题。如果《持续交付：发布可靠软件的系统方法》早两年问世，也许不会出现 DevOps 。然而，随着 DevOps 理念的传播， DevOps 的概念的外延越来越广，已经超出了《持续交付：发布可靠软件的系统方法》本身所涵盖的范畴。“持续交付”是“持续集成”的延伸，而这点恰恰和 2008 年召开的敏捷会议中提到的观点一致。但由于发生时间的先后关系，“持续交付”被视为敏捷和 DevOps 文化的产物。至今，持续交付仍然作为 DevOps 的核心实践而被广泛谈及。

2015 年是 DevOps 落地实践的转折点，也是 DevOps 的中国年。随着中国经济的腾飞，信息技术得到了蓬勃发展，因此，很多创新技术在中国企业落地和实践，取得了很好的效果并得到了权威总结。

2015 年 6 月 ，中国信通院组织国内头部互联网企业编写 DevOps 标准的雏形《互联网应用运维框架及能力模型》，并在 2016 年将 DevOps 能力上升到技术运营层面，形成了 DevOps 正式标准《研发运营一体化（ DevOps ）能力成熟度模型》。该标准明确了在 IT 软件及相关服务的研发和交付过程中，将应用的需求、开发、测试、部署和运营统一，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成，即研发运营一体化。在保证稳定的同时，帮助企业提升 IT 效能，快速交付高质量的软件和服务，灵活应对快速变化的业务需求和市场环境。

DevOps 标准的立项过程如图 1-4 所示。

图 1-4

2018 年 7 月 16 ～ 27 日，在瑞士日内瓦举办了 ITU-T （国际电信联盟电信标准化部门） Study Group13 Future networks (& cloud) 全会，来自多个国家或地区的 90 多名代表参与了此次会议。由中国信息通信研究院主导的 DevOps 国际标准项目成功立项，立项名称：“ Cloud computing-Requirements for cloud service development and operation management ”。这是由中国信息通信研究院主导立项的首个 DevOps 国际标准，是在国际标准中将云计算开发运维实践上升到国际产业和生态来共同推动 DevOps 标准全球化的重要里程碑。

1.2.3 DevOps 的发展特点

通过 DevOps 的发展趋势，我们发现其呈现 3 种鲜明的发展特点，分别是思想和文化的变革，聚焦能力的变革，以及技术传播的变革。

1 ．思想和文化的变革

在 DevOps 的发展趋势中，思想和文化有一种明显的上升态势，从技术载体文化到工程师文化，最终到组织文化。尤其是 2009 年的 Velocity 会议提出“一个中心，两个基本点”的概念，更是强调了 DevOps 发展过程中的关键要素，即思想和文化的重要性，而这种思想和文化的变革，更是体现在思想的延伸，以及价值观的支撑层面。

回顾软件发展的管理模式，在传统瀑布管理模式下，开发、测试和运维分属不同的部门，部门之间存在厚厚的部门“墙”，下一个环节的动作必须要等到上一个环节全部完成才能进行。到后来的敏捷时代，也主要是打通了开发和测试的部门“墙”，采用迭代的方式，测试驱动开发，这是技术载体文化到工程师文化的延展。

比较上述两种模式，我们会发现，传统瀑布管理模式注重在交付范围不变的情况下，通过计划驱动修改交付的时间和协调资源来完成交付。而敏捷是在资源、时间不变的情况下，通过价值驱动更改交付范围。在这个范围内，已经初步具备价值交付的相关特性。因此，工程师文化已经相对局限，更为全局的组织文化和价值观需要更为宏观的体现。

2 ．聚焦能力的变革

在能力聚焦阶段，程序由服务能力到快速交付能力，再到后续的价值交付能力，最终到价值输出能力，体现了聚焦的锚定。

在现阶段，绝大多数企业的 DevOps 实践在于软件快速交付和系统稳定运营。团队共享面向客户的价值和集成目标，同时共担质量责任。但是， DevOps 并不会取代敏捷，而是对敏捷的补充。它通过消除浪费和简化部署等思想，实现持续交付的目标。DevOps 是集大成者，它并不制造概念，而是将很多理念和实践进行整合，是真正打通端到端交付的方法体系。

在下一个阶段，快速交付需要延伸至技术运营，交付的根本体现在对企业发展的支撑能力，一切不能量化的支撑能力都不能称为价值输出。

在聚焦能力层面， DevOps 不断以端到端的传播方式来体现，在 IT 组织内部，端到端地进行资源输出，端到端地进行持续部署，端到端地进行价值输出；在 IT 组织外部，面向用户进行服务，面向客户传递价值，面向其他职能组织提供产品和运营反馈。

3 ．技术传播的变革

DevOps 的发展过程其实就是敏捷思想从软件开发端（ Dev ）到系统维护端（ Ops ）的延伸。“ Dev ”是开发人员的简称，但在真正的实践中，意味着更广泛的“参与开发产品”的所有人，包括产品人员、质量人员和其他工种人员。“ Ops ”也是一个总括术语，泛指系统工程师、系统管理员、操作人员，发布工程师、数据管理员（ DBA ）、网络工程师和安全专家等维护支撑类工种人员。职能的变化带来了技术传播的变革。

随着微服务、容器和云技术的成熟， DevOps 在技术传播中，从强调资源交付、敏捷交付到持续集成、持续部署和持续交付，再到端到端的价值交付，技术的赋能更为明显。尤其在万物互联的时代，即人与人连接，人与物连接，以及物与物连接的信息时代，需求关系的转变，让业务变得越来越复杂，系统功能越来越多。因此， DevOps 的技术传播和 IT 技术架构的革新形成良性循环，技术的赋能也不断呈现上升趋势，不同业态和规模的 DevOps 实现也变得规范化和标准化。

1.3 DevOps 的总体架构和流程

1.3.1 DevOps 的总体架构

在 DevOps 的落地过程中，因其总体架构具备全局且较为泛化的特性，因此并没有一个统一标准。在由中国信息通信研究院牵头编写的《研发运营一体化（ DevOps ）能力成熟度模型》中， DevOps 更多地以体系化的方法论、实践和标准的集合呈现，而总体架构在体系化的范畴内，更多承担的是企业级组织结构的全局设计，这种设计理念也是和企业的自身发展需求相匹配的，因此， DevOps 的总体架构在不同业态和不同规模的企业中落地，具备一部分泛化的标准特性。

1 ．康威定律在 DevOps 的总体架构中的作用

在软件工程领域，康威定律具备一定的影响力。在康威定律的描述中，系统设计受限于组织自身的沟通结构，这种组织的形态是不固定的，随着组织的规模变大，相对的灵活性变差，这种现象会越来越明显。在 DevOps 的总体架构中，康威定律定义了团队的结构和规模对 DevOps 的输出能力存在巨大影响。在 IT 组织内部，能力子域的范围和职能覆盖程度影响内部沟通和信息传递。越小的范围对沟通和传递的影响越小，越大的范围对沟通和传递的影响越大。

同理， DevOps 的锚定价值提升组织级的效能和质量，因此，管理价值通过管理组织实现。DevOps 的目标必须和组织成员的目标对齐，这就表明在 DevOps 的总体架构中，协作是基本的构成元素，而协作的过程也是组织架构和团队结构配合的过程。

通过康威定律在 DevOps 的总体架构中的应用，我们不难发现，协作的第一个障碍是共享职责，必须具备一致的目标和信息传递方式。在很多企业中，达成这个目标有多种方法，如所有能力子域都在一个层级的领导之下， DevOps 的度量和反馈方式都具备东西向传递的能力。协作的第二个障碍在于组织的边界。在很多企业中，边界是能力子域的天然特性，因此，在 DevOps 的总体架构中，需要解决组织无边界问题，或者，让组织的边界以团队自组织的方式存在，这与敏捷的特性类似。协作的第三个障碍与顶层组织能力输出有关，这也是 DevOps 的总体架构中的高阶应用。对于很多企业，缺乏产品质量反馈和客户满意度调查机制。一般来说， IT 组织作为能力输出单位，往往是以前置目标来驱动的。想要解决这个问题，需要在 DevOps 的总体架构中具备可优化和可回溯能力，最终实现组织的能力输出闭环。

2 ． DevOps 的总体架构中组织的类型

在 De vOps 的实践和落地过程中，很多企业会遇到因组织架构设置不合理而导致落地结果不尽如人意的问题，其中职能导向是一个明显的问题点。对于体系组织，有多种类型，其中有以下 3 种典型类型，分别是以后台支撑为导向的团队组织，对应的 IT 组织具备支撑属性；以产品交付为导向的团队组织，对应的 IT 组织具备业务属性；以用户响应为导向的团队组织，对应的 IT 组织具备矩阵管理属性。这 3 种团队组织分别承担的职责如图 1-5 所示。

图 1-5

（ 1 ）以后台支撑为导向的团队组织，承担创造价值的职责，一般出现在传统的制造型企业中。这种组织具备以下特征：以专业技能为基准，将组织成员划分成不同的级别和层级，并按照不同的专业领域进行分组，对领域的管理采取垂直方式。这种组织在 DevOps 推进过程中只能自下而上地进行单节点推进，同时会出现交付流水线的各能力子域因流程的不合理而产生失调的情况，并缺乏良好的沟通机制。

（ 2 ）以产品交付为导向的团队组织，承担交付价值的职责，一般出现在常见的业务驱动的互联网企业中。这种组织具备以下特征：它是由多个跨职能部门或团队组成的大型 IT 组织，达到开发敏捷和流程的标准化，快速响应业务需求，内部具备一套相对完善的效能和质量体系， IT 组织具备对外输出和服务的能力。这种组织在 DevOps 推进过程中能够基本实现能力输出的自闭环，同时会存在交付流水线的各能力子域人员冗余，容易造成资源浪费，并缺乏项目后评价和成本复盘的能力。

（ 3 ）以用户响应为导向的团队组织，承担传播价值的职责，一般出现在常见的科技驱动的互联网企业中。这种组织具备以下特征：它是矩阵式的小型 IT 组织，具备相应的管理职能和业务属性，以架构师、项目经理和业务经理为核心，并通过临时项目组或团队的形式提供服务。这种组织在 DevOps 推进过程中能够快速地进行信息传递和资源共享，同时具备矩阵管理的相关特点和复杂的交叉汇报关系。

还有一种以 IT 最高领导为核心的 DevOps 组织，兼顾以上 3 种团队组织的优点，自上而下地进行统筹管理，交付流水线的各能力子域可以稳定、独立地进行工作，并快速地进行信息汇聚和能力输出， IT 全生命周期管理能够从成本和效能出发，并与企业经营和业务运营结合，根据企业的需要能够灵活地对资源进行配给，价值交付的能力较容易达成，度量和反馈能力较为突出。

3 ． DevOps 的总体架构中组织的模式

DevOps 的总体架构中的组织存在差异，意味着这种差异会面向公司文化、 IT 组织的管理方式和价值交付的输出方式，重点体现在沟通方式和成本，信息的触达和汇聚，产品的交付和质量，以及反馈的效果和调节。

企业在 DevOps 的实践和落地过程中，进行了多次形式上的衍变，从原生的研发、运维，到后续的研发、测试和运维，再到项目、需求、研发、测试、运维和安全，目前已经具有两个主要方向，一个方向是以技术运营为主的价值交付，另一个方向是以产品生命周期管理的价值输出。两者随着企业类型的不同而形成交叉，是一种彼此包含的关系。

同时，一个理想的 DevOps 组织应该是一个跨 IT 职能的组织，组织成员可以包括运营人员、产品人员、需求人员、研发人员、测试人员和运维人员，还可以包括具备矩阵特性的项目管理人员和架构师。在通常情况下，各能力子域的成员应该共享目标和价值，并对各自的过程和结果负责，具备统一的价值观，并有标准的流程和工具。组织负责价值交付和价值输出，而各能力子域需要对最终的产品负责。而在实际情况中，各能力子域的职责划分要比 DevOps 的总体架构划分容易得多，这也导致了在实际落地过程中，因不同组织的模式而产生各种各样的问题。在一般情况下，组织的模式会产生不同的组织结构，而不同的组织结构会导致不同效率。下面介绍 4 种 DevOps 组织模式。

1 ）割裂式的 DevOps 组织模式

割裂式的 DevOps 组织模式是常见的 DevOps 组织模式，也是一种流程式的伪 DevOps 组织模式。在很多企业进行 DevOps 落地的过程中，能力子域的职能并没有嵌入全链路价值交付流水线中，已然处在“部门墙”的形态中进行信息交互和价值交互，在数据口径、度量口径和争议口径中依旧“各自为战”，最终的目标是虚荣的。

割裂式的 DevOps 组织模式如图 1-6 所示，价值交付链路过程中形成多个割裂式节点。

图 1-6

2 ）阻断式的 DevOps 组织模式

阻断 式的 DevOps 组织模式也较为常见，一般出现在 IT 组织规模较小的公司，其特点是人员复用率高，职能边界模糊。与割裂式的 DevOps 组织模式相比，阻断式的 DevOps 组织模式并不存在“部门墙”，信息交互和价值交互顺畅，数据口径、度量口径和争议口径以唯一的形式存在。需要注意的是，这种表面上的顺畅掩盖了内在的风险，往往会造成某个能力子域去做另一个能力子域的事情，导致专业领域的权威性缺失。从逻辑上来说，这会对业务连续性和产品质量产生极大威胁，违背 DevOps 的锚定价值，从而导致 DevOps 组织失衡。

阻断式的 DevOps 组织模式如图 1-7 所示，价值交付链路过程中形成多个阻断式节点，且若干个阻断式节点形成独立的阻断式区域。

图 1-7

3 ）排斥式的 DevOps 组织模式

排 斥式的 DevOps 组织模式一般出现在以 DevOps 原生理念进行落地的过程中。从 DevOps 的发展历程可以得知，从研发和运维一体化到研发和运营一体化，经历了能力子域的大面积拓展。因此，在这个阶段，即一体化的范畴阶段性固化后，多个“部门墙”被打通，并形成了一个大的“部门墙”，以阻隔新纳入的组织成员单位破坏现有的组织文化，因此，信息交互和价值交互会产生一个新的且更为严重的瓶颈，数据口径、度量口径和争议口径会无限放大。

排斥式的 DevOps 组织模式如图 1-8 所示，价值交付链路过程中形成多个排斥式区域。

图 1-8

4 ）平衡式的 DevOps 组织模式

在 DevOps 最佳实践中，成功落地的企业具备一个相同的特征，即通过跨职能组织的协同合作，共担职责，打破“部门墙”，并具备期望合作的愿望。因此，具备这种特征的 IT 组织的能力子域极有可能是平衡式的 DevOps 组织模式。在实践过程中，相同的价值观促使组织成员共同承担责任，实现共同目标，各能力子域可以有效合作，确保最终的价值交付和价值输出。

但这种高度协同的模式的达成是一个漫长的过程，需要组织的领导者具备高度统筹的能力，也需要技术的支撑具备一体化的赋能。在实践过程中，通常需要在某些领域达成阶段性目标，如 DevOps 的原生阶段，集中在研发和测试阶段，研发和运维阶段，或者需求和研发阶段，这意味着有一个过渡阶段的组织平衡过程。

通 常，组织内部会通过交付链路的关键节点来承担试点职责，典型的有研发组织的敏捷，测试组织和运维组织的自动化，需求组织的需求精准控制，以及项目组织的风险管理。这个试点成员也将成为 DevOps 文化的种子， DevOps 的布道师，以及流程和工具相关的领域专家。

平衡式的 DevOps 组织模式如图 1-9 所示。在价值交付链路过程中，各个节点呈现“共同承担责任，实现共同目标”的特点。

图 1-9

1.3.2 DevOps 的流程

DevOps 的流程是一个全局概念，贯穿需求交付、资源交付、软件交付和产品交付的整个过程，实现最终的价值交付。DevOps 落地的本质在于方法论的落地，因此 DevOps 的流程需要兼顾需求交付的准确、资源交付的合理、软件交付的敏捷和产品交付的反馈。在此期间，随着安全、合规的关注度不断提升， DevOps 还需要符合安全审计的要求，以抵御内部风险。

1 ． DevOps 的流程种类

DevOps 的目标是锚定价值。在 DevOps 的流程设计方面，需要紧扣价值主线。在价值主线方面，需要明确 3 个要素，即流程价值的流转、流程价值的跟踪和流程价值的复盘。

1 ）流程价值的流转

价值的载体是产品，而流程的载体是人。因此，在 DevOps 实践的初始阶段，会出现一系列共性问题。

q DevOps 应该从哪个层级开始？

q DevOps 应该从哪个组织开始？

q DevOps 应该从哪个角色开始？

在全链路价值交付过程中，并不是每个组织成员都认可 DevOps ，尤其“部门墙”比较严重的区域，这个问题并不是通过时间来解决的。因此，流程价值的流转需要从高价值的区域开始，得到管理者的支持和认可是直接的方式。自上而下的价值流转是效率很高的一种方式，也是直接的方式，也就是我们俗称的“一把手”工程。这和 DevOps 提升组织级的效能和质量的核心价值观相符。

2 ）流程价值的跟踪

DevOps 开始在组织中进行推广，流程价值的跟踪成为关键任务。团队会根据 DevOps 的流程进行信息传递和汇聚，同样会进行产品的生产和交付。当 DevOps 发展到成熟阶段时，流程作为工具和信息的载体，在不断构建和传输，因此流程创造的价值需要 具备高可用特点和抵抗风险能力，这已不是某个能力子域的问题，会成为这个 IT 组织 的问题。

在实际过程中，流程价值的跟踪可以进行分解，流程按照不同的组织进行划分，主要可以分为信息传输流程、需求交付流程、研发交付流程和项目管理流程，流程价值最终依托流程的归属进行合理的管理，促进流程快速流转和减少重复工作。

（ 1 ）信息传输流程：在全链路交付过程中，任何节点的信息传递和交付，业务的需求分解，需求的讨论，代码的回检，上线前的评审，以及上线后的质量反馈都需要一个反馈路径来达到信息的闭环。

（ 2 ）需求交付流程：交付环节的重要组成部分，包括需求的受理和任务的分解，需求的流转和任务的下发，以及需求组织的内部管理。

（ 3 ）研发交付流程：同样是交付环节的重要组成部分。作为交付的核心流程，对软件的研发阶段进行全生命周期管理和具备交付质量的管控。

（ 4 ）项目管理流程：该流程的重点在于将能力子域的管理转化为交付内容的时间管理，因此需要细化流程的衍生要素，如产品交付管理、流程流转管理和项目风险管理。

3 ）流程价值的复盘

流程价值的复盘处于后置阶段，帮助全链路交付过程的各能力子域乃至整个 IT 组织理解整个流程，通过流程的调整和优化达成最终共识。这对于 DevOps 的全局架构体系至关重要。流程的前置目标和后置目标是流程价值的复盘的直接动力。

在 DevOps 的实践过程中，我们通常将流程作为一种模型，在模型上执行流程价值的流转，并通过复盘的方式完成度量和反馈。在这个过程中，通常有一个共性问题：在我们的 DevOps 的组织流程中，最薄弱的地方在哪里？让整个组织具备高效和抗风险能力是流程价值的复盘的关键，也有助于我们打破大部分“壁垒”，防范“部门墙”的侵害。随着 DevOps 的发展，一些新的理念和文化帮助我们通过更优的方式来进行流程的整合和优化，如面向终态的流程设计，这方面将在第 3 章中重点介绍。

2 ． DevOps 的流程反馈

在 DevOps 组织中， DevOps 团队通常会以流程模型的方式来提供相应的准入原则，并拥抱最终的反馈。在此期间， DevOps 流程作为企业流程的子集，应该具备可延续性和可优化性，重新定义流程的反馈机制，以支撑 DevOps 的价值观，通过流程的合理运用来形成具有一定规模性的复制，最终为企业输出 DevOps 组织的核心价值。

1.4 DevOps 文化

1.4.1 为什么需要 DevOps 文化

经过慎重考虑，作者决定把“ DevOps 文化”部分放在本章的中间。对于一个组织，文化起了地基的作用。DevOps 是否能够按计划和规划实现，文化是一个重要因素。在企业的实践过程中，很多案例凸显了一个事实：DevOps 转型的第一个要素是实践 DevOps 文化，并通过文化建设促使 DevOps 进行实践和落地。

对于企业，文化具有统一思想和价值流向的作用。对于 IT 组织， DevOps 文化的作用更为聚焦和纯粹，促使组织成员不断进行知识沉淀和过程管理并将结果反馈至组织，从而提升组织级的效能和质量。

1.4.2 传统 IT 组织文化存在的弊端

1 ．更多的惩罚

IT 组织文化中的惩罚源于传统行业。在制造业的信息化转型过程中， IT 组织的工作内容和权责与制造业中的流水线挂靠严重，赋予 IT 组织成员极少的权利， IT 组织成员更多时候以支撑的角色来作业，因此无法从日常工作中得到成长，更缺乏连续学习和创新的机会。相对应的， IT 组织成员对企业和 IT 组织缺乏相应的知识共享和传递精神。出现这种现象的本质是文化的缺失。在这种文化氛围下，惩罚是 IT 组织反馈的唯一方法，通过惩罚来促进优化和改进，以及进行考核和促进成员成长。

2 ．有意识地进行隐瞒

IT 组织文化中的隐瞒存在于大部分企业，在组织文化层面，缺乏合理的复核和考核机制，在技术体系层面，缺乏相应的监控和度量机制，导致业务连续性风险。在很多企业中，随着业务的不断拓展和信息系统数量的不断增加，文化和技术的结合得不到及时跟进，于是 IT 组织的发展得不到文化的赋能，导致风险无法被管控。

在事件和问题管理中，一般有事前、事中和事后 3 个阶段，经过作者统计，约 80% 的问题是由于 IT 组织成员的失误造成的，因此，在事前进行管理，就显得非常必要。而在 IT 组织管理中，绝大多数问题的管理集中在事中和事后，事前管理更多集中于流程流转和资源输出，因此， IT 组织作为支撑，事前管理的缺失会导致最终价值输出存在极大风险，而在最终 KPI 考核层面，风险性较大的环节往往得不到重视，带“病”上线的情况经常出现。一个典型的现象：从架构设计、代码设计到性能和质量的把控，趋向于以流程为基准，漠视数据反馈和隐瞒风险成为大多数人的选择。

3 ．缺乏分享精神

科技是第一生产力。从本质上来说，技术的提升是组织级的能力提升。为了辅助达成这个目标，文化的作用尤为重要。若体现在氛围方面，就会形成一个高度信任的环境，使得 IT 组织成员乐于提出意见，并进行信息无障碍传递和知识分享。在实际的日常流水线工作中，通过技术革新和文化加持，将风险提前暴露，并进行流程优化，促使新理念和新技术不断被尝试和优化，最终推广至整个 IT 组织，提升组织不断适应快速变化的环境的能力，将整体变得越来越敏捷，越来越集约，越来越可靠。

1.4.3 DevOps 文化具备的特点

下面介绍 DevOps 文化具备的 5 个特点。

1 ．具备全局的系统思维

在 IT 组织内部，成员必须具备从全局系统的角度与业务进行结合的思维。全局的系统思维涵盖了链路级的系统范围，而不是自己负责的某个功能模块。践行 DevOps 理念，不能局限于自身，应从自身出发并沿着领域、团队级和组织级的脉络进行涵盖。

全局的系统思维意味着成员应了解其他成员、能力子域在价值交付流水线中承担的职责和工作范围，同时了解其可能造成的影响，如是否对全局的系统链路或业务造成影响，是否是业务连续性保障中的风险点。在持续交付的目标中，有一句话值得思考：交付的目标是将不同的实践、流程和程序进行高度协同，以抵消风险，高质量和高效率地完成交付。这句话其实也体现了 DevOps 的锚定价值，即提升组织级的效能和质量，达到最终的价值交付。

2 ．关注业务需求是否契合 IT 组织文化

DevOps 需要达到端到端的价值交付，而交付的主体是业务组织，因此业务需求需要进行统一的扎口和事后复盘。尤其在 IT 组织文化层面，需要组织成员通过价值流向来梳理交付流程和确定交付核心节点，围绕价值流向来判定交付进度和交付过程中的风险点，并通过技术手段和管理手段进行规避和优化。

价值交付将业务需求从设计发展到产出，最终到终端交付。在这个过程中， IT 组织的文化起到了管理理念和管理方式的固化作用。价值的定义在组织内部是顶层目标，提升交付的效率和质量是具体方法。文化赋能能够促使团队成员随时进行业务价值的跟踪和反馈，并及时与业务部门、需求部门实现信息的传递和协调机制的建立。

3 ．共担责任

共担责任是 DevOps 文化的根本，不能共担责任的文化意味着组织成员最终会“单兵作战”且主动关闭信息共享通道。在价值输出流水线中，具备共担责任的节点主要为交付速度和交付质量，交付质量更为突出。在质量环节，如果质量管理由某个能力子域独自承担，那么意味着违反了 DevOps 的模糊边界原则，在此期间，缺乏客观的数字化呈现，质量的管控体系会形成无法打破的“墙”。

在价值交付模式下，质量管理是关键节点，与质量相关的能力子域需要共担责任。在 DevOps 文化中，强调打破“部门墙”，建立互相信任的通道，交付速度和交付质量之间的矛盾需要通过模糊边界来解决。模糊边界的核心文化是共担责任。因此，必须通过流程和数据的管理方式和文化理念才能达到最终提升组织级质量的要求。负责质量的能力子域需要在其他能力子域的配合下，尽早发现和解决问题，从价值交付的角度来触发，更有助于流水线上各能力子域高效协作，促进整体质量提升。

4 ．勇于“试错”

试错的成本包括学习成本、实验成本和总结经验的成本。试错也是达到最终目标的必备手段。在试错环节，信任是试错的基础，也是 IT 组织各能力子域通力合作的基础，尤其在 DevOps 价值输出流水线过程中，试错是检验信任的重要手段。

IT 组织各能力子域需要认清试错等同于最终成功的价值，并及时在 IT 组织内部进行分 享和信息传递。只有不断试错和勇于试错，才能暴露更多的风险和提升技术的赋能。

5 ．善用数据，通过数据说话

数据是 DevOps 中的重要组成部分，这种趋势将一直延续。没有量化数据的管理，一切判断都是主观的。管理者需要客观地分析和解决问题。因此，没有数据思维，就不能持续地进行度量和反馈。

在 DevOps 的价值输出流水线中，整个交付周期的管理依赖各能力子域的节点数据的输出。无论是 IT 组织的管理者还是各能力子域的管理者，都需要输出数据、使用数据，并信任数据，通过数据的分析和输出，从全局的角度关注内部的优化和改进，促进信息流转和数据赋能。

1.4.4 DevOps 文化的目标

在企业文化中， DevOps 文化是面向 IT 组织和软件产品交付的独有文化，具备多重标签，包括内部管理、数据使用、信息传递和互相信任。对于 IT 组织，提倡免责、共担责任、高度信任、分享和协作，这种文化会改善 IT 组织内部的协作和管理方式。通过对 IT 组织各能力子域的文化赋能，能够有效地提升交付的效率和质量，并加快技术迭代和技术创新的速度，最终反馈至业务组织，实现更高的业务价值，助推企业发展。

1.5 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 工具的选择

在工具的选择方面，作者经过大量的实践和调研，提出了工具选择方法论。这个方法论主要包含 4 个方面：工具的驾驭、工具的价值、工具的赋能和工具的本质，如图 1-12 所示。

图 1-12

1 ．工具的驾驭

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

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

2 ．工具的价值

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

3 ．工具的赋能

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

4 ．工具的本质

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