《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）

作者：顾黄亮 （现任苏宁消费金融安全运维部总经理）

【声明】为了能让大家更好的学习Devops以及深入了解应用Devops的实践案例，《DevOps权威指南：IT效能“新基建”》作者顾黄亮先生授权twt社区进行该书部分内容连载。内容包括DevOps的基本概念，DevOps的工具集，支撑管理，敏捷开发，持续集成和测试，持续部署和持续交付，代码质量和安全，DevOps的度量体系，持续改进和反馈，DevOps最佳实践，以及DevOps的后续发展。

# 第 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 组织的核心价值。

## 全部连载

《DevOps权威指南：IT效能“新基建”》-前言
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.2）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.3）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.1）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.3）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.2）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.3）