什么样的团队结构才能适应 DevOps 的蓬勃发展？

引言

组织中发起任何 DevOps 相关活动的首要目的是改善对客户和业务的价值交付，而不是降低成本，提升自动化程度，或者从配置管理中驱动任何事情；这意味着不同的组织可能需要不同的团队结构才能开展有效的开发和运维协作。

提要

哪些 DevOps 团队结构或拓扑适合组织取决于几件事情：

• 该组织的产品组合：较少的产品使得协作更加容易，因为根据康威定律，这种情况下各自独立的小团队较少。
• 技术领导力的范围，力度和有效性；Dev 和 Ops 是否有共同的目标。
• 一个组织是否具有将IT运维部门从“硬件机架”和“配置服务器”改变为与价值流实际一致的需求或能力，以及软件研发团队是否认真对待来自运维方面的要求。
• 该组织是否具备带头解决当前运维问题的能力或技能。

当然，这里描述的主题有所不同；拓扑和类型是作为参考指南或启发，协助您来评估哪些模式可能是适合的。实际上，将多种模式或一种模式转化为另一种模式的组合往往是最好的方法。

那么 DevOps 的团队结构如何发展呢？ 显然，没有任何适合每个组织的理想结构或团队拓扑。然而，对于团队结构来说，参考少数不同的模型是有用的，其中一些模型与某些组织的适合度更高。通过探索这些团队结构（或“拓扑”）的优缺点，考虑到康威定律，我们可以确定可能对我们自己组织中 DevOps 做法最有效的团队结构。

这些 DevOps 拓扑中的大多数已经在其他地方描述过；特别是 CollabNet 的Lawrence Sweeney 在对 Ben Kepes 博客的评论中谈到了有关我在这里所描述的反类型B（独立的 DevOps 团队）， 类型3（运维作为基础设施服务）以及类型1（开发和运维协作）。DevOpsGuys 列出了十二个 DevOps 反模式，Jez Humble，Gene Kim，Damon Edwards（以及许多其他人）也曾经说过类似的事情。我在这里添加了三个额外的“拓扑”，我没有看到或听到于此相关的一些讨论（共享运维，DevOps-as-a-Service 和临时 DevOps团队）。

DevOps 反类型

看看一些不好的做法，我们可以称之为“反类型”（在无处不在的“反模式”普及之后的说法）是有用的。 A: Dev 和 Ops 分离 B: 单独的 DevOps 团队 C: 开发不需要运维 D: 工具团队 E: 系统管理员 F: 开发包含运维 G: 开发和 DBA 分离

反类型 A：Dev 和 Ops 分离

这是经典的“扔过墙去”式的 Dev 和 Ops 分离。这意味着需求点可以在前期被提取出来（DONE意味着“功能完整”，但不能在生产中使用），并且软件的可运维性受到损害，因为开发者没有运维相关的上下文信息，运维人员没有时间或者动力参与到开发者中，在软件上线之前解决问题。

我们都知道这种拓扑类型不好，但我认为有很多相似的拓扑结构很差；至少我们清楚反类型A（开发和运维分离）是一个问题。

反类型B：单独的 DevOps 团队

单独的 DevOps 团队（反类型B）通常来自经理或执行官，决定他们“需要一点这个 DevOps 的事情”，并启动一个“DevOps 团队”（可能是被称为“DevOp”的人）。DevOps 团队的成员迅速形成另一个团体，使 Dev 和 Ops 比以往任何时候都更加分开，因为他们需要捍卫自己的角色，技能和工具集，防止自己被“无知的 Devs”和“恐龙般的Ops”所消灭。

单独的 DevOps 团队真的有意义的唯一的情况是，当团队是暂时的，例如持续时间少于12或18个月，其明确目的是使 Dev 和 Ops 更紧密地结合在一起，并被明确地授权的时候，当这段时间过去，这个团队是多余的。这就是我所说的类型5 DevOps 拓扑。

反类型C：开发不需要运维

这种拓扑结构由开发人员和开发经理之间的天真和傲慢相结合，特别是在新项目或系统开始时。假设 Ops 现在是过时的事情（“我们现在有了Cloud，对吗？”），开发人员大大低估了运维技能和活动的复杂性和重要性，并认为他们可以不需要运维，或者在闲暇时间就可以搞定运维做的事情。

这种反类型C DevOps 拓扑可能最终需要Type 3（Ops as IaaS）或Type 4（DevOps-as-a-Service）拓扑，当他们的软件变得更加深入和复杂，运维开始需要开发工作“（又称编码）”的时候。如果这样的团队认识到运维作为一个重要和有价值的学科，并且认可其对于软件开发的重要性，他们将能够避免许多痛苦和不必要的（和相当基本的）运维错误。

反类型D：DevOps 作为工具团队

在不影响当前开发团队的速度（实现用户故事）的情况下，成立一个DevOps团队，负责部署管道，配置管理，环境管理等所需的工具。同时，Ops 的人们继续孤立工作，Dev 团队继续将他们的应用程序“放在墙上”。

