你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

DevOps 团队拓扑

在 IT 团队和应用程序团队之间分配角色、职责和信任对于大规模采用云所涉及的运营转换至关重要。

IT 团队努力保持控制。 应用程序所有者寻求最大化敏捷性。 最终在这两个目标之间建立的平衡极大地影响了云运营模式的成功。

根据康威定律,团队基于其通信结构生成体系结构。 了解这一原则对于努力实现自主和控制之间的必要平衡至关重要。 任何设计系统(定义广泛)的组织都将生成一个设计结构,该结构是该组织通信结构的副本。

说明康威定律的示意图。

从 DevOps 的角度来看,组织必须进行优化,才能快速响应客户需求。 拥有、设计和实现其应用程序和系统的团队在具有以下特征的体系结构中找到了最高级别的自主权:

  • 支持不断变化的进化体系结构
  • 可部署性
  • Testability

康威的解决方法是战胜康威定律。 如果组织遵循特定结构来生成服务和产品并想要进行优化,则需要重新考虑组织结构。 发展团队和组织结构,以实现所需的体系结构。

反向康威机动示意图。

这一原则导致有意设计的团队拓扑,其中团队负责他们拥有的所有应用程序、系统或平台的端到端,以实现 DevOps 的完整规则。

下表提供了这些团队的简化分类。

团队类型 定义
应用程序工作负载团队 这些团队构建的应用程序可推动一部分业务领域的直接业务成果。 在 Azure 登陆区域上下文中,这些团队负责应用程序工作负载的端到端生命周期。
平台团队 这些团队构建引人注目的内部平台,以加快交付速度并减少应用程序工作负载团队的认知负担。 在 Azure 登陆区域上下文中,这些团队负责 Azure 登陆区域的端到端生命周期。
支持团队 这些团队通过协助其他具有专用能力(如 DevOps)的团队来克服技能差距。

设计注意事项

  • 建立跨职能平台团队,以设计、生成、预配、管理和维护 Azure 登陆区域生命周期。 此团队可能包括来自中心 IT 团队、安全性、合规性和业务部门的成员,以确保代表企业的广泛范围。 请确保避免使用反模式

  • 考虑建立一个支持团队,该团队可以提供 DevOps 职能以支持不具有现有 DevOps 功能的应用程序和平台,或提供业务案例来建立一个(例如,具有最少开发功能的旧版应用程序)。

  • 请勿将应用程序工作负载团队限制在中心项目上,因为这可能会阻碍其敏捷性。 可以使用策略驱动的治理和 Azure 基于角色的访问控制 (Azure RBAC) 强制实施一致的基线配置,并确保应用程序(业务部门)团队足够灵活,以便进行创新,同时仍能够从预定义的模板集汲取经验。

  • 请勿强制应用程序团队使用中心流程或预配管道来实例化或管理应用程序资源。 已经依赖 DevOps 管道进行应用程序交付的现有团队仍然可以使用其当前工具。 请记住,可以使用 Azure Policy 来帮助强制实施组织标准,并大规模评估合规性,并解决 DevOps 流程的安全注意事项

  • 全面应用 DevOps 模型并不会立即打造出技能高超的 DevOps 团队。

  • 投资工程能力和资源至关重要。

  • 某些旧版应用程序的应用程序团队可能没有与 DevOps 策略协调一致所需的工程资源。

设计建议

以下部分包含设计建议,可在设计团队拓扑时提供指导。

使团队拓扑与云运营模式保持一致

请确保团队拓扑与所需的云运营模式保持一致。

建立运营适应性审核的核心流程,以便充分了解团队结构可能导致的问题。

为平台团队定义职能

以下列表为负责 Azure 登陆区域的平台团队提供了一组建议的职能:

  • 体系结构治理
  • 所需网络、标识和访问管理策略的订阅预配和委托
  • 平台管理和监视(整体)
  • 成本管理(整体)
  • 平台即代码(模板、脚本和其他资产的管理)
  • Microsoft Entra 租户中 Microsoft Azure 的总体操作(服务主体管理、Microsoft Graph API 注册和角色定义)
  • Azure RBAC(整体)
  • 中心服务的密钥管理(简单邮件传输协议和域控制器)
  • 策略管理和强制执行(整体)
  • 安全监视和审核(整体)
  • 网络管理(整体)

为应用程序工作负载团队定义职能

以下列表为负责应用程序工作负载的应用程序团队提供了一组建议的职能:

  • 通过 DevOps 模型创建和管理应用程序资源
  • 数据库管理
  • 应用程序迁移或转换
  • 应用程序管理和监视(应用程序资源)
  • Azure RBAC(应用程序资源)
  • 安全监视和审核(应用程序资源)
  • 机密和密钥管理(应用程序密钥)
  • 成本管理(应用程序资源)
  • 网络管理(应用程序资源)

为支持团队定义职能

以下列表为负责协助其他团队的支持团队提供了一组建议的职能:

  • 定义横向(跨职能)指导和能力,以帮助在整个组织中获得正确的专业知识,从而确保与整体目标云运营模式(如 DevOps)保持一致
  • 为其他团队提供支持、培训和指导,以达到必要的专业知识水平
  • 为应用程序或平台团队建立一组通用的可重用模板和库,并培养 InnerSourcing,例如 Azure 验证的模块

定义团队之间的交互模式

团队之间的交互目标是:

  • 实现自主
  • 解除依赖
  • 最大程度地减少时间浪费
  • 避免瓶颈

团队拓扑概述了三种团队交互模式:

交互模式 说明
协作 团队密切合作。
X 即服务 团队以最少的协作消费或向其他团队提供某些东西,类似于第三方供应商交互。
辅助 团队帮助或由另一个团队帮助以消除障碍。