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

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

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

1.6.1 DevOps 实践和落地的模型

DevOps 的核心元素包括 3 种，分别是组织、技术和流程。 DevOps 落地的模型基于核心元素进行扩展和组合。其中组织和流程构成了文化，流程和技术构成了工具，组织和技术构成了能力输出。文化、工具和能力输出构成了 DevOps 实践和落地过程中 3 个不同的阶段，如图 1-15 所示。

图 1-15

（ 1 ）在文化阶段，呈现的是流程和组织的集合方式。在 IT 服务流程的支撑下，组织会形成一整套行为参与准则，而组织的行为参与准则会时刻影响软件交付、产品交付和价值输出的各阶段的效能和质量，因此需要将组织的行为参与准则进行规整，形成行之有效、可持续的 DevOps 文化。

（ 2 ）在工具阶段，呈现的是流程和技术的集合方式。在技术的支撑下，结合流程形成一整套承载 IT 组织能力输出的标准流程，这也是 1.5 节所描述的工具链。在这个阶段，有一个鲜明的方法，任何流程和技术的结合都是为了解决实际问题而引进的工具，这一点在工具链的介绍中有所体现。在工具的选型和使用方面，应具备 3 种特性，分别是工具的吸引效应、规模效应，以及工具链汇聚效应。

• 吸引效应，处在工具阶段的初级阶段，一般是开始进行构建局部工具链的阶段。初始工具会不断吸收与之上下游相关的工具，逐步形成一个初级集合，然后会逐步形成局部工具链。
• 规模效应，处在工具阶段的中级阶段，一般是完成局部工具链构建的阶段。工具链的构建成本会随着 DevOps 需求的扩展而不断提高，因此，当 DevOps 的工具链构建到一定阶段的时候，局部工具链的构建应实现一定的规模化。
• 工具链汇聚效应，处在工具阶段的后期阶段，一般是全局工具链，特指全局的价值交付流水线的构建阶段。在这个阶段，流程、数据和信息传递具备共享能力，能够快速接入新的业务和产品，并能实现规模化的能力输出。

（ 3 ）在能力输出阶段，呈现的是组织和技术的集合方式。工具是标准化流程的载体，一方面可以规范和约束组织的行为，另一方面，可以对组织进行赋能，进行能力输出。而组织作为行为的主体，通过工具链进行高度协作，更好地实现能力输出。

在 DevOps 落地的模型中，文化、工具和能力输出作为 DevOps 实践过程中的 3 个阶段，体现了对组织、流程和技术的关注。无论是组合的多样性还是融入性，组织、流程和技术都应该融为一体，缺一不可。只有将组织、流程和技术有机结合，通过文化、工具和能力输出进行推进，才能对 DevOps 进行有价值的落地。

1.6.2 DevOps 实践和落地的基本原则

由于企业的类型、业务场景、驱动模式、组织架构，以及 IT 组织的规模和技术能力不相同，甚至企业的经营层对 IT 的支撑能力和创新能力具有不一致的度量和要求，因此，对于 DevOps 的落地，需要根据企业的实际情况因地制宜、因人施策和因势利导。

根据 DevOps 落地的模型，我们可以得知，组织、技术和流程是 DevOps 的核心要素，文化、工具和能力输出是 DevOps 落地的 3 个阶段。要素和阶段是 DevOps 落地基本原则中的构成部分，下面分别进行阐述。

1 ） DevOps 推进者的原则

DevOps 的推进者需要从 DevOps 的 3 个核心要素出发，制订 DevOps 实践和落地的全局规划和推进步骤。 DevOps 的实践和落地具备 3 个原则，分别是通过组织进行协同工作的推进、通过技术实现“基础设施即代码”和通过流程固化持续交付能力。

（ 1 ）协同工作。 IT 组织的各能力子域必须进行高频且密切的信息交互，拥有完善的全链路价值交付的上下游关系。在协同工作原则内，需要达到几个要求：自动化的信息流转，将大范围的工作内容分解成小范围的工作内容，具备统一的信息集散地和流转通道，以及完备的协同工具。

（ 2 ）“基础设施即代码”是实现 交付快速响应和获得产品稳定性的重要手段。 IT 组织的各能力子域通过自动化的手段将计算资源、存储资源和网络资源进行持续输出。

