在大多数团队中，开发和运维之间存在着一系列的冲突和博弈。有人说，DevOps的出现，让开发和运维不再相爱相杀。从那以后，他们手牵着手，愉快地编码和捕捉错误。但是有人说DevOps就是开发吃运维。是不是这样，不同的团队结构又会如何影响DevOps的发展？阅读下文，你会有自己的答案。简介在组织中启动任何与DevOps相关的活动的主要目的是提高对客户和业务的价值交付，而不是降低成本、提高自动化或从配置管理中推动任何事情；这意味着不同的组织可能需要不同的团队结构来进行有效的开发和运营协作。哪种DevOps团队结构或拓扑结构适合组织取决于以下几点：组织的产品组合：更少的产品使协作更容易，因为根据康威定律，独立的小团队更少。技术领导的范围、强度和有效性；Dev和Ops是否有共同的目标。组织是否有必要或有能力将IT运营部门从“硬件机架”和“配置服务器”转变为真正与价值流保持一致的部门，以及软件开发团队是否认真对待来自运营的需求。组织是否有能力或技能带头解决当前的运营问题。当然，这里描述的主题各不相同；拓扑和类型作为参考指南或启发式方法提供，以帮助您评估哪些模式可能是合适的。事实上，多种模式的组合，或者一种模式转换成另一种模式，通常是最好的方法。那么DevOps团队结构是如何演变的呢？显然，没有适用于每个组织的理想结构或团队拓扑。然而，对于团队结构，参考少量不同的模型是有用的，其中一些模型更适合某些组织。通过探索这些团队结构（或“拓扑”）的优势和劣势，我们可以确定可能对我们组织中的DevOps实践最有效的团队结构，同时考虑康威定律。这些DevOps拓扑中的大部分已在其他地方进行了描述；特别是CollabNet的LawrenceSweeney谈到了我在这里描述的反类型B（独立的DevOps团队），类型3（作为基础设施服务的运营）和类型1（开发和运营协作）。DevOpsGuys列出了十二种DevOps反模式，JezHumble、GeneKim、DamonEdwards（以及许多其他人）也说过类似的话。我在这里添加了三个额外的“拓扑”，对此我还没有看到或听到一些讨论（共享操作、DevOps-as-a-Service和临时DevOps团队）。DevOps反类型查看一些我们可能称之为“反类型”的不良实践（在无处不在的“反模式”普及之后）是很有用的。A：Dev和Ops分离B：独立的DevOps团队C：开发不需要运维D：工具团队E：系统管理员F：开发包括运维G：开发和DBA分离Anti-typeA：Dev和Ops分离这就是Dev和Ops的经典“翻墙”分离。这意味着前期可以提取需求点（DONE表示“功能完成”，但不能用于生产），软件的可操作性受到损害，因为开发者没有与运维相关的上下文信息，而运维维护人员在软件上线前没有时间和动力去参与开发，解决问题。我们都知道这种拓扑不好，但我认为还有很多类似的拓扑不好；至少我们知道反类型A（Dev和Ops的分离）是一个问题。反类型B：单独的DevOps团队单独的DevOps团队（反类型B）通常来自经理或执行官，他们决定“需要一点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在组织中蓬勃发展的是人际交往能力。Anti-TypeF:OperationsEmbeddedinDevelopmentTeam组织不想要单独的运营团队，所以开发团队负责基础设施，管理环境，监控等。但是，以这种方式被项目或产品驱动意味着这些项目资源有限，优先排序导致运营不佳和半成品解决方案。就这种反类型学而言，组织缺乏对有效IT运营所需的重要性和技能的认识。反类型G：开发和DBA隔离这是反类型A（开发和运维分离）的一种形式，在大中型公司中很突出，其中多个遗留系统依赖于相同的核心数据集。由于这些数据库对业务至关重要，因此通常在业务中有专门的DBA团队负责维护、性能调整和灾难恢复。这是可以理解的，但问题是当这个团队成为任何数据库更改的网关时，实际上成为小型和频繁部署的障碍（DevOps和持续交付的核心原则）。此外，与反类型A中的操作一样，DBA团队没有参与应用程序开发的早期，因此数据问题（迁移、性能等）是在交付周期的后期发现的。再加上支持多个应用程序数据库的过载，最终的结果是持续不断的救火和部署压力。DevOpsTeamTopologies站在反类型的对立面，我们来看一些适合DevOps的拓扑。1：开发与运维协作2：共享运维3：运维作为基础设施服务4：DevOps-as-a-Service5：临时DevOps团队6：DevOps布道者团队7：SRE团队8：容器驱动9：数据库能力类型1：开发与运维协作This是DevOps的“乐土”：开发团队和运维团队之间的顺畅协作，各学科各有所需，但也需要共享。可能有许多独立的开发团队，每个团队都在独立或半独立的产品堆栈上工作。我的意思是，这种Type1模型需要进行相当大的组织变革才能建立，并且在技术管理团队中具有很高的竞争力。开发人员和运维人员必须有清晰明确的共同目标（“提供高质量、拥抱变化”或其他目标）。运维人员要和Devs结对，掌握测试驱动编码技能和Git工具，开发要认真对待运维特性的需求，找运维人员加入日志实现。所有这一切都需要相当大的文化变革才能从目前的情况转变为现在的情况。类型1适应性：技术驱动型组织。有效潜力：高类型2：完全分担运维责任我们看到运维已集成到产品开发团队中的类型2拓扑。Dev和Ops之间几乎没有分离，都高度重视一个共同的目标；这是类型1（Dev和Ops协作）的一种形式，但它具有一些特殊功能。Netflix和Facebook等组织，有效地实现了基于Web的产品，已经实现了这种Type2拓扑，但我认为它在纯粹的产品视角之外可能不是很适用，因为预算限制和多个之间经常有上下文切换产品线，这可能会迫使Dev和Ops进一步分离（例如，回到Type1模型）。此拓扑也可能称为“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团队”的目标应该是通过支持组织的其他部分来支持自己的业务。—推特：EricMinick类型6适应性：开发和运营趋向于去中心化组织。谨防B类危险。有效潜力：中高类型7：SRE团队（Google模型）DevOps通常建议Dev团队参加定期轮班会议，但这不是必需的。事实上，一些组织（包括谷歌）运行不同的模型，明确地从开发“切换”到运行软件的团队（站点可靠性工程（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适应性：适用于具有连接到一个或多个大型中央数据库的多个应用程序的组织。有效潜力：中请记住：在任何组织中都没有“正确”的团队拓扑结构，只有几个“坏”的拓扑结构。
