云享专家姚冬：9种DevOps团队结构适用类型与7种反型

本文翻译自：https://web.devopstopologies.com/

译者：云享专家姚冬

前 言

什么样的团队结构适合DevOps蓬勃发展?

在一个组织内DevOps工作的主要目标是改善客户和业务的价值交付，而不是为了降低成本、提高自动化或驱动配置管理;这意味着不同的组织可能需要不同的团队结构才能进行有效的Dev和Ops协作。

总 结

究竟组织适合采取哪种DevOps团队结构或拓扑取决于以下几点：

组织的产品组合：更少的产品使得协作更容易，因为康威定律所预测的天然筒仓会更少。

技术领导的范围，力量和有效性，决定了Dev和Ops是否拥有共同的目标。

组织是否具备能力或兴趣，将IT运维部门的功能从“上架硬件”和“配置服务器”，变为真正与价值流保持一致，并且软件研发团队认真对待运维功能。

组织是否有能力或技能投入在运维所关心的问题上。

当然，下文列出了多种拓扑和类型，可以作为评估哪些模式可能适合的参考指南或启示。实际上，超过一种模式的组合，或是从一种模式转换为另一种模式是通常被采用的方式。

那么可以让DevOps蓬勃发展的团队结构是什么?显然，没有针对所有组织的普适的神奇结构或团队拓扑。但是，列出少数不同的团队结构模型是有用的，其中一些模型比起其他模型来说更适合于某些组织。通过探索这些团队结构(或“拓扑”)的优点和缺点，我们可以在康威定律下，确定可能最适合我们自己组织DevOps实践的团队结构。

大多数的DevOps拓扑结构之前已在其他地方描述过;特别是，CollabNet的Lawrence Sweeney在Ben Kepes的博客评论中详细介绍了我在这里称为Anti-Type B(DevOps Team Silo)，Type 3(Ops as IaaS)和Type 1(Dev and Ops Collaboration)的特征。)。DevOpsGuys列出了十二个DevOps反模式，Jez Humble，Gene Kim，Damon Edwards(以及其他许多人)都说过类似的事情。我在这里添加了三个额外的'拓扑'，在别处没有看到或很少听到讨论(Shared Ops，DevOps-as-a-Service和Temp DevOps Team)。

DevOps Anti-Types

我们先来看一些不好的做法，称之为“反类型”(模仿无处不在的“反模式”)。

A：Dev vs Ops 对立

B：DevOps Silo筒仓

C：不需要Ops

D：DevOps工具团队

E：SysAdmin 系统管理员

F：嵌入式Ops

G：Dev vs DBA

反型A：Dev和Ops筒仓

这是Dev和Ops之间的经典“扔过墙”模式。这意味着可以提前声明故事点(DONE表示“功能完成”，但没有在生产环境中运行)，软件可运维性受到影响，因为Dev人员没有足够的运维工作上下文，而Ops人员没有时间或倾向于拉开发人员在软件上线之前解决问题。

我们可能都知道这种拓扑很糟糕，但我认为实际上存在更糟糕的拓扑; 至少，在使用Anti-Type A(Dev和Ops Silos)，我们都知道存在问题(而某些拓扑我们并不知道有问题)。

反型B：DevOps Team Silo 筒仓

DevOps Team Silo(Anti-Type B)通常来自于主管决定他们“需要一些这样的DevOps事情”，并启动了一个'DevOps团队'(可能包含所谓的'DevOp'人员)。DevOps团队的成员很快形成了另一个孤岛，让Dev和Ops比以往任何时候都更加分离，因为DevOps团队要捍卫他们的角落：技能和工具集(对比那些“无能为力的Dev”和“恐龙Ops”)。

DevOps孤岛模式唯一有意义的情况：DevOps团队是临时的，持续时间少于(比如说)12或18个月，明确定义目的是让Dev和Ops更紧密地联系在一起，并明确要求在此之后解散DevOps团队。(这就是我后面要说的Type 5 DevOps Topology。)

反型C：Dev不需要Ops

这种拓扑结构因开发人员和开发经理的天真和傲慢而产生，特别是在新项目或系统开始时。开发人员假设Ops现在已成为过去(“我们现在拥有云，对吗?”)，这大大低估了运维技能和活动的复杂性和重要性，并相信可以不使用它们，或只需要在闲暇时间来处理。

这样的Anti-Type C DevOps拓扑结构可能最终需要Type 3(Ops as IaaS)或Type 4(DevOps-as-a-Service)拓扑，当他们的软件变得更加复杂并且运维活动开始淹没开发(又名编码)时间。如果只有这样的团队才能认识到运维作为一门学科的重要性，就像软件开发一样的重要和有价值，他们就能避免很多痛苦和不必要的(而且非常基本的)运维错误。

反型D：DevOps作为工具团队