（ 3 ） 持续交付能力。通过固化的流程，打通端到端的持续交付通道、端到端的资源交付通道和端到端的服务交付通道，这 3 种通道统称为持续交付能力。与原生的 DevOps 交付能力不同的是，构建、集成与部署只是开发和运维阶段，而且持续交付能力需要延伸至整个 IT 组织。除此之外，需求的吞吐率和研发的吞吐率应该涵盖在持续交付能力之中。

2 ） DevOps 管理者的原则

DevOps 的管理者需要从公司的实际情况出发，并具备全局的 DevOps 理念和判断。作者认为，企业对 DevOps 进行实践和落地，不缺乏推进 DevOps 的人，而是缺乏对 DevOps 具有全局理解和体系建设的人，因此，管理者在 DevOps 的实践和落地过程中应该具备以下原则。

（ 1 ）管理者需要主动进行组织架构的调整，从组织顶层的角度推进 DevOps 的实践。

（ 2 ）管理者在 DevOps 的实践和落地过程中，愿意承担一部分因各能力子域的试错带来的损失。

（ 3 ）管理者需要了解企业在价值交付过程中的问题的优先级，分阶段以“小步快走”的方式进行 DevOps 方法的转型。

（ 4 ）管理者应该具备工具化意识，最大化地利用工具和自动化流程。

（ 5 ）管理者应该具备数据意识，采用有效度量的手段对所有的过程和结果进行判断和分析。

3 ） DevOps 各能力子域的原则

DevOps 各能力子域作为 DevOps 的实践和落地过程中的深度参与者，应在 DevOps 的推动者和管理者的统筹下，统一思想，凝聚力量，在 DevOps 价值体系内认领职权。因此，在 DevOps 的实践和落地过程中， DevOps 各能力子域应具备下列原则。

（ 1 ）找出各能力子域之间的边界，并通过技术手段逐步模糊边界。以研发和运维为例，运维的核心指标为稳定性和安全性，以系统可靠性指标为代表，研发的核心指标为需求研发吞吐率和研发质量，以交付效率指标和代码质量指标为代表。因此，针对系统可靠性和代码质量会形成口径不一致的能力子域边界，浪费大量的时间和资源。

（ 2 ）顺应各能力子域之间的技术革新形势，使 DevOps 的技术接入具备可扩展性和可持续性。以开发模式为例，循序渐进地支持瀑布开发、敏捷开发和 DevOps 开发；以应用架构为例，循序渐进地支持单体架构、 MVC 分层和微服务架构；以部署方式为例，循序渐进地支持物理机部署、虚拟机部署和容器云部署。

（ 3 ）明确各能力子域之间的合作顺序和数据共享范围，以及合作的节点和上下游关系，打破因合作顺序和数据共享问题造成的屏障，让 IT 组织从业务需求出发，最终实现组织级的效能和质量的提升。

典型的能力子域的范围如图 1-16 所示。

图 1-16

1.6.3 DevOps 落地过程中的问题

在 DevOps 的实践和落地过程中，企业会遇到各种各样的问题。一般来说，问题大多源自 1.6.2 节中描述的 DevOps 落地的基本原则。常见的问题分为以下几类。

1 ）相关能力子域对 DevOps 有超出预期的计划

大多数企业在 DevOps 的实践和落地过程中出现过这样的问题。这个问题在全链路价值交付的各能力子域尤为突出。有些企业为了实施 DevOps 而实施 DevOps ，即使管理者从组织和文化的角度进行铺垫，仍然以所在组织为核心，没有真正地从价值交付和以业务为视角出发，导致相关能力子域对 DevOps 有超出预期的计划。

对于中心化的研发组织，因文化的宣传和贯彻不力，或者技术革新未匹配到 DevOps 的实践和落地过程中，导致与其他能力子域无法建立通常的信息沟通渠道和数据共享路径，最终导致内部管理滞后和出现隐形屏障，无法实现 DevOps 的红利变现。

2 ）推进太快，导致在 DevOps 的实践和落地过程中出现断层

由于企业类型和业态的不同，因此，传统企业在组织、流程和技术层面无法合理地进入 DevOps 初期阶段，而多数的创业公司，因科技赋能较强，可以跨阶段地进入 DevOps 后期阶段。因此，这会导致推进程度不匹配企业的实际情况，不能做到 因地制宜、因人施策和因势利导。

