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