虽然这个专门团队的成果在改进的工具链方面可能是有益的，但其影响是有限的。在应用程序开发生命周期中缺乏早期运维的参与和协作，根本问题依然存在。

反类型E：变相的 SysAdmin

这种反类型在工程成熟度低的组织中是典型的。他们希望改善他们的做法并降低成本，但是他们不能将IT视为业务的核心驱动力。因为 DevOps 的行业成功现在显而易见，他们也想“做 DevOps”。不幸的是，他们并没有反思目前的结构和关系的差距，而是为其 Ops 团队聘请了“DevOps 工程师”。

DevOps 只是一个名为 SysAdmin 的角色的重塑，没有真正的文化/组织变化发生。这种反类型越来越广泛，因为庸碌的招聘人员只是寻找具有自动化和工具技能的候选人。不幸的是，人际沟通技巧才能真正使 DevOps 在组织中茁壮成长。

反类型F：运维嵌入开发团队

该组织不希望独立的运维团队，所以开发团队负责基础设施，管理环境，监控等。但是，这样以项目或产品驱动的方式，意味着这些项目受到资源限制，优先次序导致了较差的运作方式和半成品的解决方案。

在这种反类型方面，该组织对于有效的IT运维所需的重要性和技能缺乏认识。

反类型G：Dev 和 DBA 隔离

这是一种在中型到大型公司中突出的反类型A（开发和运维分离）的形式，其中多个遗留系统依赖于相同的核心数据集。由于这些数据库对于业务至关重要，因此经常在业务范围内的专门的 DBA 团队负责维护，性能调整和灾难恢复。这是可以理解的，但问题是当这个团队成为任何数据库变更的门户时，有效成为小型和频繁部署（DevOps 和持续交付的核心宗旨）的障碍。

此外，就像在反类型A中的运维一样，DBA 团队在应用开发早期也没有涉及，因此数据问题（迁移，性能等）在交付周期的后期被发现。加上支持多个应用数据库的过载，最终的结果是面临持续的“救火”和部署压力。

DevOps 团队拓扑

站在反类型的对面，我们看一些适合 DevOps 的拓扑。

1: 开发和运维协作 2: 共享运维 3: 运维作为基础设施服务 4: DevOps-as-a-Service 5: 临时 DevOps 团队 6: DevOps 布道者团队 7: SRE 团队 8: 容器驱动 9: 数据库能力

类型1：开发和与运维协作

这是 DevOps 的“乐土”：开发团队和运营团队之间的顺利协作，每个专业都在需要的地方，但也需要分享。可能有许多独立的开发团队，每个工作在一个单独的或半独立的产品堆栈。

我的意思是，这种1型模型需要相当大的组织变革才能建立起来，在技术管理团队中具有较高的竞争力。开发者和运维部门必须有明确的表达和鲜明合理的共同目标（“高质量交付，拥抱变化”或其他）。运维人员必须与 Devs 配对，掌握测试驱动的编码技能和 Git 工具，并且开发必须认真对待运维特性方面的要求，并寻找运维人员加入日志实现。从目前状况到这个状态，所有这些都需要相当的文化变革。

类型1适应性：一个技术驱动型的组织。 有效潜力：高

类型2：完全共享运维责任

在运维人员已经集成到产品开发团队中的情况下，我们看到了类型2拓扑。Dev 和 Ops 之间的分离很少，所有人都高度重视共同的目标；这是一种形式的类型1（开发和运维协作），但它有一些特殊的功能。

Netflix 和 Facebook 等组织有效实现了一种基于 Web 的产品，已经实现了这种2型拓扑结构，但是我认为在单纯的产品角度之外来看，它可能不是非常适用的，因为预算限制和多个产品线之间通常存在上下文切换，这可能会迫使 Dev 和 Ops 进一步分开（例如，回到类型1模型）。这个拓扑也可能被称为“NoOps”，因为没有明显的或可见的运维团队（尽管 Netflix NoOps 也可能是类型 3（作为IaaS的Ops））。

类型2适应性：组织只有一个简单的基于 web 的产品或服务。 有效潜力：高

类型3：运维作为基础设施服务

对于 IT 运维部门非常传统的组织，不会或者不能（足够）快地速拥抱变化，对于在公共云（Amazon EC2，Rackspace，Azure等）中运行所有应用程序的组织，它可能将运维作为一个只需提供应用程序部署和运行功能的弹性基础设施团队。因此，内部运维团队直接等同于 Amazon EC2或基础架构即服务。

Dev 内部的一个团队（或许是一个虚拟团队）将作为运维特性、指标、监控、服务器配置等方面的专业知识来源，并且可能与 IaaS 团队进行大部分的沟通。然而，这个团队仍然是一个开发团队，遵循TDD，CI，迭代开发，人员指导等标准实践。

