原文连接： https://blog.matthewskelton.n...
原做者：Matthew Skelton
翻译君：CODING 戴维奥普斯

大部分组织对 DevOps 发起设立的初衷是改善客户和业务之间的交付价值，而不是下降成本，加强自动化，或驱动组织架构；这意味着不一样的组织可能须要不一样的团队结构才能进行有效的 Dev（开发）和 Ops（运维）协做。编程

因此关于问题 ”什么是能够帮助 DevOps 发展的正确组织架构？“是没有一个明确答案的。很显然，没有一种神奇的团队结构能够适用于任何组织。服务器

不过，确实有少许的团队结构模型对某些组织来讲具备必定的参考价值。经过探索这些团队结构的优缺点，同时考虑到康威定律的状况下，或许能够肯定最适合咱们组织的、并有利于 DevOps 实践的团队结构。架构

不少 DevOps 团队结构以前已经被介绍过了，特别是 CollabNet 的 Lawrence Sweeney 在 Ben Kepes 的博客评论中详细介绍了我将在本文说起的 Anti-Type B（独立的 DevOps 谷仓：DevOps Silo）、Type 3（基础设施服务：IaaS）和 Type 1（开发运维共同协做：Smooth Integration）。负载均衡

DevOpsGuys 列出了十二个 DevOps 反类型，Jez Humble、Gene Kim、Damon Edwards（以及其余许多人）也说过相似的事情。在这里我增长三个额外的团队结构，关于这三种类型我以前不多见过或听过人说起：全嵌入式/共享运维（Fully Embedded），DevOps 即服务（DevOps-as-a-Service），和临时 DevOps 团队（Temporary DevOps Team）。运维

DevOps Anti-Types

首先，看待事物的一个有效方式是去观察它很差的一面，这种方式咱们称之为“反类型”（在广泛存在的“反模式”以后）。工具

Anti-Type A：独立谷仓/Dev 和 Ops 分离

这是一种传统的分裂了 Dev 和 Ops 的“抛过墙法”。这意味着 story point（需求点）能够被提早估算（“DONE”意味着功能完整，可是不意味着能够在生产中使用），同时软件的可运维性受损，由于 Devs （开发人员）没有足够的上下文环境去了解功能操做，Ops （运维人员）也没有时间或倾向参与到 Devs 中去共同解决软件上线前的问题。测试

咱们可能都知道这种类型很糟糕，但我认为不少的团队结构实际上更糟糕；至少到目前为止，咱们已经意识到这个反类型 A 的问题所在了。编码

Anti-Type B：独立的 DevOps 谷仓

这种独立的 DevOps 团队一般状况下来自经理或执行官，他们“须要一点 DevOps 的事情”，而后就启动了一个“DevOps 团队”（也有可能有一我的的名字叫作 “DevOp”）。这个 DevOps 的成员会迅速造成另外一个团体，让 Dev 和 Ops 分得更开，由于他们要从“无知的 Devs”和“恐龙同样的 Ops”手里保卫本身的角色、技能和工具集。spa

惟一一个让这种模式能够被理解的状况就是当团队组织为临时的、时间短于十二或十八个月的时候。其目的是让开发人员和运营人员更紧密地联系在一块儿，并明确受权在这段时间以后，这个团队将变得多余。.net

这就成为了我所称的 Type 5 DevOps Topology（见下文）。

Anti-Type C：“咱们（开发）不须要 Ops（运维）”

这种团队结构是由开发人员和开发经理的幼稚自大结合而来的，特别是当一些新项目启动的时候。假设 Ops 如今已经成为了过去式 （“咱们如今有云了，对吧？），开发人员严重低估运维技能和活动的复杂性及重要性，认为没有这些技能和活动他们仍能够作到，或者只要花费一些空余时间就能够。

当他们的软件变得更复杂，更多的运维活动开始淹没“开发”（即编程）的时候，这种 Anti-Type C 的类型可能最终会须要 Type 3（IaaS）或者 Type 4 DevOps topology（DevOps-as-a-Service）。

只要这样的团队能认识到运维做为一个规则的重要性和软件开发同样重要和有价值时，他们将可以避免许多痛苦和没必要要的（以及很是基本的）错误。

DevOps 团队结构

在已经了解了反类型的糟糕以后，咱们能够看一些 DevOps 良好运做的团队结构。

类型一：开发运维顺畅协做

这是 DevOps 的“乐土”：开发团队和运营团队之间顺畅协做，每个团队都在须要的地方专业化工做，但也在须要的地方共享。

可能有许多独立的开发团队，但每一个团队又会在一个单独或半独立的产品组合上工做。个人感受是，类型一的平滑协做模型须要至关大的组织变革来创建它，而且在管理团队须要有较高的能力。

开发人员和运维人员必须有一个明确有效的共同目标（“高质量交付、快速迭代”或其余）。运维人员必须与开发人员进行温馨的合做，掌握测试驱动的编码和 Git，开发人员必须认真对待运维特性，寻找运维人员以输入日志记录等等，全部这些相比较过去都须要进行至关大的文化变革。

