Dev和Ops在一起工作是件很美好的事情，但是目前很多DevOps团队可能是个“假DevOps团队”。那么，蓬勃发展的DevOps的理想结构应该是什么样子？

如果开发能够和IT运营无缝协作，是一件很美好的事情。而DevOps就是旨在消除孤岛，以便这些团队可以协同工作，更快地构建、测试和部署软件。DevOps不仅仅是一个通俗易懂、充满哲学意味的缩写词汇，它包含很多比结构组件更深层次的东西。

对于不熟悉康威定律的人来说，它是这样的：

任何设计系统的组织(广泛定义)都将产生一种设计,其结构是组织通信结构的副本。

那么理想的DevOps团队结构应该是什么样子？了解现有结构是否有效的唯一方法就是，开发和运营协同工作之后，是否达到或超过了既定的业务目标。当然，每家公司的情况不同，这样有助于分析不同的模型，通过查看每个的优缺点，并结合康威定律，企业能够找到更适合团队的独特需求。

在团队结构方面，有几个因素可以发挥作用：

现有孤岛：是否有独立运作的产品组或团队？
技术领导：谁领导团队，他们的行业经验是什么？Dev和Ops是否有相同的目标，以及他们是否是由领导者的个人经验在指导？
IT运营：运营是否完全符合业务目标，他们的角色定位是否仅仅是配置服务器并协助开发团队完成其项目？
知识差距：组织现在是否具备改变DevOps结构的技能和人力资源？

了解筒仓

Matthew Skelton的博客详细介绍了许多不同的DevOps场景，这里我们仅仅谈论他提到的孤岛以及它们如何影响组织。

Dev和Ops完全分离

Skelton 称这是一个经典的“隔墙扔砖”（译注：throw it over the wall）的团队结构，并且暗示，它不是最有效的DevOps战略。虽然两个团队都在努力工作，但是缺乏对其他团队工作流程的可见性。这种完全分离的团队结构缺乏协作、可见性和理解，而这些刚好是有效的DevOps的重要组成部分。在这样的团队结构中，一旦出现问题，很容易出现互相推诿的情况，例如“我们不清楚他们做了什么，我们完成了自己的工作，剩下的应该是他们来做。”

回到康威定律，这显然是个不善于沟通的组织，因此他们创建了这样一个团队结构，并且在可能没有意识到的情况下就反映出了这一点。很明显，这不是伟大的DevOps。

DevOps中间人

在这个团队结构中，仍然有单独的Dev和Ops团队，但会有个“DevOps”的团队作为推动者。这不一定是个坏事，Skelton 强调这种方式有一定的用例，例如如果这是个临时的解决方案，其目标是使Dev和Ops在未来更具凝聚力，那么就可能是一个很好的策略。

Ops独立

在这个团队结构中，Dev和DevOps融合在一起，而Ops仍然是独立的。在这样的组织中，他们认为Ops是支持软件开发计划的东西，而不是有价值的东西，但是当他们遇到基本的操作错误时，他们就会理解Ops的价值了。

领导力的重要性

假设，您所在的组织中，遇到的功能障碍都已经由康威定律100%确认了，并且为了改善DevOps结构，需要在沟通方面进行重大转变。这时应该怎么办呢？克服与DevOps实施相关的文化变革挑战的秘密可以从领导者的领导方式中找到。

众所周知，组织变革是非常困难的，必须有全公司的支持，许多部门必须就行动方案达成一致。即使是在这样理想的状态下，变革也是不容易的，更不用说有些组织在事先都没有沟通好。

导致变革失败的主要因素包括：

抵制变革
变革准备不足
员工敬业度差

变革型领导力直接影响团队成员如何响应流程、技术、角色和思维模式中的DevOps变化。

在定义特定角色及其功能时，Puppet团队提出了以下建议：

IT经理：与其他团队的同行建立信任; 创造学习和持续改进的氛围; 将相应的权力下派给团队成员；
开发经理：与Ops建立信任; 尽早将Ops纳入规划流程；
系统工程师：让之前痛苦的事情变成自动化；
质量工程师：提供有关规模、性能和组织环境的输入；
开发人员：计划部署新功能，提供Ops的反馈，并在部署过程中与他们合作。

Ops的参与感

运营是一门拥有自己方法的学科，由于云托管的出现，使得服务器的部署比以往任何时候都更容易，而不必知道另一根SCSI数据线的一端，但这并不意味着每个人都是Ops主人。Ops为SDLC带来的是可靠性、性能和稳定性。开发人员可以利用自己的技能来自动化生产环境的流程。真正的DevOps应该是能够发挥每个人的优势。

DevOps并不意味着开发人员管理生产。

Dev和Ops之间可能存在直接冲突，因为两个团队是以非常不同的方式受到激励：运营强调可用性，开发强调功能交付。可用性需要谨慎，而谨慎是速度的对立面，但两个团队可以相互学习并从相互的经验中获益。

在SDLC中，Ops是盟友，而不是障碍。

差距存在的必然性

是否现在就需要创建更高效的DevOps团队结构？这就要再次回到康威定律，很重要的一点是，我们需要分享团队目前的沟通方式，客观地思考什么应该更好，你想要创造什么。

工具无法解决文化问题。

很多企业和组织已经接受了新的团队结构，并且了解了组织结构与所创建软件之间的联系。例如，Netflix和Amazon围绕多个小团队构建自己的结构，每个团队在系统的一小部分上都是自主的。但是拥有更多单片代码库的团队不能这样工作，为了采用Netflix DevOps模型，他们还需要采用微服务架构。

微服务和容器使DevOps模型能够快速迭代，并在某些组织中提供更多自治。代码环境的体系结构对团队如何协同工作会产生很大影响。

由于GitLab是整个软件开发生命周期中的一个单一应用程序，我们的Dev Teams被分为几个阶段（例如验证组、创建组等），因为它们在将从其它公司是独立产品，需要自主权。除了“Dev”之外，我们还有其它功能性DevOps组，来负责管理我们产品的其它方面。我们还有一个SRE团队，负责管理GitLab.com、质量部门和分销团队的正常运行时间和可靠性。以上只是简单举了几例，为了实现整个SDLC的透明度和可见度，我们把很多部分都组合起来了。为了能够加快发布速度，我们还通过容器和Kubernetes进行云原生开发。

一个促进Dev和Ops团队之间协作和可见性的团队结构，以及自动化流程的工具，是理想的DevOps生命周期的标志。请记住，良好的DevOps 并不意味着每个人都要做或者会做所有的工作。开发人员也没有必要做Ops的工作。

刚开始，很多人认为DevOps的目标是把Dev、QA和Ops部门合并为一个团队，然后每个人需要做好每一件事情。不出所料，这些策略失败了。

的确，专家可以增加价值，但是如果Dev和Ops流程之间缺乏凝聚力，反而会导致不必要的功能障碍。不应该是我们和他们，而统一是我们。这样沟通的组织将不可避免的建立一个以同样方式运作的结构，而理想的DevOps团队结构可以让团队有效地协同工作，消除代码和生产之间的障碍。

原文链接：https://about.gitlab.com/2019/06/12/devops-team-structure/

创作场景

消灭无效 DevOps，理想的 DevOps 团队结构应是这样