对于企业，为了快速提升产品能力，巩固市场竞争力，亟需提升 IT 支撑能力，企业的管理者期望通过 DevOps 快速提升组织级的效能和质量，以达到上述高效的状态。而 IT 组织的各能力子域均没有达到大规模实践 DevOps 的时间点，因此造成了 DevOps 的实践和落地过程中出现断层。

3 ）工具选型不清晰，导致工具组链失败

在实践中， DevOps 在中期阶段依赖局部工具的组链，逐渐到最终全局工具链的构成。在 DevOps 的实践和落地过程中，因企业的历史“包袱”，导致对过时的工具依赖过深。而工具的选型具备一定的方法论和原则， IT 组织因技术革新的缺失，无法对更为优秀的工具进行学习和研究，或者，对工具进行过多的学习和研究，导致在工具选型阶段，出现动作缓慢和认知不清晰的问题，最终导致工具组链失败。

4 ）数据生命周期管理缺失，导致度量和反馈不准确

这个问题一般出现在 DevOps 后期阶段。一般来说， DevOps 的前、中期阶段为流程驱动阶段，后期才需要数据驱动。流程驱动和数据驱动的区别是目标不同，流程驱动为前置目标驱动，而数据驱动为后置目标驱动，度量和反馈是后置目标驱动的典型场景。

在工具的选型和组链阶段，由于 DevOps 的推动者和管理者的经验缺失，导致过度关注流程，而忽略数据，最终导致数据的维度、受众人群的覆盖率、数据资产的质量和交付链路的数据生命周期缺乏科学的管理和输出。

1.7 DevOps 的价值

通过对 DevOps 的概念、理念、发展轨迹、特点、总体架构与流程，以及实践过程中的工具链框架的打造和实践原则的描述，最终锚定 DevOps 的价值。随着 DevOps 原生理念的延伸， DevOps 的价值变得更为丰富，无论是 IT 组织的各能力子域、 IT 组织自身，还是企业，均获得相应的收益。对于企业，产品的创新和市场占有率都需要 IT 组织的支撑能力和创新能力的提高。对于 IT 组织， IT 能力决定了业务开展的深度和广度，自身的能力输出需要匹配甚至超越企业的业务发展。在 IT 组织内部的各能力子域，需要对 IT 能力输出负责，研发体系的敏捷，信息系统的安全、稳定和可靠，产品需求的精准，以及项目管理的完善和严谨都是必备条件。因此，在本章中，针对 DevOps ，我们将从多个维度对价值进行论述，对实践和落地过程提供锚定的指引。

1.7.1 提升 IT 组织中研发管理的价值

在 IT 组织中，研发是主干，也是利润和价值输出的“主力军”，因此，对研发进行有效管理，就实现了非常大的效能和质量提升。

1 ）通过 DevOps 实现软件的快速交付

根据《中国 DevOps 现状调查报告（ 2020 年）》的描述，在采用 DevOps 的企业中，其中 28.06% 的企业在部分团队已经使用 DevOps 一段时间，目前处于优化阶段； 15.72% 的企业中已有一半以上的团队的敏捷开发实践在整个组织内处于比较高的水平； 13.91% 的企业中的所有团队已经熟练掌握敏捷开发，可根据情况调整、改善和创新实践，达到对敏捷开发的最佳实践。据数据统计，传统企业的占比为 32% 。由此可见，越来越多的企业选择通过 DevOps 来提升软件的快速交付能力。

传统企业在转型，其实互联网企业在快速交付的道路上已经走了很多年。经过考证， 2011 年， A WS 平均 12 秒在生产环境中进行一次变更， Facebook 每天进行两次生产环境代码交付， Google 的很多服务每周可以进行多次发布。 2012 年，国内某大型企业需要上线一个需求，如果按照当时服务商交付的速度进行测算， Apple 的交付时间是半个月～ 1 个月， Google 的交付时间是 1 个月～ 3 个月，微软的交付时间是 6 个月～ 12 个月。通过上述例子，我们可以思考是什么成就了 AWS 、 Facebook 、 Google 和 Apple ，又是什么导致了微软 Windows Phone 在市 场竞争中的失败和产品的消亡。