为了“成为DevOps”同时又不失去当前开发团队的速度(交付功能故事)，DevOps团队被设置为处理部署流水线，配置管理，环境管理等所需的工具。同时Ops的人继续孤立地工作，开发团队继续将他们的应用程序“抛过墙去”。

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

反型E：更名的SysAdmin

这种反型在工程成熟度较低的组织中很常见。他们希望改善自身实践并降低成本，但却未能将IT视为业务的核心驱动力。由于DevOps在行业有众多的成功案例，他们也希望“做DevOps”。不幸的是，他们没有反思当前组织结构和关系中的差距，而是选择了为他们的Ops团队招聘“DevOps工程师”这一前途未卜的道路。

DevOps只是对以前称为SysAdmin的角色的重塑，没有发生真正的文化/组织变化。随着肆无忌惮的招聘人员开始寻找具有自动化和工具技能的候选人，这种反型正变得越来越普遍。不幸的是，只有人类的沟通技巧才可以使DevOps在组织中茁壮成长。

反型F：开发团队中嵌入的Ops

组织不希望保留单独的Ops团队，因此开发团队负责基础设施，管理环境，监控等。但是，以项目或产品驱动的方式这样做意味着这些项目受资源限制以及优先级排序，导致非标准的方式和半生不熟的解决方案。

在这种反类型中，组织表现出对IT运维的重要性和技能缺乏认识。特别是，Ops的价值减少了，因为它被视为Devs的烦恼(因为Ops由一个开发团队经理管理，他同时又有其他优先事项)。

感谢Scott Prugh建议澄清Anti-Type F与Type 2的区别。

反型G：Dev和DBA筒仓

这是Anti-Type A(开发和Ops孤岛)的一种形式，在中型到大型公司中很突出，其中多个遗留系统依赖于相同的核心数据集。由于这些数据库对业务至关重要，因此有专门的DBA团队(通常在Ops保护伞下)负责维护，性能调整和灾难恢复。这是可以理解的。但问题是当这个团队成为任何数据库变更的守门员时，“有效地”成为了小的并且频繁部署的障碍(DevOps和持续交付的核心原则)。

此外，就像Anti-Type A中的 Ops一样，DBA团队并未参与应用程序开发的早期阶段，因此在交付周期的后期会发现数据问题(迁移，性能等)。再加上支持多个应用程序数据库的过载，最终结果是持续的灭火和交付压力。

DevOps团队的拓扑

与反类型不同，我们可以看一些可以使DevOps工作的拓扑。

1：Dev + Ops

2：共享的Ops

3：Ops作为IaaS

4：DevOps-as-a-Service

5：临时的DevOps团队

6：DevOps倡导者

7：SRE团队

8：容器驱动

9：数据库能力

类型1：开发和运维协作

这是DevOps的“应允之地”：开发团队和Ops团队之间顺畅合作，每个团队各司其职，但也需要彼此分享。可能有许多独立的开发团队，每个团队都在独立或半独立的产品技术栈上工作。

我的感觉是，这种类型1模型需要相当大的组织变革来建立，并且对技术管理团队有更高的要求。Dev和Ops必须有明确表达并且有效的共同目标(例如“提供可靠，频繁的变化”)。运维人员必须与Devs结对，并掌握测试驱动的开发和Git，Devs必须认真对待运维能力，并寻找Ops人员进行日志记录等，所有这些都需要相当的文化变革。

第1类适用性：具有强大技术领导力的组织。

潜在效果：HIGH

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

如果运维人员已集成到产品开发团队中，我们会看到Type 2拓扑。Dev和Ops之间的分别很小，所有人都高度专注于共同的目的; 这可以说是Type 1(Dev和Ops Collaboration)的一种形式，但它有一些特殊的特征。

Netflix和Facebook这样的组织，事实上只有一个基于Web的核心产品，已经实现了这种类型2拓扑，但我认为它可能不适用于聚焦的产品之外，因为在具有多个产品流的组织中，通常存在预算限制和上下文切换，可能会使Dev和Ops进一步分开(例如，回到Type 1模型)。此拓扑也可称为“NoOps”，因为没有明显或可见的运维团队(尽管Netflix NoOps也可能是Type 3(Ops as IaaS))。

类型2适用性：具有单个基于Web的主要产品或服务的组织。

潜在效果：HIGH

类型3： Ops作为基础设施即服务(平台)

对于拥有相对传统的IT运维部门的组织，无法或不会(足够)快速变更;对于在公共云(Amazon EC2，Rackspace，Azure等)中运行所有应用程序的组织，它可能有助于将运维作为一个只提供部署和运行应用程序的弹性基础架构的团队; 因此，内部Ops团队等同于Amazon EC2或Infrastructure-as-a-Service。

