《DevOps权威指南》电子试读版-第一章-DevOps的实践和落地

在进行本节内容的描述之前，我们先了解一下企业对DevOps进行实践和落地的初衷。在1.1.1节中，企业对DevOps的期望是面向组织级的效能和质量提升，并且可以更快、更好、更稳定地支撑业务发展或引领业务发展。因此，对于IT组织，在对DevOps进行实践和落地时，需要关注以下两个原则：

（1）是否能够快速进行价值交付，促使公司产品能够及时响应市场的变化；

（2）是否能够促使IT组织更多地关注业务，并支撑业务目标的改进和提升。

一般来说，无论是业务驱动型的企业还是科技驱动型的企业，当引进新的技术或因产品转型需要更高要求的技术支撑时，通常会出现一个问题，那就是交付的快速响应和产品稳定性问题，这是IT组织需要优先考虑的问题。当企业进行成本复盘或IT组织进行利润中心运行的时候，会出现既有数据不能够支撑成本复盘和摊销的问题。除此之外，由于企业的经营层和相关职能组织对IT能力输出的理解不同，因此导致IT支撑和创新缺乏科学的评估和定论。因此，企业对DevOps的实践和落地呈现多种需求。从企业的角度出发，可以将需求归纳为以下几类。

（1）市场的易变性，导致产品需求的不稳定性。

（2）IT组织的价值输出不确定性，导致在新技术引进、技术转型和需求快速膨胀等条件下出现不规则的价值输出。

（3）业务和产品的复杂性，导致IT组织内各能力子域因信息传递和沟通被各种因素干扰。

（4）公司业态和企业文化的模糊性，导致行业规则、安全准则不能以流水线的方式进行规范的约束。

1.6.1  DevOps实践和落地的模型

（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的推动者和管理者的经验缺失，导致过度关注流程，而忽略数据，最终导致数据的维度、受众人群的覆盖率、数据资产的质量和交付链路的数据生命周期缺乏科学的管理和输出。