LBW's Wiki Pages

# DevOps 团队结构

DevOps 的主要目标是改善客户和企业之间的价值交付，而不仅仅是减小成本、提升自动化或者通过配置管理驱动一切。这意味着，为了实现高效的开发和运维协同，不同的组织可能需要不同的团队结构。

# 概述

总的来说，具体哪种 DevOps 团队结构适合组织，取决于以下几个方面

  • 组织的产品数量：产品数量越少，Dev与Ops协同起来就越简单。
  • 技术领导者的职责范围，技术实力，以及Dev和Ops是否有共同的目标。
  • 组织是否有能力或意愿变革其 IT 运维部门，使其不再只是“上架硬件”和“配置服务器”，而是成为真正与与价值流一致的部门，使运维被软件团队重视起来。
  • 组织是否有能力主导运维。

所以，什么样的团队结构适合使用 DevOps 模式呢？显然，不可能存在适合所有组织的团队结构。然而，介绍几种不同的团队结构模型仍然是有必要的，因为对于某个具体的组织而言，使用某个具体的团队结构模型会比其他的团队结构模型更合适。通过探索这些团队结构的优点和缺点，我们可以确定自己组织中最适合 DevOps 的团队结构。

下面具体介绍有关 DevOps的各种团队结构。

# 不适合DevOps 的模型

首先我们介绍一些不符合 DevOps 要求的团队结构模型。

  • 反例1：Dev 和 Ops 完全独立
    • 这种模型下，Dev人员没有足够的有关运维的信息，Ops人员也没有时间或者不想为了软件上线前解决问题而参与开发，造成团队效率较低。

img

  • 反例2： DevOps团队完全独立
    • 这种模型往往是因为项目经理认为他们“需要一点 DevOps“ 相关的东西，所以创建了一个 DevOps团队。这个团队中的成员与Dev团队和Ops团队完全分开，并且夹在两者之间，使Dev和Ops之间的距离越拉越远。
    • 这种模型仅仅在一种情况下是真正有意义的，就是该团队为临时团队，存在时间不超过12个月或18个月，其目的是为了让Dev和Ops团结起来，而且很明确，过了这段时间后，该 DevOps 团队就是多余的了。

img

  • 反例3：Dev不需要Ops

    • 这种模型诞生于开发人员和开发经理的天真和傲慢，开发人员严重低估了运维技能和活动的复杂性和重要性，并相信可以没有Ops团队。

      img

  • 反例4：DevOps作为工具团队

    • 为了“成为 DevOps”而又不影响当前 Dev 团队的速度（或者说功能点交付），创建一个 DevOps 团队致力于部署管道、配置管理、环境管理等所需的工具。同时，运维人员继续孤立工作，而 Dev 团队继续把应用程序从“墙上”扔给他们。
    • 尽管这个专门小组的成果就改进工具链而言可能是有好处的，但其影响很有限。在应用程序开发生命周期中 Ops 人员未能早期参与和协作的基本问题仍然没有改变。

img

  • 反例5：换个名的系统管理员
    • 这种反类型在工程成熟度较低的组织中很典型。他们想要提高实践并降低成本，然而，他们并没有将 IT 视为业务的核心推动力。因为 DevOps 在行业内取得的成功现在已经显而易见，所以他们想“做 DevOps”。不幸的是，他们没有反思当前的结构和关系存在什么差距就去为 Ops 团队招聘“DevOps 工程师”，这很难达到目的。
    • DevOps 只是对以前的 SysAdmin 角色改了个名，没有真正的文化 / 组织变革发生。这种反类型正变得越来越普遍，因为为了招揽人才而无所不为的招聘人员会赶时髦，寻找具有自动化和工具技能的求职者。遗憾的是，人类的沟通技巧可以让 DevOps 在组织中茁壮成长。

img

  • 反例6：Ops嵌入到Dev团队
    • 组织不希望保留一个单独的运维团队，因此，开发团队会负责基础设施、管理环境、监控等。然而，在项目或产品导向的方式中，这样做意味着这些工作会受到资源限制和优先级重排的影响，导致低于标准的方法和不成熟的解决方案。
    • 这种反类型表明，组织对有效 IT 运维的重要性和所需的技能缺乏认识。并且，Ops 的价值会被贬低，因为开发人员将其视为一种烦恼（Ops 是由开发团队的管理者管理的，而开发团队往往有其他的优先级事项）。

img

# 适合DevOps的模型

  1. Dev 与 Ops 协作
    • Dev 团队和 Ops 团队之间顺畅协作，各自专注于自己的工作，并在必要的时候互相分担。可能有许多单独的 Dev 团队，每个团队致力于一个独立或半独立的产品栈。
    • 这种模型的建立需要相当大量的组织变革，并且要求技术管理团队的高层具有一定的能力。Dev 和 Ops 必须有一个清晰描述且明显有效的共同目标（提供可靠而频繁的变更，诸如此类）。Ops 人员必须适应与 Dev 人员搭配，掌握测试驱动编码和 Git，而 Dev 人员必须认真对待运维特性，从 Ops 人员那里获得日志实现的输入，等等，所有这些都需要相当大的文化变革。