Dev中的团队(可能是虚拟团队)可以充当关于运维的功能，指标，监控，服务器配置等的专业知识来源，并且可能与IaaS团队进行大部分的沟通。然而，该团队仍然是开发团队，遵循TDD，CI，迭代开发，教练等标准实践。

这种IaaS拓扑以一些潜在的有效性为代价(失去了与Ops人员的直接协作)，来换取更容易的实现，可能比尝试Type 1(Dev和Ops Collaboration)能够更快地获得价值，Type 1可以在未来进行尝试。

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

潜在的有效性：MEDIUM

类型4： DevOps作为外部服务

一些组织，特别是较小的组织，可能没有财力，经验或工作人员来领导所生产软件的运维部分。开发团队可以联系Rackspace等服务提供商，帮助他们构建测试环境并自动化他们的基础设施和监控，并就软件开发周期中要实施的各种运维能力提供建议。

这种被称为DevOps-as-a-Service的方式，对于小型组织或团队来说可能是一种有用且实用的方式，可以了解自动化，监控和配置管理，然后随着他们的发展和增长，需要更多的员工关注于运维，可能转向类型3(Ops as IaaS)甚至 类型1(开发和Ops协作)。

第4类适用性：较小的团队或运维经验有限的组织。

潜在的有效性：MEDIUM

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

具有到期日(类型5)的DevOps团队看起来与Anti-Type B(DevOps Team Silo)非常相似，但其意图和寿命却截然不同。这个临时团队的使命是将Dev和Ops更紧密地结合在一起，理想情况下是向Type 1(开发和Ops协作)或Type 2(完全共享的Ops职责)演进，并最终使其自身被废弃。

临时团队的成员将在Dev-语言和Ops-语言之间进行“翻译”，为Ops团队引入疯狂的想法，如站会和看板，以及考虑诸如引入负载均衡器，管理NIC和开发人员SSL卸载等脏活累活。如果有足够多的人开始看到将Dev和Ops结合在一起的价值，那么临时团队就有可能实现其目标;至关重要的是，不应该要求临时团队承担部署和生产诊断等长期责任，否则很可能成为DevOps Team Silo(Anti-Type B)。

5型适用性：作为1型拓扑结构的前身，但要注意抗B型的危险性。

潜在有效性：从 低到高

类型6：DevOps倡导团队

在Dev和Ops之间存在巨大隔阂的组织中，拥有一个“引导”DevOps团队可以有效地保持Dev和Ops之间的沟通。这是Type 5(具有到期日的DevOps团队)的一种版本，但DevOps团队持续存在，承担促进Dev和Ops团队之间协作和合作的特定职责。该团队的成员有时被称为“DevOps Advocates”，因为他们帮助进行DevOps实践意识的传播。

“DevOps团队”的目标应该是通过赋能组织的其余部分来使自己消失。

感谢Eric Minick(@EricMinick)

6型适用性： 倾向于Dev和Ops分开的组织。注意反型B的危险性。

潜在的有效性： 中等至高

类型7：SRE团队(Google模型)

DevOps经常建议Dev团队加入on call轮换，但这并非必须。实际上，一些组织(包括谷歌)拥有不同的模型，从开发到运行软件的团队(即站点可靠性工程(SRE)团队)有明确地“交接”。在此模型中，开发团队需要向SRE团队提供测试证据(日志，指标等)，以证明他们的软件达到足够好的标准以供SRE团队来支持。

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

感谢Kevin Hinde (@kwdhinde)

类型7适用性：类型7仅适用于具有高度工程和组织成熟度的组织。如果SRE / Ops团队被告知“JFDI”部署，请警惕Anti-Type A.

潜在有效性：从 低到高

类型8：容器驱动的协作

通过将应用程序的部署和运行时要求封装到容器中，消除了Dev和Ops之间某些的协作需要。在这种方式中，容器充当了Dev和Ops职责的边界。凭借良好的工程文化，容器驱动的协作模型可以运行良好，但如果Dev开始忽略运维需要考虑的因素，这个模型会回归到 '我们和他们'。

感谢J Buchanan (@jascbu)

类型8适用性：容器可以很好地工作，但要注意反型A：Ops团队应该运行Dev抛出的任何东西。

潜在的有效性： 中等至高

类型9：开发和DBA协作

为了弥合Dev-DBA的鸿沟，一些组织开始尝试类型9，其中来自DBA团队的数据库能力与Dev团队的数据库能力(或专业)相匹配。这似乎有助于在以Dev为中心的数据库视角(基本上是应用程序的哑持久性存储)和以DBA为中心的数据库视角(智能，丰富的业务价值来源)之间进行翻译。

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

潜在的有效性：MEDIUM

请记住：没有“正确”的团队拓扑结构，但对于任何一个组织而言，都有一些“不良”的拓扑结构。