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/
评论 1 条评论