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

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/