img

  1. 完全共担 Ops 职责
    • 运维人员已经被整合到产品开发团队，Dev 和 Ops 之间几乎密不可分，所有人都高度关注同一个目标，这是一种有争议的 1 型（Dev 和 Ops 协作） 形式，但它有一些自己的特点。
    • 实际上，一些只有一种 Web 产品的组织已经实现了这种模型。但是，如果不是只关注少量核心产品，这种模式可能不是非常适用，因为在拥有多个产品流的组织中，预算限制和上下文切换很可能会迫使 Dev 和 Ops 进一步分开（比如说回到 1 型模型）。由于没有明显的或可见的运维团队，所以这种拓扑可能也被称为“NoOps”。
  2. Ops 即 IaaS
    • 对于具有传统 IT 运维部门的组织，以及将所有应用程序运行在公有云上的组织，这可能有助于将运维视为一个团队，他们只是提供了弹性基础设施供应用程序在上面部署和运行；为此，内部 Ops 团队直接就相当于 Amazon EC2 或“基础设施即服务（IaaS）”。
    • 然后，Dev 中的一个团队（也许是一个虚拟团队）可以作为运维特性、指标、监控、服务器配置等方面的专家组，可能负责大部分与 IaaS 团队的沟通。然而，这个团队仍然是一个 Dev 团队，遵循 TDD、CI、迭代开发等标准实践。

img

  1. DevOps 作为外部服务
    • 有些组织，特别是较小的组织，可能没有财力、经验或人力可以运维其开发的软件。Dev 团队可能会联系服务提供者，如 Rackspace，帮助他们构建测试环境及自动化基础设施和监控，并就他们在软件开发周期中实现何种运维特性提供建议。、
    • 对于小型组织或团队，如果他们想要学习自动化、监控和配置管理，然后随着他们的发展，会有更多的人专注于运维，他们可能发展成 3 型（Ops 即 IaaS） 甚至 1 型（Dev 和 Ops 协作） 模型，那么 DevOps 即服务可能是一个有效而务实的方式。

img

  1. 具有截止日期的 DevOps 团队
    • 具有截止日期的 DevOps 团队（5 型）看上去非常像 反类型 2（DevOps 完全独立），但它的意图和期限有很大的不同。这个临时团队的使命是让 Dev 和 Ops 更紧密地联系在一起，在理想的情况下向 1 型（Dev 和 Ops 协作） 或 2 型（完全共担Ops 职责） 模型转化，并最终会淘汰掉。

img

  1. DevOps 宣传团队
    • 在 Dev 和 Ops 之间存在巨大鸿沟的组织里，它可以有效地“促进”DevOps 团队，保证 Dev 和 Ops 之间的对话。这是 5 型**（具有截止日期的 DevOps 团队）** 的一个版本，但这里的 DevOps 团队是一直存在的，其具体职责是促进 Dev 团队和 Ops 团队之间的协作。这个团队的成员有时也被称作“DevOps 宣传者”，因为他们帮助宣传 DevOps 实践。

img

  1. SRE 团队（谷歌使用的模型）
    • DevOps 经常建议 Dev 团队加入值班轮换，但这不是必要的。事实上，有些组织（包括谷歌）运行一个不同的模型，软件由开发团队显式“交接给”运行软件的团队，即网站可靠性工程团队（SRE）。在这个模型中，Dev 团队需要向 SRE 团队提供测试证据（日志、指标等），证明他们的软件已经达到一个 SRE 团队认为足够好的标准。
    • 至关重要的是，SRE 团队可以拒绝不符合运维标准的软件，要求开发人员在投入生产之前改进代码。Dev 和 SRE 之间的协作围绕着运维标准展开，但是，一旦 SRE 团队对代码满意，他们（而不是 Dev 团队）就会在生产环境中提供支持。

img

  1. 容器驱动协作
    • 容器将应用程序的部署和运行要求封装到了容器中，消除了 Dev 和 Ops 之间的某些协作需求。在这种情况下，容器充当了 Dev 和 Ops 的责任边界。在良好的工程文化中，容器驱动协作模型运转良好。

img

  1. Dev 和 DBA 协作
    • 为了消除 Dev 和 DBA 之间的鸿沟，有些组织已经尝试使用类似这样的模型，DBA 团队的数据库能力与 Dev 团队的数据库能力（或专长）可以很好地互补。这似乎有助于将以 Dev 为中心的数据库视图和以 DBA 为中心的数据库视图之间的转换。

img

# 参考资料

What team structure is right for Devops to flourish? (opens new window)

DevOps代码管理 →