原文链接： https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
原作者：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 ）。
首先，看待事物的一个有效方式是去观察它不好的一面，这种方式我们称之为“反类型”（在普遍存在的“反模式”之后）。
这是一种传统的分裂了 Dev 和 Ops 的“抛过墙法”。这意味着 story point （需求点）可以被提前估算（“ DONE ”意味着功能完整，但是不意味着可以在生产中使用），同时软件的可运维性受损，因为 Devs （开发人员）没有足够的上下文环境去了解功能操作，Ops （运维人员）也没有时间或倾向参与到 Devs 中去共同解决软件上线前的问题。
我们可能都知道这种类型很糟糕，但我认为很多的团队结构实际上更糟糕；至少到目前为止，我们已经意识到这个反类型 A 的问题所在了。
这种独立的 DevOps 团队通常情况下来自经理或执行官，他们“需要一点 DevOps 的事情”，然后就启动了一个“ DevOps 团队”（也有可能有一个人的名字叫做 “ DevOp ”）。这个 DevOps 的成员会迅速形成另一个团体，让 Dev 和 Ops 分得更开，因为他们要从“无知的 Devs ”和“恐龙一样的 Ops ”手里保卫自己的角色、技能和工具集。
唯一一个让这种模式可以被理解的情况就是当团队组织为临时的、时间短于十二或十八个月的时候。其目的是让开发人员和运营人员更紧密地联系在一起，并明确授权在这段时间之后，这个团队将变得多余。
这就成为了我所称的 Type 5 DevOps Topology （见下文）。
这种团队结构是由开发人员和开发经理的幼稚自大结合而来的，特别是当一些新项目启动的时候。假设 Ops 现在已经成为了过去式 （“我们现在有云了，对吧？），开发人员严重低估运维技能和活动的复杂性及重要性，认为没有这些技能和活动他们仍可以做到，或者只要花费一些空余时间就可以。
当他们的软件变得更复杂，更多的运维活动开始淹没“开发”（即编程）的时候，这种 Anti-Type C 的类型可能最终会需要 Type 3 （ IaaS ）或者 Type 4 DevOps topology （ DevOps-as-a-Service ）。
只要这样的团队能认识到运维作为一个规则的重要性和软件开发一样重要和有价值时，他们将能够避免许多痛苦和不必要的（以及非常基本的）错误。
在已经了解了反类型的糟糕之后，我们可以看一些 DevOps 良好运作的团队结构。
这是 DevOps 的“乐土”：开发团队和运营团队之间顺畅协作，每一个团队都在需要的地方专业化工作，但也在需要的地方共享。
可能有许多独立的开发团队，但每个团队又会在一个单独或半独立的产品组合上工作。我的感觉是，类型一的平滑协作模型需要相当大的组织变革来建立它，并且在管理团队需要有较高的能力。
开发人员和运维人员必须有一个明确有效的共同目标（“高质量交付、快速迭代”或其他）。运维人员必须与开发人员进行舒适的合作，掌握测试驱动的编码和 Git，开发人员必须认真对待运维特性，寻找运维人员以输入日志记录等等，所有这些相比较过去都需要进行相当大的文化变革。
类型一适用性：具有强大技术领导类型的组织
潜在有效性：高
当运维人员完全融入进产品开发团队中的时候，我们看到了这种类型。Dev 和 Ops 之间的分离很少，以至于所有人都共同高度关注一个目标，这可以说是类型一的一种形式，不过它也具有一定特殊性。像 Netflix 和 Facebook 这样的组织有效地实现了一个基于 Web 的产品，它已经实现了这种类型的结构。
但我认为它可能不太适用于狭窄产品线模式之外，因为预算限制和多个产品线之间通常存在上下文切换，这可能会迫使 Dev 和 Ops 进一步分开（例如回到类型一模型）。这个模式也可以被称为“ NoOps ”，因为没有明显的或可见的运维团队（尽管 Netflix NoOps 也可能是类型三）。
类型二适用性：基于单一 Web 的产品或服务的组织
潜在有效性：高
对于具有相当传统的 IT 运维部门的组织，他们无法或不能（足够）快速作出改变，和对于在公共云（ Amazon EC2、Rackspace、Azure 等）中运行所有应用程序的组织来说，将运维作为一个只需提供应用程序部署和运行功能的弹性基础设施团队或许比较有帮助。这样内部运维团队直接等同于 Amazon EC2 或基础架构即服务。然后 Dev 中的团队（可能是虚拟团队）充当有关操作特性、度量、监控、服务器供应等方面的专业知识来源，并且可能与 Iaas 团队进行大部分沟通。
然而这个团队仍然是一个开发团队，遵循诸如 TDD、CI、迭代开发、指导等标准实践。IaaS 团队结构具有一些潜在的有效性（失去与 Ops 人员直接协作），以便更容易实施，可能比类型一更快地获得价值。
类型三适用性：具有几种不同产品和服务、具有传统运营部门或其应用程序完全在公共云中运行的组织
潜在有效性：中等
一些组织，特别是较小的组织，可能没有资金、经验或工作人员来领导他们的软件运维。开发团队可能会接触到像 Rackspace 这样的服务提供商，去帮助他们建立测试环境并自动化其基础设施和监控，并就软件开发周期中实现的各种运维功能提供建议。
可以被称之为 DevOps-as-a-Service 的应该是帮助小型团队了解自动化、监控和配置管理的一种有效务实的方法。随着业务的发展和更多的员工加入，可能转向第三类甚至第一类模式。
类型四适应性：运营经验有限的小型团队或组织
有效潜力：中
这个类型看起来和反类型 B 有极大的相似，但是实际上其本质意图和长远性是完全不同的。这个临时团队的任务是使 Dev 和 Ops 更紧密的联合在一起，理想目标是完全转型成类型一或二。临时团队成员将在 Dev-speak 和 Ops-speak 之间进行翻译，并引入一些疯狂的点子，例如为 Ops 团队介绍站立会和看板系统，还有一些吹毛求疵的细节，例如为 Dev 团队介绍负载均衡器，管理 NIC 和卸载 SSL。
如果有足够多的人意识到 Dev 和 Ops 团队结合后将带来的价值，临时团队将有机会真正的实现它的目标。至关重要的一点是，对部署和生产分析的长期责任不应该被分配给临时团队，否则很可能会朝着反类型 B 的不利方向演进。
类型五适应性：想达成类型一的前身，但是要警惕演变成反类型 B 的可能
有效潜力：低至中
究竟哪个 DevOps 团队结构适合一个组织取决于以下几点：
当然，这里描述的主题有所不同，团队结构和类型作为参考指南或启发，或许可以对评估哪一种模式是适合的带来一些帮助。实际上，将多种模式结合，或将两种模式构成转变和递进的结构模式，往往能达到更好的效果。
7 月 21 日本周日，CODING、腾讯云、腾讯 TEG 技术工程事业群将共同举办首届腾讯运维技术开放日 活动，旨在分享和交流腾讯内部在运维方面的实践经验，打造腾讯内部与外部共同交流、共同进步的运维技术生态。
CODING 深耕 DevOps 市场，除腾讯外，也为富士康、拉卡拉、国泰基金、天津大学等组织提供 DevOps 工具服务。CODING 创始人张海龙受邀参加本次活动，将与大家分享协助客户进行 DevOps 转型的经验，以及在 DevOps 的大趋势下开发与运维的新关系。
点击此处报名活动
7 月 21 日期待大家的到来！
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.