IaaS 拓扑结构具有一些潜在的有效性（与 Ops 人员直接协作），以便更容易实施，可能比通过尝试稍后尝试的类型1（开发和运营协作）更快地获得价值。

类型3适应性：具有多种不同产品和服务，传统的运维部门，或其应用程序完全在公有云中运行的组织。 有效潜力：中

类型4：DevOps 作为外部服务

一些组织，特别是较小的组织可能没有资金，经验或工作人员来主导他们的软件运维。开发团队可能会接触到像 Rackspace 这样的服务提供商，以帮助他们建立测试环境并自动化其基础设施和监控，并就软件开发周期中实现的各种运维功能提供建议。可以称之为 DevOps-as-a-Serviced 的可能是小型组织或团队，他们了解自动化，监控和配置管理的用途和实现方式，然后随着业务的发展和更多的员工，可能转向第3类（作为 IaaS 的操作）或甚至第一类（开发和运维协作）模式。

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

类型5：具有到期日的 DevOps 团队

具有到期日的 DevOps 团队（类型5）看起来像反类型B（DevOps Team Silo），但其意图和寿命是完全不同的。这个临时团队的任务是使Dev和Ops更紧密地结合在一起，理想目标是面向类型1（开发和运营协作）或类型2（完全共享的 Ops Reponsibility）模型，并最终使其自身过时。临时小组的成员将在 Dev-speak 和 Ops-talk 之间进行“翻译”，引入疯狂的想法，如为 Ops 团队引入站立会和看板，并考虑“肮脏”的细节，如负载均衡器，管理 NIC 和为 Dev 团队卸载 SSL。如果足够多的人开始看到将 Dev 和 Ops 组合在一起的价值，那么临时团队就有实现其目标的真正机会；至关重要的是，部署和生产环境的长期分析诊断责任不应该提供给临时团队，否则可能会成为 DevOps 团队隔离（反类型B）。

类型5适应性：运营经验较小的小型团队或组织。 有效潜力：低至中

类型6：DevOps“布道者”团队

在 Dev 与 Ops 之间存在巨大差距（或者大的差距趋势）的组织中，拥有一个“促进”DevOps 团队来保持 Dev 和 Ops 方面的交流是有效的。这是一个类型5（DevOps Team with Expirey Date）的版本，但 DevOps 团队在持续的基础上存在着具体的促进 Dev 与 Ops 团队之间的协作与合作的职责。这个团队的成员有时被称为“DevOps 布道者”，因为它们有助于传播 DevOps 实践的意识。

“DevOps团队”的目标应该是通过启用组织的其余部分来实现自己的业务。— Twitter: EricMinick

类型6适应性：Dev 和 Ops 趋势分散的组织。小心类型B的危险。 有效潜力：中至高

类型7：SRE团队（Google模型）

DevOps 经常建议 Dev 团队定期参加值班会议，但这不是必须的。事实上，一些组织（包括 Google）运行不同的模式，从开发到运行该软件的团队（站点可靠性工程（SRE））团队的明确“切换”。在这个模型中，开发团队需要向 SRE 团队提供测试证据（日志，指标等），表明他们的软件具有足够的标准，得到SRE团队的支持。

最重要的是，SRE 团队可以拒绝在运维上不合标准的软件，要求开发人员在将代码投入生产之前对其进行改进。Dev 和 SRE 之间的协作发生在运维标准上，但是一旦 SRE 团队对代码感到满意，他们（而不是开发团队）就在生产中支持它。

类型7适应性：类型7仅适用于具有高度工程和组织成熟度的组织。如果SRE/Ops 团队被告知“JFDI”部署，请小心返回反类型A。 有效潜力：低至高

类型8：容器驱动的协作

通过将应用程序的部署和运行时需求封装到容器中，容器不再需要 Dev 和 Ops 之间的某些协作。这样，容器就是开发和运维的责任界限。凭借良好的工程文化，容器驱动的协作模式运作良好，但如果开发者开始忽视运维需要考虑的一些事情，这种模式可以转变为对抗“我们与他们”。

类型8适应性：容器可以工作得很好，但要注意反类型A，Ops 团队预计会运行Dev 发出的任何内容。 有效潜力：中至高

类型9：开发和 DBA 协作

为了弥合 Dev-DBA 的鸿沟，一些组织已经尝试过类似于类型9的数据库功能，DBA 团队的数据库功能与 Dev 团队的数据库功能（或专业）相称。这似乎有助于在以开发为中心的数据库（以本质上是应用程序的虚拟持久存储）视图和 DBA 为中心的数据库（智能，丰富的业务价值来源）视图之间进行转换。

类型9适应性：适用于具有多个应用程序连接一个或多个大型中央数据库的组织。 有效潜力：中

请记住：任何一个组织都没有“正确的”团队拓扑，但是有几个“坏”拓扑。

原文链接：http://web.devopstopologies.com/

END