1.3.1 DevOps的总体架构
在DevOps的落地过程中，因其总体架构具备全局且较为泛化的特性，因此并没有一个统一标准。在由中国信息通信研究院牵头编写的《研发运营一体化（DevOps）能力成熟度模型》中，DevOps更多地以体系化的方法论、实践和标准的集合呈现，而总体架构在体系化的范畴内，更多承担的是企业级组织结构的全局设计，这种设计理念也是和企业的自身发展需求相匹配的，因此，DevOps的总体架构在不同业态和不同规模的企业中落地，具备一部分泛化的标准特性。
1．康威定律在DevOps的总体架构中的作用
在软件工程领域，康威定律具备一定的影响力。在康威定律的描述中，系统设计受限于组织自身的沟通结构，这种组织的形态是不固定的，随着组织的规模变大，相对的灵活性变差，这种现象就越明显。在DevOps的总体架构中，康威定律定义了团队的结构和规模对DevOps的输出能力存在巨大影响。在IT组织内部，能力子域的范围和职能覆盖程度影响内部沟通和信息传递。越小的范围对沟通和传递的影响越小，越大的范围对沟通和传递的影响越大。
同理，DevOps的锚定价值提升组织级的效能和质量，因此，管理价值通过管理组织实现。DevOps的目标必须和组织成员的目标对齐，这就表明在DevOps的总体架构中，协作是基本的构成元素，而协作的过程也是组织架构和团队结构配合的过程。
通过康威定律在DevOps的总体架构中的应用，我们不难发现，协作的第一个障碍是共享职责，必须具备一致的目标和信息传递方式。在很多企业中，达成这个目标有多种方法，如所有能力子域都在一个层级的领导之下，DevOps的度量和反馈方式都具备东西向传递的能力。协作的第二个障碍在于组织的边界。在很多企业中，边界是能力子域的天然特性，因此，在DevOps的总体架构中，需要解决组织无边界问题，或者，让组织的边界以团队自组织的方式存在，这与敏捷的特性类似。协作的第三个障碍与顶层组织能力输出有关，这也是DevOps的总体架构中的高阶应用。对于很多企业，缺乏产品质量反馈和客户满意度调查机制。一般来说，IT组织作为能力输出单位，往往是以前置目标来驱动的。想要解决这个问题，需要在DevOps的总体架构中具备可优化和可回溯能力，最终实现组织的能力输出闭环。
2．DevOps的总体架构中组织的类型
在DevOps的实践和落地过程中，很多企业会遇到因组织架构设置不合理而导致落地结果不尽如人意的问题，其中职能导向是一个明显的问题点。对于体系组织，有多种类型，其中有以下3种典型类型，分别是以后台支撑为导向的团队组织，对应的IT组织具备支撑属性；以产品交付为导向的团队组织，对应的IT组织具备业务属性；以用户响应为导向的团队组织，对应的IT组织具备矩阵管理属性。这3种团队组织分别承担的职责如图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所示，价值交付链路过程中形成多个阻断式节点，且若干个阻断式节点形成独立的阻断式区域。
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实践的初始阶段，会出现一系列共性问题。
DevOps应该从哪个层级开始？
DevOps应该从哪个组织开始？
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组织的核心价值。