类型一适用性：具备强大技术领导类型的组织
潜在有效性：高

类型二：全嵌入式/共享运维

当运维人员彻底融入进产品开发团队中的时候，咱们看到了这种类型。Dev 和 Ops 之间的分离不多，以致于全部人都共同高度关注一个目标，这能够说是类型一的一种形式，不过它也具备必定特殊性。像 Netflix 和 Facebook 这样的组织有效地实现了一个基于 Web 的产品，它已经实现了这种类型的结构。

但我认为它可能不太适用于狭窄产品线模式以外，由于预算限制和多个产品线之间一般存在上下文切换，这可能会迫使 Dev 和 Ops 进一步分开（例如回到类型一模型）。这个模式也能够被称为“NoOps”，由于没有明显的或可见的运维团队（尽管 Netflix NoOps 也多是类型三）。

类型二适用性：基于单一 Web 的产品或服务的组织
潜在有效性：高

类型三：基础设施即服务

对于具备至关传统的 IT 运维部门的组织，他们没法或不能（足够）快速做出改变，和对于在公共云（Amazon EC二、Rackspace、Azure 等）中运行全部应用程序的组织来讲，将运维做为一个只需提供应用程序部署和运行功能的弹性基础设施团队或许比较有帮助。这样内部运维团队直接等同于 Amazon EC2 或基础架构即服务。而后 Dev 中的团队（多是虚拟团队）充当有关操做特性、度量、监控、服务器供应等方面的专业知识来源，而且可能与 Iaas 团队进行大部分沟通。

然而这个团队仍然是一个开发团队，遵循诸如 TDD、CI、迭代开发、指导等标准实践。IaaS 团队结构具备一些潜在的有效性（失去与 Ops 人员直接协做），以便更容易实施，可能比类型一更快地得到价值。

类型三适用性：具备几种不一样产品和服务、具备传统运营部门或其应用程序彻底在公共云中运行的组织
潜在有效性：中等

类型四：DevOps 即服务

一些组织，特别是较小的组织，可能没有资金、经验或工做人员来领导他们的软件运维。开发团队可能会接触到像 Rackspace 这样的服务提供商，去帮助他们创建测试环境并自动化其基础设施和监控，并就软件开发周期中实现的各类运维功能提供建议。

能够被称之为 DevOps-as-a-Service 的应该是帮助小型团队了解自动化、监控和配置管理的一种有效务实的方法。随着业务的发展和更多的员工加入，可能转向第三类甚至第一类模式。

类型四适应性：运营经验有限的小型团队或组织
有效潜力：中

类型五：临时 DevOps 团队

这个类型看起来和反类型 B 有极大的类似，可是实际上其本质意图和长远性是彻底不一样的。这个临时团队的任务是使 Dev 和 Ops 更紧密的联合在一块儿，理想目标是彻底转型成类型一或二。临时团队成员将在 Dev-speak 和 Ops-speak 之间进行翻译，并引入一些疯狂的点子，例如为 Ops 团队介绍站立会和看板系统，还有一些吹毛求疵的细节，例如为 Dev 团队介绍负载均衡器，管理 NIC 和卸载 SSL。

若是有足够多的人意识到 Dev 和 Ops 团队结合后将带来的价值，临时团队将有机会真正的实现它的目标。相当重要的一点是，对部署和生产分析的长期责任不该该被分配给临时团队，不然极可能会朝着反类型 B 的不利方向演进。

类型五适应性：想达成类型一的前身，可是要警戒演变成反类型 B 的可能
有效潜力：低至中

总结

究竟哪一个 DevOps 团队结构适合一个组织取决于如下几点：

1. 该组织的产品组合：较少的产品会使团队协做更加容易，由于根据 Conway 定律，这种状况下的独立谷仓会比较少。
2. 技术领导的范围力度和有效性；Dev 和 Ops 是否有清晰明确的共同目标。
3. 组织是否具备能力或欲望去该改变它的 IT 运维部门，从“服务器的组建和配置”转变成真的能够实现其价值流，以及软件研发团队认真对待运维团队。
4. 组织是否具备能力和技能去解决运维问题。

固然，这里描述的主题有所不一样，团队结构和类型做为参考指南或启发，或许能够对评估哪种模式是适合的带来一些帮助。实际上，将多种模式结合，或将两种模式构成转变和递进的结构模式，每每能达到更好的效果。

活动预告

7 月 21 日本周日，CODING、腾讯云、腾讯 TEG 技术工程事业群将共同举办首届腾讯运维技术开放日 活动，旨在分享和交流腾讯内部在运维方面的实践经验，打造腾讯内部与外部共同交流、共同进步的运维技术生态。

CODING 深耕 DevOps 市场，除腾讯外，也为富士康、拉卡拉、国泰基金、天津大学等组织提供 DevOps 工具服务。CODING 创始人张海龙受邀参加本次活动，将与你们分享协助客户进行 DevOps 转型的经验，以及在 DevOps 的大趋势下开发与运维的新关系。

点击此处报名活动
7 月 21 日期待你们的到来！