在大多数团队中，开发和运维之间存在着一系列的冲突和博弈。有人说DevOps的出现让开发和运维不再相爱相杀。从那以后，他们就一直手拉手，愉快地编码和抓bug；但是有人说DevOps是开发吃运维。这是真的吗？不同的团队结构将如何影响DevOps开发？阅读下文，你会有自己的答案。在组织中启动任何与DevOps相关的活动的主要目的是改进对客户和业务的价值交付，而不是降低成本、提高自动化或从配置管理中推动任何事情。这意味着不同的组织可能需要不同的团队结构来进行有效的开发和运营协作。哪种DevOps团队结构或拓扑结构适合组织取决于几个因素：组织的产品组合：更少的产品使协作更容易。因为按照康威定律，这种情况下独立的小团队更少。技术领导的范围、强度和有效性；Dev和Ops是否有共同的目标。组织是否需要或有能力将IT操作从“硬件机架”和“配置服务器”更改为实际与价值流一致的操作，以及软件开发团队是否认真对待来自操作的要求。组织是否有能力或技能带头解决当前的运营问题。当然，这里描述的主题各不相同；拓扑和类型作为参考指南或启发式方法提供，以帮助您评估哪些模式可能是合适的。事实上，多种模式的组合，或者一种模式转换成另一种模式，通常是最好的方法。那么DevOps团队结构是如何演变的呢？显然，没有适用于每个组织的理想结构或团队拓扑。然而，对于团队结构，参考少量不同的模型是有用的，其中一些模型更适合某些组织。通过探索这些团队结构（或“拓扑”）的优势和劣势，我们可以确定可能对我们组织中的DevOps实践最有效的团队结构，同时考虑康威定律。这些DevOps拓扑中的大部分已在其他地方进行了描述；特别是，CollabNet的LawrenceSweeney在BenKepes的博客上评论了我在这里描述的反类型B（独立的DevOps团队）、类型3（作为基础设施服务的运营）和类型1（开发和运营协作）。DevOpsGuys列出了十二种DevOps反模式，JezHumble、GeneKim、DamonEdwards（以及许多其他人）也说过类似的话。我在这里添加了三个额外的“拓扑”，对此我还没有看到或听到一些讨论（共享操作、DevOps-as-a-Service和临时DevOps团队）。DevOpsAntitypes查看一些不好的实践是很有用的，我们可以称之为“antitypes”（在无处不在的“antipatterns”普及之后）。Dev和Ops分离单独的DevOps团队开发不需要运维DevOps作为工具团队系统管理员开发包括运维开发和DBA分离反类型A：Dev和Ops分离这是经典的“翻墙”开发和运维分离。这意味着可以预先提取需求点（DONE表示“功能完整”，但在生产中不可用），并且软件的可操作性受到损害。因为开发者没有运维相关的上下文信息，运维人员没有时间和动力去参与开发者，在软件上线前解决问题。我们都知道这种拓扑不好，但我认为还有很多类似的拓扑不好；至少我们知道反类型A（Dev和Ops的分离）是一个问题。反类型B：单独的DevOps团队单独的DevOps团队通常来自经理或执行官，他们认为他们“需要一点DevOps的东西”并开始一个“DevOps团队”（可能有人称为“DevOps”）。DevOps团队的成员迅速组成了另一个小组，将Dev和Ops比以往任何时候都更加分离，因为他们需要捍卫自己的角色、技能和工具集，以免被“无知的Devs”和“恐龙Ops”摧毁。唯一一个独立的DevOps团队真正有意义的时候是团队是临时的，比如持续不到12或18个月，其明确目的是使Dev和Ops更紧密地联系在一起，并且是明确的当需要委派时，当那时光荏苒，团队多余。这就是我所说的Type5DevOps拓扑。反类型C：开发不需要操作这种拓扑结构是开发人员和开发经理天真和傲慢结合的结果，尤其是在新项目或系统开始时。假设Ops现在已经过时（“我们现在有云，对吗？”），开发人员大大低估了Ops技能和活动的复杂性和重要性，并认为他们可以在没有Ops的情况下或在闲暇时做事。时间可以把运维的事情搞定。这种反类型CDevOps拓扑最终可能需要类型3（Ops作为IaaS）或类型4（DevOps-as-a-Service）拓扑，因为他们的软件变得更深入和更复杂，并且操作开始需要开发工作（并称为编码）。如果这样的团队将操作视为一门重要且有价值的学科，并认识到它对软件开发的重要性，他们将能够避免很多痛苦和不必要的（并且相当基本的）操作错误。反类型D：DevOps作为一个工具团队组建一个DevOps团队，负责部署流水线、配置管理、环境管理等所需的工具，同时不影响当前开发团队的速度（实现用户故事）。与此同时，运维人员继续在孤岛中工作，而开发团队继续将他们的应用程序“挂在墙上”。虽然这个专门团队的工作可能有助于改进工具链，但其影响是有限的。如果在应用程序开发生命周期中没有早期的操作参与和协作，根本问题仍然存在。原型E：伪装的系统管理员这种原型在工程成熟度低的组织中很典型。他们希望改进实践并降低成本，但他们无法将IT视为业务的核心驱动力。因为现在DevOps的行业成功已经有目共睹，他们也想“做DevOps”。不幸的是，他们没有反思他们当前结构和关系中的差距，而是为他们的Ops团队聘请了“DevOps工程师”。DevOps只是重新发明了一个名为SysAdmin的角色，并没有发生真正的文化/组织变化。这种原型正在变得普遍，因为平庸的招聘人员只寻找具有自动化和工具技能的候选人。不幸的是，真正让DevOps在组织中蓬勃发展的是人际交往能力。反类型F：嵌入开发团队的运营组织不希望有单独的运营团队，因此开发团队负责基础设施、管理环境、监控等。然而，以这种方式被项目或产品驱动意味着这些项目是资源受限的，并且优先级排序会导致糟糕的操作和半成品的解决方案。就此原型而言，该组织缺乏对有效IT运营所需的重要性和技能的认识。反类型G：开发和DBA隔离这是反类型A（开发和运维分离）的一种形式，在大中型公司中很突出，其中多个遗留系统依赖于相同的核心数据集。由于这些数据库对业务至关重要，因此通常在业务中有专门的DBA团队负责维护、性能调整和灾难恢复。这是可以理解的，但问题是当这个团队成为任何数据库更改的网关时，实际上成为小型和频繁部署的障碍（DevOps和持续交付的核心原则）。此外，与反类型A中的操作一样，DBA团队没有参与应用程序开发的早期，因此数据问题（迁移、性能等）是在交付周期的后期发现的。再加上支持多个应用程序数据库的过载，最终的结果是持续不断的救火和部署压力。DevOpsTeamTopologies站在反类型的对立面，让我们看看一些适合DevOps的拓扑：DevandOpsCollaborationFullySharedOpsResponsibilityOpsasanInfrastructureServiceDevOps-as-a-ServiceDevOps-as-a-ServiceTemporaryDevOpsTeamsDevOpsEvangelistTeamsSRETeamsContainer-DrivenCollaboratoryDatabaseCapabilityType1:DevelopmentandCollaborationwithOperations这就是DevOps的“乐土”：开发和运维团队之间的顺畅协作，各学科各有各的地方，但也需要共享.可能有许多独立的开发团队，每个团队都在独立或半独立的产品堆栈上工作。我的意思是，这种第1类模型需要进行相当大的组织变革才能建立，技术管理团队的竞争也很激烈。开发人员和运维人员必须有清晰明确的共同目标（“提供高质量、拥抱变化”或其他）。运维人员要和Devs结对，掌握测试驱动编码技能和Git工具，开发要认真对待运维特性的要求，找运维人员加入日志实现。所有这一切都需要相当大的文化变革才能从目前的情况转变为现在的情况。类型1适应性：技术驱动型组织。有效潜力：高类型2：完全分担运营责任我们看到类型2拓扑，其中运营已集成到产品开发团队中。Dev和Ops之间几乎没有分离，都高度重视一个共同的目标；这是类型1（Dev和Ops协作）的一种形式，但它具有一些特殊功能。Netflix和Facebook等组织有效地实现了基于Web的产品，已经实现了这种Type2拓扑。但我认为它在纯粹的产品视角之外可能不太适用，因为预算限制和多个产品线之间经常存在上下文切换，这可能会迫使Dev和Ops进一步分离（例如回到类型1模型）。此拓扑也可能称为“NoOps”，因为没有明显或可见的运营团队（尽管NetflixNoOps也可能是类型3（Ops作为IaaS））。类型2适应性：组织只有简单的基于Web的产品或服务。有效潜力：高类型3：作为基础设施服务的运营对于具有非常传统IT运营部门的组织，没有或不能（足够）快速拥抱变化，适合在公共云（AmazonEC2、Rackspace、Azure等）中运行组织所有应用程序。它可能将运营视为一个弹性基础设施团队，只需要提供部署和运行应用程序的能力。因此，内部运营团队直接相当于AmazonEC2或基础设施即服务。Dev中的一个团队（也许是一个虚拟团队）将作为操作特性、指标、监控、服务器配置等方面的专业知识来源，并且可能与IaaS团队进行大部分沟通。然而，该团队仍然是一个开发团队，遵循TDD、CI、迭代开发、人员指导等标准实践。IaaS拓扑具有一些潜在的有效性（与Ops人员直接协作），可以更轻松地实施，可能更快地实现价值类型1（开发和运营协作）稍后尝试。类型3适应性：拥有许多不同产品和服务的组织、传统运营部门或其应用程序完全在公共云中运行。有效潜力：中类型4：作为外部服务的DevOps一些组织，尤其是较小的组织，可能没有资金、经验或人员来领导他们的软件运营。开发团队可能会联系Rackspace等服务提供商，帮助他们设置测试环境并自动化其基础设施和监控，并就软件开发周期中实施的各种操作功能提供建议。可以称为DevOps-as-a-Serviced的可能是一个了解什么以及如何使用和实施自动化、监控和配置管理的小型组织或团队。随着业务的增长和更多员工的加入，可能会转向类型3（作为IaaS的运营）甚至类型1（开发和运营协作）模型。类型4适应性：运营经验很少的小型团队或组织。有效潜力：中型类型5：有到期日的DevOps团队有到期日的DevOps团队（类型5）看起来像反类型B（DevOpsTeamSilo），但意图和寿命是完全不同的。这个临时团队的任务是将Dev和Ops更紧密地结合在一起，理想情况下以Type1（开发和运营协作）或Type2（完全共享Ops责任）模型为目标，并最终使自己过时。特设小组的成员将在Dev-speak和Ops-talk之间“翻译”，为Ops团队带来疯狂的想法，如站立和看板，并考虑负载均衡器、管理NIC和卸载SSL等“脏”细节开发团队。如果有足够多的人开始看到将Dev和Ops结合在一起的价值，临时团队就有真正的机会实现其目标。至关重要的是，不应将对部署和生产环境的长期分析和诊断的责任交给临时团队，这可能会造成DevOps团队隔离（反类型B）。类型5适应性：运营经验很少的小型团队或组织。有效潜力：低到中等类型6：DevOps“传道者”团队谈话这是有效的。这是类型5（具有到期日期的DevOps团队）的一个版本，但DevOps团队持续存在，具有特定职责以促进Dev和Ops团队之间的协作与合作。这个团队的成员有时被称为“DevOps传播者”，因为他们帮助传播对DevOps实践的认识。“DevOps团队”的目标应该是通过支持组织的其他部分来支持自己的业务。—推特：EricMinickType6适应性：Dev和Ops趋势去中心化组织，提防TypeB的危险。有效潜力：中高类型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发送给他们的任何东西。有效潜力：中高Type9：开发和DBA协作为了弥合Dev-DBA之间的差距，一些组织尝试了类似Type9的数据库功能，其中DBA团队的数据库能力与Dev团队的数据库能力（或专业知识）相当).这似乎有助于在以开发为中心的数据库视图（本质上是应用程序的虚拟持久存储）和以DBA为中心的数据库视图（智能、丰富的业务价值来源）之间进行转换。类型9适应性：适用于具有连接到一个或多个大型中央数据库的多个应用程序的组织。有效潜力：中请记住：在任何组织中都没有“正确”的团队拓扑结构，只有几个“坏”的拓扑结构。