下面以 Visual Studio 为例进行说明。微软的 IT 组织在 2012 年开始进行 DevOps 转型。在转型之前，微软每 3 年进行一次 Visual Studio 版本发布和产品更新，而现在可以建立 3 周的功能迭代计划，并实现应用上“云”，通过自动化工具实现了软件产品的持续交付。更重要的是，通过持续交付加强了用户的反馈，提高了产品的价值。

当然，在软件出现以后，研发模式不断进化，从无序到有序的管理演进，研发标准化，从敏捷开发发展到现在的 DevOps 研发。运维模式也在不断迭代，从最初的人工运维到工具化运维，再到一体化运维，最终发展到目前的研发与运营一体化。因此，通过 DevOps 提升软件的快速交付能力是 IT 组织中的基本价值。

图 1-17 为软件交付效能的比较。从图 1-17 中可以得知，在部署频率、变更前置时间、服务恢复时间和变更失败率 4 个维度，各个层级的效能是相差很大的。

图 1-17

2 ）通过 DevOps 提升敏捷的质量

在现 代软件交付模型中， DevOps 框架体系中的敏捷管理相比传统 项目管理多了两个关键因素：价值和质量。从此，泛化的价值得到了统一，涵盖了成本、进度、范围、质量和价值。

在产品交付的前置阶段，因为需求方不能准确描述他们想要的东西，所以需要把业务系统以用户故事的方式呈现，或者将业务系统 描述为 具备一个或多个有特定业务价值的功能。通过快速迭代，快速交付这些用户故事，最终及时得到用户反馈。在高效且无障碍的沟通的基础上，最终交付用户真正想要的东西。

DevOps 的原生理念主要体现在 IT 组织内部，可以简单地理解为将敏捷思想应用于软件开发、技术运营和质量保障，全面提升敏捷水平，更多地通过流程贯通研发、测试和运维。在引入 DevOps 后，在业务响应速度、质量、安全性保障、员工满意度和投入产出比等方面可以得到大幅提升。

根 据相关数据的统计结果，图 1-17 中的精英 DevOps 团队在部署环节的速度提 升了 200 倍，问题修复的速度提升了 24 倍，变更错误率降低到原来的 1/3 ，线上问题修复时间或服务恢复时间降低到原来的 1/2500 ，减少了 22% 不可预料的问题，减少了一半的安全和性能问题，同时，减少了低价值的重复性工作和不可服务时间，让 IT 组织成员有更多的时间投入更有意义的工作，如新功能开发和技术迭代。

3 ）通过 DevOps 构建新一代的技术架构

在企业的发展过程中，应用的技术架构随着业务的发展不断进行迭代。在业务爆发式发展的今天， IT 技术需要优先于业务发展计划进行迭代。因此， DevOps 要构建新一代的技术架构，提升 IT 组织的价值。

以微服务架构为例，微服务有助于研发团队提高变革的速度和敏捷性，但仅依靠新的架构还不够。负责应用架构的架构师必须在 IT 组织内部进行 DevOps 文化的普及，除此之外，还需要进行流程、组织和研发平台的变革，从而真正为企业创造效益。

微服务架构是一种将软件构建到可移植和半自动组件中的模式，具备敏捷的特性，但其成功完全依赖采用现代应用平台和技术的敏捷流程和实践，因此，微服务架构需要 DevOps 进行文化和流程的规整，同时需要 DevOps 在工具链的集成以进行技术体系的覆盖和融合。

在降低开发的复杂度的同时，微服务架构带来了系统运维和技术运营的复杂性，因此， DevOps 的数据流转和数据分析能力，以及智能监控体系是支持新一代技术架构落地的基础和前置条件。

1.7.2 提升 IT 组织中服务输出的价值

1 ） DevOps 能够给 IT 组织的各能力子域带来突破边界的能力

对于 IT 组织内部的各能力子域，文化和技术能力存在比较明显的差异，因此，在 IT 组织服务能力输出的框架下，这种差异会带来服务输出能力新的瓶颈。在企业的发展过程中， IT 组织需要面对新系统的开发和旧系统的技术迭代等问题，从而需要进行人员扩张，同时需要具备更先进的 IT 管理能力。 IT 组织的各能力子域需要突破边界来支持 IT 组织的转型，从而快速地应对变化，更好地支撑业务发展。

