与DevOps相关的“定律”之一由程序员Melvin Conway提出。该定律于1967年问世，其内容很简单：“设计系统的组织……其设计必然受限于这些组织的沟通结构，并成为这种结构的复制品。”
我特别强调了“系统”一词，因为人们往往只将康威定律应用于应用，也就是软件系统。但实际上，“系统”涵盖从应用到交付和部署这些应用的集成流水线等一切内容，也包括您的流水线。
在部署端（即生产环境）采用DevOps方法时，还需要了解康威定律等相关原则。因为该定律不仅适用于部署流水线的设计，也同样适用于流水线推向市场的应用。
您可能还记得，我们在《2019 年应用服务状况报告》中提出了两个问题。第一个问题涉及 IT 的组织结构，即综合运营团队、单职能团队或跨职能团队。调查发现，在 2,000 多名受访者中，近一半（46%）采用单职能团队模式。综合运营团队占 37%，位居第二。跨职能团队相对少见，仅有 15% 的受访者采用这种组织结构。
这一点很重要，因为接下来我们将考察部署流水线自动化的现状。调查结果明确反映出单一职能团队占主导地位。
这些数据表明，自动化工作缺乏一致性，无助于实现近半数（48%）受访者在数字化转型方面的目标，即更快、更频繁地部署应用。IT内部这些成熟领域之间的差异有力地证明，康威定律适用于任何地方的任何系统。
进一步分析发现，略高于十分之一（11%）的受访者仅实现了其中一个领域的自动化。四分之一（25%）的受访者已实现两到三个领域的自动化。略高于五分之一（21%）的受访者则实现了全部四个主要领域的自动化，而这四个领域是构建全自动部署流水线的必要条件。
有相当高比例（42%）的受访者在这些领域中一个也没有实现自动化。
部署流水线各环节的自动化程度不均，是影响价值实现时间的一个重要因素，因为流水线中每遇到一个手动流程，都会造成延迟。这种延迟会拖慢价值实现速度（也可以说是产品上市速度）。自动化率的差异反映出组织继续采用“单一职能团队结构”所带来的影响：各个“孤岛”各自实现自动化，却很少或完全不考虑其与流水线其他环节的交互。
因此，更适合采用联合运维或跨职能团队结构。这样一来，IT领域之间的沟通将成为对等协作流程，更有利于设计兼顾多方面需求的系统。由团队设计管道（系统）时，可以从整体出发加以考量，而不是只关注各个组成部分。
自动化工作本身可以（而且很可能应该）由领域专家负责。但整体设计和集成方式（API）需要由开放协作的团队共同设计，否则就会形成自动化孤岛，未必能实现更快、更频繁地将产品推向市场这一业务目标。
因此，如果在尝试实现生产流水线自动化时遇到延误或阻碍，不妨退一步，审视现有的组织结构，以及这些结构如何影响流水线的设计。您可能会发现，要有效实现任何自动化，首先需要推动建立更高效的组织结构，为这项工作提供支持。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。