你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
项目组合层次结构
若要了解工作负载、资产和支持服务 组合 如何协同工作，需要建立项目组合层次结构。 本文为项目组合层次结构的级别提供了明确的定义，以及指导团队实现每个级别的预期。 在本文中，层次结构的每个级别也称为范围。
工作负载
提供定义的业务价值的技术集合称为工作负载。 集合可能包括应用程序、服务器或虚拟机、数据、设备和其他类似分组的资产。 大多数企业依赖于多个工作负载来提供重要的业务功能。
通常，业务利益干系人和技术负责人共同负责对每个工作负载的持续支持。 在工作负载生命周期的某些阶段，这些角色是明确规定的。 在工作负载生命周期的更多运营阶段，这些角色可能会转移到共享运营管理团队或云运营团队。 随着工作负载数量的增加，角色（明示或暗示）变得更加复杂和矩阵化。
工作负载及其支持资产是任何项目组合的核心。 范围或层定义这些工作负载的查看方式，以及它们受潜在支持团队矩阵的影响程度。
尽管条款可能有所不同，但所有 IT 解决方案都包括资产和工作负载：
- 资产：支持工作负载或解决方案的最小技术功能单位。
- 工作负载：为业务提供 IT 支持的最小单位。 工作负荷是基础结构、应用程序和数据资产的集合，这些基础结构、应用程序和数据资产支持共同的业务目标或共同业务流程的执行。
部署第一个工作负载时，工作负载及其资产可能是唯一定义的范围。 当部署更多工作负载时，可能会显式定义其他层。
IT 项目组合
当公司通过矩阵方法或集中式方法支持工作负载时，可能存在更广泛的层次结构来支持这些工作负载：
- 登陆区域： 登陆区域为工作负载提供支持一个或多个工作负载所需的必要基础实用工具或共享管道。 登陆区域在云中非常重要，云采用框架的整个就绪方法都侧重于登陆区域。 有关更详细的定义，请参阅什么是登陆区域？
- 基本实用程序：这些共享 IT 服务是工作负载在技术和业务组合中运行所必需的。
- 平台基础：此组织构造集中了基础解决方案，有助于确保为所有登陆区域强制实施这些控制。
- 云平台： 根据支持完整产品组合的总体策略，客户可能需要具有不同平台基础部署的多个云平台，以管理多个区域、混合解决方案，甚至多云解决方案。
- 项目组合：从技术角度来看，该产品组合是跨所有云平台的工作负载、资产和支持资源的集合。 从业务角度来看，项目组合是支持和管理技术组合以推动业务成果的项目、人员、流程和投资的集合。 这两个角度共同刻画了项目组合。
层次结构问责制和指南
问责团队管理项目组合层次结构的每一层。 下图显示了问责团队与支持其业务决策、技术决策和技术实现的指南之间的映射。
注意
以下列表中提到的团队可能是虚拟团队或个人。 对于此层次结构的一些变体，某些问责团队可以按照后面的问责制变体中的描述进行折叠。
- 投资 组合： 云策略团队和卓越云中心 (CCoE) 使用 策略 和 计划 方法来指导影响整个项目组合的决策。 云策略团队负责云项目组合层次结构的企业级。 云策略团队还应了解有关环境、登陆区域和高优先级工作负载的决策。
- 云平台： 云治理团队负责确保每个环境与 治理 方法保持一致的规则。 云治理团队负责治理所有环境中的所有资源。 对于可能需要例外的更改或对治理策略的更改，应该咨询云治理团队。 云治理团队还应了解工作负载和资产采用的进展情况。
- 登陆区域和云基础：云平台团队负责开发支持采用的登陆区域和平台实用程序。 云自动化团队负责自动开发和持续支持这些登陆区域和平台实用程序。 两个团队都使用 就绪 方法指导实现。 工作负载采用的进度以及企业或环境的任何更改都应告知这两个团队。
- 工作负载：采用发生在工作负载级别。 云采用团队使用迁移和创新方法建立可缩放的流程来加速采用。 采用完成后，工作负载的所有权可能会转移到云运营团队，该团队使用 管理 方法来指导运营管理。 两个团队都应该能够熟练地使用 Microsoft Azure 架构良好的框架来制定影响他们支持的工作负载的详细体系结构决策。 对于登陆区域和环境的更改应告知这两个团队。 两个团队偶尔可能会为登陆区域功能做出贡献。
- 资产：资产通常由云运营团队负责。 该团队使用管理方法中的 管理 基线来指导运营管理决策。 它还应使用 Azure 顾问和 Azure 良好架构的框架来进行满足运营要求所需的详细资源和体系结构更改。
问责制变体
- 单一环境：当企业只需要一个环境时，通常不需要 CCoE。
- 单一登陆区域：如果环境中只有一个登陆区域，则可以将治理和平台功能合并到一个团队中。
- 单个工作负载： 某些企业在单个登陆区域和单个环境中只需要一个工作负荷或几个工作负载。 在这些情况下，几乎不需要在治理、平台和运营团队之间进行职责分离。
常见的工作负载和问责制示例
以下示例演示项目组合层次结构。
COTS 工作负载
传统上，企业青睐商用现货 (COTS) 软件解决方案来为业务流程提供动力。 这些解决方案经过安装、配置，然后进行操作。 配置后，解决方案体系结构几乎没有变化。
在这些场景中，COTS 解决方案的任何云采用都以转换到 云运营团队而告终。 然后，云运营团队成为该软件的技术所有者，并承担管理配置、成本、修补周期和其他运营需求的责任。
这些工作负载包括计帐包、物流软件或行业特定的解决方案。 在 Microsoft 术语中，这些包的供应商称为独立软件供应商 (ISV)。 许多 ISV 提供一项服务，用于在订阅中部署和维护其软件包的实例。 它们还可能提供在自己的云托管环境中运行的软件包版本，为工作负载提供平台即服务 (PaaS) 替代方案。
除 PaaS 产品/服务外，云运营团队负责确保这些工作负载的基本运营合规性要求。 云运营团队应与云治理团队合作，以协调成本、性能和其他体系结构要素。
在开发时具有活动修订版本
当 COTS 解决方案或 PaaS 产品/服务不符合业务需要，或不存在解决方案时，企业将构建自定义开发的工作负载。 通常，只有一小部分 IT 产品组合使用此工作负载方法。 但这些工作负载往往会导致 IT 对业务成果的贡献比例过高，尤其是与新收入流相关的成果。 这些工作负载往往很好地映射到新的创新理念。
鉴于植根于敏捷方法和 DevOps 实践的各种运动，这些工作负载有利于业务/DevOps 的一致性，而不是传统的 IT 管理。 对于这些工作负载，可能几年都不会移交给云运营团队。 在这些情况下，开发团队充当工作负载的技术所有者。
由于大量时间和资金限制，自定义开发选项通常仅限于高价值机会。 典型示例包括应用程序创新、深层数据分析或任务关键型业务功能。
中断/修复或日落开发
在自定义开发的工作负载达到最高成熟度后，开发团队可能会被重新分配到其他项目。 在这些情况下，技术所有权通常会转换到云运营团队。 当需要进行小的修复时，运营团队将招募开发人员来解决错误。
在某些情况下，开发团队会转向最终将取代当前工作负载的项目。 或者，团队可能会继续工作，因为工作负载支持的业务机会正在逐步淘汰。在这些日落方案中，云运营团队将充当技术所有者，直到不再需要工作负载。
在这两种场景下，云运营团队通常是长期的技术所有者和决策者。 当运营更改需要大量体系结构更改时，该团队可能会招募应用程序开发人员。
关键工作负载
在每个公司，都有一些工作负载对业务来说太重要而不能失败。 对于这些任务关键型工作负载，通常有负责不同级别的运营和开发所有者。 这些团队应协调运营更改和体系结构更改，以尽量减少对生产解决方案的中断。
这些场景需要非常注重职责分离。 运营团队通常会对生产环境中的日常运营更改负责。 当这些运营更改需要体系结构更改时，在运营团队将更改应用于生产之前，开发或采用团队将在非生产环境中完成这些更改。
具有所需职责分离的任务关键型工作负载示例包括 SAP、Oracle 或其他企业资源规划 (ERP) 解决方案等工作负载，它们跨越公司的多个业务部门。
策略项目组合协调
重要的是要了解云采用工作的策略目标并调整项目组合以支持该转换。 几种常见类型的策略项目组合协调有助于塑造项目组合层次结构。 以下部分提供了项目组合对齐方式和对项目组合层次结构的影响的示例。
创新或开发导向型项目组合
一些公司，尤其是快速增长的初创公司，自定义开发项目的百分比高于平均水平。 在开发密集型项目组合中，环境、登陆区域和工作负载通常是压缩的，因此可能有特定环境用于特定工作负载。 结果是环境、登陆区域和工作负载之间的比率为 1：1。
由于环境托管自定义解决方案，DevOps 管道和应用程序级报告可能会取代对运营和治理功能的需求。 这些客户可能会减少对运营、治理或其他支持角色的关注。 通常也会更强调云采用和云自动化团队的职责。
项目组合协调：IT 项目组合可能会专注于工作负载和工作负载所有者，以推动关键体系结构决策。 在采用和运营活动期间，这些团队可能会在 Azure 架构良好的框架指导中发现更多价值。
边界定义：逻辑边界（即使在企业级）也可能侧重于生产和非生产环境分段。 公司软件项目组合中的产品之间也可能存在明确分段。 有时，开发实例和托管客户实例之间也可能存在分段。
运营导向型项目组合
拥有更成熟的 IT 运营团队的跨国企业组织通常更关注治理和运营，而不是开发。 在这些组织中，较高百分比的工作负载通常与由云运营团队中的技术所有者维护的“票房”或“中断/修复”类别保持一致。
项目组合协调：IT 项目组合将与工作负载保持一致，但这些工作负载随后会与操作部门或业务部门保持一致。 可能还有围绕资金模型、行业或其他业务分段要求的组织。
边界定义：登陆区域可能会将应用程序分组为应用程序原型，以在类似的分段中保留类似的运营。 环境可能会引用物理构造，例如数据中心、国家/地区、云提供商区域或其他运营组织标准。
迁移导向型项目组合
与运营导向型项目组合类似，主要通过迁移构建的项目组合将基于导致现有资产迁移的特定业务驱动因素。 通常，数据中心是这些驱动因素中的最大因素。
项目组合协调：IT 项目组合可能与工作负载一致，但更可能与资产一致。 如果公司历史上发生过向 IT 运营的转换，许多活跃使用的资产可能无法轻松映射到受资助的工作负载。 在这些情况下，许多资产可能直到迁移过程后期才具有定义的工作负载或明确的工作负载所有者。
边界定义：登陆区域可能会将应用程序分组到反映本地分段的边界。 虽然不是最佳做法，但环境通常与代表网络分段做法的本地数据中心名称和登陆区域相匹配。 更好的做法是遵循与运营导向型项目组合更紧密一致的分段。
治理导向型项目组合
应尽早与治理团队保持一致。 通过治理实践和云治理工具，项目组合和环境边界可以最佳地平衡创新、运营和迁移工作的需求。
项目组合协调：治理导向型项目组合往往包括捕获创新和运营详细信息的数据点，例如工作负载、运营所有者、数据分类和运营关键性。 这些数据点可创建项目组合的一个全面视图。
边界定义：治理导向型项目组合中的边界倾向于支持运营而非创新，同时使用映射到业务部门和开发环境标准的管理组驱动的层次结构。 在层次结构的每个级别，云治理边界可以实施不同级别的策略，以实现开发和创意灵活性。 同时，生产级要求可应用于生产订阅，以确保职责分离和一致的运营。