在实际情况中，需要通过 DevOps 持续进行能力子域的敏捷和管理转型，通过能力子域的赋能来模糊边界，从而更好地支撑复杂的业务、场景和项目。在 IT 组织内部，边界的突破需要统一的管理，整体的研发效率的提升直接带来降本增效。而间接的价值在于团队能力、 IT 治理水平的提升更为显著，最终通过 IT 组织的价值和质量来快速应对业务的变化和管理服务交付的风险。

2 ） DevOps 建立端到端的服务输出的能力

IT 组织若想具备端到端的服务能力，需要采用更为先进的 DevOps 理念，通过 DevOps 工具的组链，形成流水线式的服务输出。我们可以将软件研发工具、基础资源池化技术和运营监控工具进行整合，解决研发过程中代码托管、代码分支、环境管理、架构管理和持续交付等突出难题，支持 IT 组织更快和更高质量地进行 DevOps 转型，在团队管理和持续服务能力输出上实现跨越式提升。

在 DevOps 端到端的服务能力框架中，具备以下能力：端到端的资源输出、端到端的交付输出和端到端的价值输出，贯穿 IT 组织内部的各能力子域。 DevOps 端到端的服务能力框架可以划分为软件交付和技术运营两大部分，分别使用不同的管理域和管理方法。而支撑这些管理的全链路价值交付流水线，通过流程和数据的双轨驱动，可以对软件交付的全过程和全生命周期进行管理。在开发的管理过程中，通过对流程进行梳理和知识的沉淀，形成有价值的数据仓库和知识库。全链路价值交付流水线整合了项目管理、需求管理、架构管理、研发管理、测试管理和运维管理等研发工具，集成了软件研发工具、基础资源池化技术和运营监控等技术运营工具。在基础设施层，通过云计算技术，实现了资源的弹性伸缩，具备“基础设施即代码”能力。借助 DevOps 方法构建研发与运营一体化能力体系，实现贯穿产品需求到产品交付全过程的流水线，建立端到端的全局服务能力。

1.7.3 助力企业进行产品转型和科技输出

随着 IT 组织的支撑能力逐渐转变成创新能力， IT 支撑业务到 IT 助推业务的时代即将到来。纵观国内头部科技企业在抗击新冠肺炎疫情期间的表现，科技赋能的趋势越来越明显，因此， DevOps 的价值在产品转型和科技输出中体现得淋漓尽致。

1 ） DevOps 让 IT 组织全面提升企业各方面的业务能力

随着云计算、大数据、物联网、移动互联网和区块链等新兴技术的成熟和应用，很多企业开始探索科技赋能，用更先进的 IT 技术来提升业务能力。

例如，利用大数据和人工智能技术可以提高数据输出能力，把数据处理能力和智能算法嵌入运营体系，达到智慧运营的目的。利用云计算和移动互联技术可以更好地提升 IT 远程服务能力，提高跨组织和跨地域的软件交付能力。利用移动互联技术和人工智能技术可以更好地理解客户需求，并提高数字化营销能力。

在科技赋能的今天，企业要时刻拥抱新兴技术，用科技助推企业业务的发展，这就需要 IT 组织在文化、技术能力和信息系统方面适应新技术的要求，将技术和业务进行深度融合，通过 DevOps 的价值输出能力，全面整合到企业的内外部价值输出生态链，重塑基于科技赋能的商业模式和全面的 IT 服务输出能力。

2 ） DevOps 赋能 IT 组织，支撑企业进行业务创新

在科技高速发展的今天，企业同时承受两种压力，一种是传统业务的压力，另一种是创新发展的压力，因此，企业压力也会传递至 IT 组织。 Gartner 在其最新的研究报告中提出“双模 IT ”概念。“双模 IT ”概念和 DevOps 的锚定价值是匹配的。双模 IT 具备两种 IT 模式：可靠 IT 和敏捷 IT ，在强调安全性和经济性的同时，还需要具备更快的交付速度和更高的灵活性。因此， IT 组织不仅需要在传统业务模式下提供稳健、安全的服务，还需要助推业务进行新兴领域业务的创新。

在 DevOps 的实践和落地过程中，其价值输出是分阶段的，不同能力子域的能力输出和不同阶段的能力输出是可靠 IT 和敏捷 IT 不断融合的过程。在企业的业务创新过程中，这种有机结合的方式能够让企业的 IT 组织站在更高的位置进行科技赋能，对业务转型提供更好的支撑和帮助。

## 全部连载

《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）