本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 投资组合分析和迁移规划
<a name="portfolio-analysis-migration-planning"></a>

此评估阶段的重点是完成在投资组合发现和[初始规划部分开始的投资组合级别的发现和](portfolio-discovery-initial-planning.md)分析。目标是对应用程序和基础设施的初始产品组合进行迭代并建立基准。该基准包括确定所有依赖关系、迭代迁移合理化模型、创建详细的业务案例以及概述迁移浪潮计划。因此，所需的数据保真度更高。这个阶段需要时间投入。为了加快评估结果，我们建议尽可能多地使用程序化数据源，例如发现工具。

该阶段的主要结果包括以下内容：
+ 高保真应用程序和基础设施清单
+ 每个应用程序的高级迁移策略
+ 高度可信的移民浪潮计划
+ 详细的商业案例

# 了解完整的评估数据要求
<a name="understanding-complete-assessment-data-requirements"></a>

下表描述了获取迁移中应用程序及其相关基础架构的完整产品组合视图所需的信息。

这些表使用以下缩写：
+ R，表示必填项
+ O，表示可选
+ 不适用，因为不适用

**应用程序**


| **属性名称** | **描述** | **库存和优先顺序排列** | **详细的商业案例** | **建议的保真度级别（最低）** | 
| --- | --- | --- | --- | --- | 
| 唯一标识符 | 例如，应用程序 ID。通常可在现有 CMDBs 或其他内部库存和控制系统上使用。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R | 高 | 
| 应用程序名称 | 您的组织知道此应用程序的名称。如果适用，请包括商业 off-the-shelf (COTS) 供应商和产品名称。 | R | R | 高 | 
| 是 COTS 吗？ | 是或否。 无论是商业应用程序还是内部开发 | R | R | 高 | 
| COTS 产品和版本 | 商用软件产品名称和版本  | R | R | 高 | 
| 说明 | 主要应用程序功能和上下文 | R | R | 高 | 
| 严重性 | 例如，战略性或创收应用程序，或支持关键功能 | R | R | 高 | 
| Type | 例如，数据库、客户关系管理 (CRM)、Web 应用程序、多媒体、IT 共享服务 | R | R | 高 | 
| 环境 | 例如，生产、预制版、开发、测试、沙箱 | R | R | 高 | 
| 合规与监管 | 适用于工作负载（例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP）和监管要求的框架 | R | R | 高 | 
| 依赖项 | 内部和外部应用程序或服务的上游和下游依赖关系。非技术依赖关系，例如操作元素（例如维护周期）。 | R | O | 高 | 
| 基础设施映射 | 映射到构成应用程序的物理 and/or 虚拟资产 | R | R | 高 | 
| 许可证 | 商用软件许可证类型（例如，微软 SQL Server Enterprise） | R | R | 中高 | 
| 成本 | 软件许可、软件操作和维护成本 | 不适用 | R | 中高 | 
| 业务部门 | 例如，营销、财务、销售 | R | R | 高 | 
| 所有者详情 | 应用程序所有者的联系信息 | R | R | 高 | 
| 灾难恢复信息 | 灾难恢复组件 | R | R | 高 | 
| 迁移策略 | 例如，迁移到 6 R 中的一个 AWS | R | R | 高 | 
| Support 门票 | 12—24 个月的数据可帮助评估中断、减速、交易限制和批处理窗口超支对生产率和财务的影响 | O | R | 中 | 

**基础设施**


| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度级别（最低）** | 
| --- | --- | --- | --- | --- | 
| 唯一标识符 | 例如，服务器 ID。通常可在现有 CMDBs 或其他内部库存和控制系统上使用。 IDs如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R | 高 | 
| 网络名称 | 网络中的资产名称（例如，主机名） | R | R | 高 | 
| DNS 名称（完全限定域名或 FQDN） | DNS 名称 | R | O | 高 | 
| IP 地址和网络掩码 | 内部 and/or 公有 IP 地址 | R | R | 高 | 
| Asset type | 例如，物理或虚拟服务器、虚拟机管理程序、容器、设备、数据库实例 | R | R | 高 | 
| Product name | 商业供应商和产品名称（例如， VMware ESXiIBM Power Systems、Exadata） | R | R | 高 | 
| 操作系统 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 高 | 
| 配置 | 分配的 CPU、内核数、每个内核的线程数、总内存、存储空间、网卡 | R | R | 高 | 
| 利用率 | CPU、内存和存储峰值和平均值。数据库实例吞吐量。 | R | R | 高 | 
| 许可证 | 商品许可证类型（例如，RHEL 标准） | R | R | 高 | 
| 是共享基础架构吗？ | “是” 或 “否” 表示提供共享服务的基础架构服务，例如身份验证提供商、监控系统、备份服务和类似服务 | R | R | 高 | 
| 应用程序映射 | 在此基础架构中运行的应用程序或应用程序组件 | R | R | 高 | 
| 成本 | 裸机服务器的满负荷成本，包括硬件、维护、操作、存储（SAN、NAS、Object）、操作系统许可证、机架空间份额和数据中心管理费用 | 不适用 | R | 中高 | 
| 估计的数据传输量（输入/输出） | 例如，在 30 天内每天的每项基础设施资产  | O | R | 中 | 

**网络**


| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度级别（最低）** | 
| --- | --- | --- | --- | --- | 
| 管道尺寸 (Mb/s), redundancy (Y/N) | 当前广域网链路规格（例如，1000 Mb/s 冗余） | R | R | 中高 | 
| 链路利用率 | 峰值和平均利用率，出站数据传输（GB/月） | R | R | 中高 | 
| 延迟 (毫秒) | 连接位置之间的当前延迟。 | R | O | 高 | 
| 成本 | 每月当前费用 | 不适用 | R | 中高 | 

**迁移**

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)

# 为应用程序组合建立基准
<a name="baseline-application-portfolio"></a>

要制定高度可信的迁移浪潮计划，必须为应用程序组合及其相关基础设施建立基准。产品组合基准提供了迁移范围的全面视图，包括技术依赖关系和迁移策略。产品组合基准可以清楚地说明哪些应用程序在迁移范围内，并收集了 “[了解完整评估数据要求” 部分中概述的数据](understanding-complete-assessment-data-requirements.md)点。同样，所有相关的基础架构（计算、存储网络）都被理解并映射到应用程序。

技术依赖关系可以分为四类：
+ pplication-to-infrastructure依赖关系@@ **建立了**软件与物理或虚拟硬件之间的联系。例如，CRM 应用程序与安装该应用程序的虚拟机之间存在依赖关系。
+ **应用程序组件**依赖关系描述了在不同基础架构资产中运行的组件是如何交互的。应用程序组件依赖关系的一个示例是在虚拟机上运行的 Web 前端，应用程序层在不同的虚拟机上运行，数据库运行在数据库集群上。
+ **pplication-to-application依赖关系与应用程序或应用程序组件与其他应用程序或其组件之间的交互有关。** application-to-application依赖关系的一个例子是付款处理应用程序和库存管理应用程序。这些应用程序是独立的，但它们经常使用定义的 API 操作进行交互。
+ Application-to-infrastructure 鉴于基础设施@@ **服务**本身就是一个应用程序，服务 application-to-application依赖关系在技术上是依赖关系。但是，我们建议将它们分开分类。主要原因是基础设施服务通常由许多应用程序共享，因此它们有很长的依赖关系。它们通常还遵循不同的迁移策略和模式。例如，负载均衡器可以包含多个应用程序的平衡池。重要的是对池的依赖关系，它很可能会与依赖的应用程序一起单独迁移，而负载均衡器本身则被保留或停用。此外，个性化 application-to-infrastructure服务依赖关系有助于避免错误的依赖组。错误依赖组是指将多个业务应用程序组合在一起，这意味着必须同时迁移与基础架构服务有共同依赖关系的业务应用程序。例如，诸如 Active Directory 之类的身份验证服务很可能与大型应用程序组相关联。关键是要单独处理这些应用程序，并通过在云环境中启用服务（例如在云环境 AWS Directory Service for Microsoft Active Directory中）来解决依赖关系。

在为产品组合建立基准时，我们建议您确认每个应用程序组件的迁移策略。迁移策略将是迁移的 6 R 策略之一（参见 “[迭代 6 R 迁移策略](iterating-6-rs-migration-strategy-selection.md)” 部分）。在投资组合基准中，应将6R中的一个与每个应用程序相关联。还应将 6 R 策略与应用程序的每个基础架构组件相关联。

要建立产品组合的基准版本，包括依赖关系和迁移策略，请使用自动发现工具（请参阅[评估对发现工具的需求](understanding-initial-assessment-data-requirements.md#discovery-tooling)）。使用从应用程序所有者和基础设施团队等关键利益相关者那里收集的信息来补充数据。继续收集数据，直到获得与本阶段[数据要求部分](understanding-complete-assessment-data-requirements.md)中概述的属性和保真度相匹配的完整投资组合清单。生成的数据集将有助于推动迁移。

请考虑一下，根据您的迁移范围和可用工具，此活动可能需要几周才能完成。

# 迭代优先级标准
<a name="iterating-prioritization-criteria"></a>

在创建迁移浪潮计划之前，我们建议您迭代应用程序优先级标准，从试点应用程序选择转向长期浪潮规划。

在前面的章节中，我们引入了默认的优先级标准，该标准将优先考虑简单的云就绪应用程序（请参阅对应用程序[进行优先排序](prioritization-and-migration-strategy.md#prioritizing-applications)）。这是因为在早期阶段，我们建议从非关键应用程序开始，以完善迁移流程并吸取经验教训。但是，在这个阶段，为了制定长期计划，应用程序的迁移顺序应与业务驱动因素保持一致。应用新标准将生成新的应用程序排名，这将是波浪规划的关键输入。

查看应用程序组合中的可用数据点，并选择将根据业务驱动因素确定应用程序优先级的属性。

首先，验证您的业务驱动因素（参见[业务驱动因素和技术指导原则](business-drivers-technical-guiding-principles.md)）。接下来，根据您的业务驱动因素，选择有助于确定要迁移的应用程序优先顺序的属性。

下表显示了与创新业务驱动因素一致的优先顺序标准示例。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)

下表显示了与业务驱动因素一致的优先级标准示例，可快速降低成本。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)

测试优先级标准并进行迭代，直到您普遍同意输出为止。至少需要三到四次迭代才能获得基准版本。

# 迭代 6 R 迁移策略选择
<a name="iterating-6-rs-migration-strategy-selection"></a>

在这个阶段，我们建议您迭代和改进 6 R 决策树。“[确定迁移的 R 类型](prioritization-and-migration-strategy.md#migration-r-type)” 部分引入了默认决策树。我们建议对树进行修改，同时考虑初始试点应用程序迁移过程中的经验教训，并确保它仍然与业务驱动因素、优先级标准和您的独特情况保持一致。使用示例应用程序验证决策树，并验证它是否仍然产生预期的策略。否则，请相应地更新逻辑。生成的树将是为应用程序组合建立基准以及为每个应用程序组件分配迁移策略的关键。

如前面的 [6 R 部分](prioritization-and-migration-strategy.md#migration-r-type)所述，6 R 也适用于基础设施，相应地分配它们同样重要。虽然给定的应用程序组件将有迁移策略，但在基础架构级别，每项基础架构资产都将遵循给定的迁移策略，该策略可能与为其支持的应用程序组件制定的策略不同。

请记住，6 R 决策树仅适用于应用程序组件。基础架构的迁移策略源于为应用程序选择的策略。例如，对于将要进行平台改造的应用程序组件，托管该组件的当前基础架构可能会停用。

确保将迁移策略分配给每个应用程序组件及其关联的基础架构。在估算所需的工作量、容量和技能以及制定迁移浪潮计划时，这些信息将是一个关键因素。

有关确定 6 R 的更多信息，请参阅[AWS Migration Hub 策略建议](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)。

# 波浪规划
<a name="wave-planning"></a>

在波浪规划中，依赖组是一组具有无法解决的技术和非技术依赖关系的应用程序和基础架构。由于这些依赖关系，依赖关系组中的应用程序和基础架构必须同时迁移或在特定日期迁移。例如，在虚拟机上运行的应用程序和在单独的虚拟机中运行的数据库，在这些虚拟机中存在低延迟要求或高流量和复杂的查询，很可能会一起迁移，而不是在云中运行一个组件，而另一个组件在内部运行。同样，通过具有类似低延迟要求的 API 进行交互的独立应用程序也将同时迁移。

迁移波通常持续 4-8 周，可能包含一个或多个迁移事件。依赖组被组合成波次，因此波浪可以包含一个或多个依赖组。该浪潮还包含迁移所需的其他活动。其中包括 AWS 基础架构设置（例如 landing zone、安全和运营）、迁移工具和迁移活动，例如数据复制、切换规划、测试和迁移后支持。

为了衡量成功和跟踪进展，波浪应与结果和业务驱动因素保持一致。这也会影响波浪持续时间和波浪所包含的依赖组。一波浪潮的完成应反映出一项可衡量的成就。波浪的规划还可以结合其他因素，例如技术指导原则。例如，可以按环境（例如开发、测试、生产）或迁移策略（例如，重新托管浪潮、重新平台浪潮）来定义浪潮。

要制定有效且高度可信的迁移浪潮计划，您必须全面了解应用程序产品组合、相关基础架构（计算、存储、网络）、依赖关系映射和迁移策略。

关于[为应用程序组合建立基准的](baseline-application-portfolio.md)部分描述了四类技术依赖关系。这些依赖关系促成了迁移浪潮的产生和依赖群体的定义。依赖群体将由依赖关系的严重程度决定。此外，还必须考虑非技术依赖性。例如，应用程序发布时间表、维护时段和关键业务日期（例如月底或季度末处理）将影响波浪计划。

确定依赖关系是*软*依赖关系还是*硬*依赖关系。软依赖关系是两个或多个资源之间的关系，或者从一个资源到一个约束的关系，它不依赖于组件的位置。例如，在同一个局域网（或相同基础架构）中运行的两个系统可以分开，方法是将其中一个系统移到云端，而另一个系统则留在内部。另一个例子是可以在维护时段内迁移而不会影响维护活动的系统。

硬依赖关系是两个或多个资产之间的关系，或者从一项资产到约束条件的关系，取决于位置。例如，两个系统在同一个本地网络中运行，并且在很大程度上依赖于低延迟来实现应用程序服务器和数据库服务器之间的通信，这两个系统具有硬依赖性。仅将其中一个系统迁移到云端会导致无法解决的功能或性能问题。同样，非技术原因，例如资源可用性（例如，执行迁移的团队）或操作限制（例如维护时段，两个系统只能在给定的时间窗口内迁移），可能会对这些资产造成严重的依赖。

要制定迁移浪潮计划，请通过分析依赖关系来确定依赖组，最好是来自高度可信的数据来源，例如专业的发现工具，并将这些信息与您的应用程序优先级标准和操作环境相结合。在优先级排名中名列前茅的应用程序应针对您的初始迁移浪潮。根据资源可用性、风险承受能力、业务和技术限制、经验和技能来确定波浪容量（一波可以包含的应用程序数量）。考虑与 AWS 专业服务或 AWS 迁移能力合作伙伴合作，他们可以提供专家在整个过程中为您提供帮助。

优先级标准是将应用程序迁移到云端的顺序的初步指示。但是，依赖组将是将在给定时间移动的应用程序的实际决定因素。这是因为排名为高优先级的应用程序可能与排名中间或底部的应用程序有硬依赖性。

迁移策略还将影响浪潮的构成。例如，需要重构策略的高优先级应用程序可能需要数周或数月的分析、设计、测试和准备工作，很可能会被置于以后的浪潮中。

## 制定波浪计划
<a name="create-wave-plan"></a>

迁移一波应用程序的先决条件是应用程序组合数据以及对将在浪潮中迁移的应用程序组的详细应用程序评估。详细的评估应包括浪潮中的应用程序列表、相关的基础架构详细信息、目标设计以及每个应用程序的迁移策略。

建立浪潮所有权和治理是管理和跟踪浪潮工作、项目依赖关系、变更管理、问题和风险的关键。确保建立管理框架来管理计划。

要概述波浪计划，请从默认波浪构造开始。波浪中会发生什么？ 定义初始输入后，波浪就可以开始了。通常，活动将是：

1. 完善切换计划。本活动应概述迁移时必须采取的操作手册和步骤，包括与其他内部和外部团队的协调。

1. 完善回滚计划。如果出现问题，必须采取什么措施才能回滚应用程序？

1. 准备目标基础架构。例如，您可以创建或扩展 landin AWS g zone（安全AWS 账户、网络、基础设施服务、其他支持基础设施）。

1. 测试目标基础架构。

1. 操作迁移工具。例如，安装复制代理并开始数据传输。

1. 执行切换计划和运行手册试运行。对所有参与的团队成员进行分组，并提前查看所有步骤。

1. 监控数据复制和基础架构部署。

1. 确认中基础设施和应用程序的运行准备就绪 AWS。

1. 确认安全准备就绪。

1. 如果适用，请确认合规性和法规要求（例如，迁移前和迁移后的工作负载验证）。

1. 将应用程序迁移到 AWS 并执行上线前测试。

1. 在一段时间（例如 3 天）内提供迁移后支持，届时运营团队和迁移团队将完全可以解决问题并进行优化。

1. 进行迁移后审查。记录吸取的经验教训，并将其融入未来的浪潮中。

1. 通过确认操作移交和获取报告指标来执行波浪结算。

每项活动需要多长时间将取决于范围的复杂性、波浪容量、所涉及的人员和您的独特情况。在可能的情况下，最好使用较小的波浪，因为这样可以减少任何延迟或迁移阻碍因素的影响。与你的队伍一起确定浪潮的默认持续时间。

接下来，继续分析日期，创建由空波组成的初始高级结构（尚未分配应用程序）。考虑以下问题：
+ 迁移计划的总长度是多少？ 
+ 截止日期是什么时候？
+ 是否有固定的数据中心退出日期？ 
+ 有搭配合同的终止日期吗？ 
+ 应用程序和基础架构的更新周期是多少？ 
+ 应用程序的维护和发布周期是多少？ 
+ 是否有应避免迁移的日期（例如，发布和维护周期、年底、节假日、月底处理）？

考虑到这些因素，将波浪规划成计划。为了加快迁移过程，我们建议尽可能重叠浪潮。重叠波浪的关键是定义和考虑波浪中会发生什么。通常，部署活动、目标基础架构验证和数据同步将在浪潮的前半段进行。下半部分将侧重于实际的迁移、测试和操作移交。这意味着流程的每一半都涉及不同的团队，并且您可以提高一定的效率。例如，一旦参与目标基础架构准备的团队完成工作，他们就可以开始研究下一波的要求。通常，大多数波浪最好具有相似的长度和结构，以便于采用类似工厂的迁移方法。但是，在波浪规划过程中，可以扩展给定波浪的大小以满足依赖关系或操作要求。

接下来，根据已确定的依赖组，根据波浪可以包含的依赖组数量来确定波浪的最大大小。波浪大小通常由风险偏好（例如，可以容忍多少并行变化）和资源可用性（例如，利用可用资源、技能和预算可以执行多少并行变化）决定。但是，在早期规划期间，不要受资源需求和可用性的限制。在未来的迭代中，包含多个依赖组的波浪可以分解为较小的波浪。

确认给定波次的依赖组后，请查看迁移该浪潮的资源需求。考虑根据资源需求调整波浪大小（其中包含的依赖组数量）。这可能会导致更小或更大的波浪。根据需要迭代波浪计划，直到所有波浪都定义完毕。

## 管理变更
<a name="manage-change"></a>

在迁移计划的生命周期中，应用程序和相关基础架构组合将发生变化。长期运行的迁移计划与正常的业务演变和变化并存。应用程序在等待迁移的过程中会不断发展。添加或删除服务器，在本地部署新的基础架构。预计浪潮或依赖群体的范围将需要更改。尤其是在接近迁移日期时，发现以前未知的依赖关系或清单中包含新服务器时，需要进行更改。有时，这可能发生在迁移过程中。

范围变化会影响依赖组和波动。为了应对变化并最大限度地减少影响，建立范围控制机制非常重要。范围变更控制机制要求定义范围的单一真实来源。这可以是管理范围的工具，也可以是迁移计划治理所定义的.csv 文件、电子表格或数据库。您必须识别变化，分析影响，并将变更传达给相关利益相关者，以便他们能够采取行动。因此，将对波浪计划进行迭代。

# 详细业务案例
<a name="detailed-business-case"></a>

在此阶段，我们建议验证并扩大业务案例的范围，以提供更详细的信息来支持转型计划。快速整理的初步方向性商业案例旨在提供足够的信心，以投资于基础步骤和下一级别的详细规划。

制定详细的商业案例可通过以下方式支持这一规划过程：
+ 提供财务分析，为决定哪些内容应迁移和现代化、选择哪些选项以及如何分阶段和确定工作的优先顺序提供依据
+ 通过详细重新审视，验证、完善和开发最初的定向财务案例：
  + 降低基础设施成本的潜力
  + 内部 IT 工作效率和任何外包运营效率
  + 项目设置、迁移和现代化所需投资的估算
+ 识别、估计迁移带来的更多价值驱动因素，并设置流程以跟踪迁移带来的更多价值驱动因素

在详细的商业案例中，您可以确定以下内容：
+ 确保至少执行第一阶段迁移的任务和投资的客观基础
+ 该计划的基准最低财务业绩预期
+ 明确制定各种移民设计和优先顺序决策的财务基础，这样当情况和人员在计划过程中发生变化时，新的领导层可以做出明智的选择。
+ 在工作负载迁移和开始运行时，初始使用数据可用后，深入了解成本优化的增量领域
+ 估算云转型通过提高弹性和敏捷性为业务带来的价值 
+ 用于估算弹性和灵活性提高所带来的财务回报的相关 KPIs指标和假设，这些指标和假设构成了推动该计划实现主要收益的基准

## 确定案例所需的场景
<a name="determine-scenarios-needed"></a>

在构建详细的商业论证时，通常需要开发多个场景来支持商业论证的不同用途。

**最小变化情景** — 要评估最低财务业绩预期，请准备一个假设现状发生最小预期变化的情景。作为最坏的情况，这种情况在获得投资迁移的授权时是有用的支持。此情景对容量增长的最低预期程度以及其他 quality-of-service需求（例如可用性和弹性）的最小变化进行建模。对于当前的运营模式，最少的变化会带来最低的成本和最少的资源效率低下。

**最有可能的情况** — 为了为计划策略和优先级决策提供信息，请准备反映企业预期情况的情景。此情景应包括可能的峰值利用率增长或减少以及升级成本，以满足业务对高水平服务质量（尤其是可用性和弹性）的需求。

**其他具体情景** — 如果仍有必要做出可能对商业论证产生重大影响的假设，则为假设成立、哪些假设不成立，制定假设不成立的情景。但是，我们建议将这些替代方案的数量保持在绝对最低限度。总共创建超过三到四个场景都会减慢进度，并且会变得昂贵、混乱且难以维护。只要有可能，就进行实验并努力消除更大的假设。

## 验证和完善基础架构和迁移成本模型
<a name="validate-refine-infrastructure-migration-cost-model"></a>

完成投资组合分析并准备好目标的设计和规模后 AWS 服务，针对每种情景完善当前运营模式 (COM) 和 future 运营模式 (FOM) AWS 的运行成本估算。通常需要完善以下各项的估计值：
+ 虚拟机管理程序主机服务器、裸机服务器、存储、网络设备、安全设备硬件更新、安装和维护的 **COM 基础架构成本**。使用场景所需容量的实际定价和 discount 级别来计算这些值。
+ **COM 数据中心和并置设施的成本**，包括空间、冷却、电源、机架、不间断电源 (UPS)、电缆、物理安全系统，其规模适合增长并指定满足容量，以及该场景的高可用性和灾难恢复 (DR) 级别。
+ **COM 网络服务成本**，包括 WAN 链路、内容交付网络和虚拟专用网络的成本 (VPNs)，使用合同定价来计算该场景的连接、带宽、吞吐量和延迟需求。
+ **COM 应用程序和基础设施软件成本**基于现有合同，用于提供场景中使用量的增长或减少。
+ **FOM AWS 公用事业成本**，包括所需的技术支持和托管服务，具体取决于完善的服务架构、实例大小、首选定价模式、预期使用量和使用波动性。
+ **FOM 应用程序许可**基于最终的应用程序设计、运行应用程序的基础架构的配置、随时间的增长以及许可证可转让性规则。
+ **FOM 迁移和现代化成本估算**，经过细化以反映该场景的基准迁移浪潮计划，并详细提供了每项工作负载的成本，尤其是那些要进行平台重建、回购或重构的工作负载。
+ **FOM的退役成本**，包括资产注销和合同提前终止成本的估计，进行了修订，以反映基准迁移浪潮计划中的退役时间，核实哪些资产可以重新利用，哪些资产可以转换以最大限度地减少核销，以及处置实物资产和媒体的成本。
+ 对@@ **迁移并行运行成本**进行了细化，以反映每次迁移切换和每个现有服务停用的时间。

## 完善 IT 生产力和 IT 运营并支持效率价值模型
<a name="refine-it-productivity-it-operations-support-efficiency-value-model"></a>

与定向业务案例一样，有两种主要方法可以完善和开发围绕IT运营和支持的价值模型。您选择的方法取决于COM是由内部管理还是由承包商或外包服务管理：

*提高内部团队的工作效率*

在 IT 运营和支持由内部管理的情况下，业务案例的重点是以下几点：
+ 识别并量化迁移和范围中包含的任何操作自动化所带来的生产率提高
+ 验证为内部团队腾出的时间可以轻松、富有成效地应用于其他通常价值较高的活动，从而为团队提供进步和更高回报的机会，为组织带来更多价值

评估团队中每个角色的每位成员在各种常规活动上花费的时间，并就不同活动的工作量预期减少提供指导。

对于那些消耗团队中不同角色的大量 IT 操作和支持工作的任务，下表提供了按活动减少工作负载的典型水平的初步指导。该表包括对如何实现生产率的描述。

**注意**  
列出的活动通常由担任多个不同角色的团队成员执行，因此应根据团队中所有角色评估每项任务节省的生产力。例如，在按基础架构塔（例如计算、存储和网络）组织的 IT 运营团队中，资本支出规划和预算对每座塔楼的主管来说可能很常见。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)

下表显示了每个工作量减少级别的预期节省。


| **级别** | **预期** | 
| --- | --- | 
| 非常高 | 85%-100% | 
| 高 | 60%-90% | 
| 中 | 30%-70% | 
| 低 | 10%-35% | 
| Minimal | 0%-10% | 

这些指标为评估生产率提高并将其纳入详细的业务案例提供了一个起点。实际生产率的提高因具体情况而异。计算区间中端和下端的生产率节省可能很有用，以估计典型和保守情景。

随着计划的进展，按角色捕获在每项活动上花费的时间的实际数据非常有价值。这些数据为估算运营奠定了更好的基础，并支持了新项目和服务扩展的成本。

*外包 IT 运营和支持成本降低*

[如果 IT 运营和支持主要外包或由承包商管理，则可以通过向提供托管服务解决方案（包括合作伙伴 AWS 主导AWS Managed Services (AMS)）的 AWS 合作伙伴索取报价来准备未来运营模式 (FOM) 的成本分配。](https://aws.amazon.com/managed-services/partners/)您也可以联系您的 AWS 客户经理，直接索取 AMS 的价格，如[创建定向商业案例](directional-business-case.md)部分[中关于运营成本优化的构建](directional-business-case.md#building-operational-cost-optimization)小节中所述。

要了解详细的业务案例，请将任何基准数据替换为基于修订后的 AWS 服务物料清单和预期服务消耗、AMS 套餐和所需的任何选项以及所需服务级别的报价。成本将包括一次性实施部分和基于消耗的运行率。

包括所有剩余的 IT 运营、必须为任何不会迁移到的服务保留的支持 AWS，以及如果有合同罚款（例如，提前终止），则需支付一次性费用。

## 开发弹性价值模型
<a name="develop-resilience-value-model"></a>

在上 AWS，您可以构建各种高可用性、灾难恢复和容错架构。基于消费的定价意味着仅在使用时才对服务收费。这两个因素共同为弹性提供了卓越的成本性能。

此外， AWS 客户一直在使用它来提高其工作负载的弹性。[IDC 2018 调查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)举例说明参与的客户每年减少了 73% 的停机次数，平均恢复时间 (MTTR) 缩短了 58%，生产力损失减少了 94%。同一项调查显示，通过提高弹性获得的财务收益比降低IT基础架构成本的收益高出50％。

此外，通过对应用程序的软件开发生命周期进行现代化改造，可以进一步提高弹性。在引入具有测试自动化的 CI/CD 管道以支持更高的业务灵活性时，可以在开发周期的早期发现软件缺陷，从而大大降低软件维护成本。

要评估这一价值并将其纳入业务案例中，请首先与应用程序业务所有者合作，了解要迁移的每个工作负载的*总体收益机会***。**这可能包括以下项目：
+ 服务中断的次数、平均持续时间和性质：
  + 服务中断的示例包括中断、性能减慢、计划中的批处理和维护窗口超时、关键功能出现错误以及高峰时段的访问限制。
+ 创收服务（例如电子商务系统）中断对收入的影响：
  + 根据中断时间和交易速率，可能因服务中断而无法完成的交易数量
  + 每笔受影响的交易的平均价值
+ 与在开发过程早期发现缺陷的成本相比，支持工程师解决生产系统缺陷所需的额外成本
+ 对内部用户工作效率的影响和浪费时间的成本

然后，对因服务中断而损失的时间进行预期的、更为保守的缩短情况进行评估，而弹性增强应该会产生****这种缩短。例如，考虑包括以下项目：
+ 使用高可用性架构和改进的恢复时间目标 (RTO) 和恢复点目标 (RPO)，减少停机次数和 MTTR
+ 使用自动扩展等功能，减少减速，消除容量限制，避免批处理超支
+ 通过实施 CI/CD 管道以及对启动和关闭的基础设施进行自动回归测试，减少仅在生产中发现的应用程序错误数量，从而最大限度地降低成本

将它们汇总在一起，得出要迁移和现代化的应用程序组合，并计算每个案例年度的预期和更保守的业务价值数字。收益应根据迁移时间表增加，然后根据贡献应用程序的使用量增长预期扩大容量。

 

## 开发业务敏捷性价值模型
<a name="develop-business-agility-value-model"></a>

业务敏捷性是 AWS 客户迁移到的主要原因 AWS。[IDC 2018 年 AWS 客户调查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)显示，对他们而言，业务敏捷性收益占测总收益的 47%，是基础架构成本降低所得收益的五倍多。

准确预测任何转型将带来的所有业务敏捷性优势是一项艰巨的任务。但是，通过将重点放在支持大量用户或成为业务差异化来源的应用程序上，您可以对这种优势的很大一部分进行建模，并将其纳入基准详细的业务案例中。

随着迁移的进行，随着更多收益可以量化，逐步完善和扩展业务敏捷性价值模型。这样可以使业务案例保持相关性，因此可以将其用作指导计划的主要决策支持工具。

要构建业务敏捷性价值模型，请使用以下指南：
+ 选择有机会推动最大业务绩效改善的工作负载，例如：
  + 创收工作负载 
  + 业务运营工作负载有推动效率提高和降低业务成本的余地
  + 支持大型用户群的业务生产力工具
+ 对于产生收入和效率的工作负载，请执行以下操作：
  + 对主要和次要应用程序升级可能推动的收入增长或运营效率进行现实和更为保守的评估。
  + 估计每年增加的主要版本和次要版本数量，从而 AWS 提高了应用程序开发速度并缩短了基础架构部署时间。IDC 报告中提供了这方面的一些基准指标。
  + 计算现实且更为保守的福利预期。在业务论证期间对它们进行映射，以便在相应的工作负载迁移后的一段时间内提高到最大效率。
+ 要使用业务生产力工具，请执行以下操作：
  + 对主要和次要应用程序升级预计可以节省的时间进行现实和更为保守的评估。
  + 估算受影响用户群中人们的时间和精力的平均成本。
  + 使用这些数字来计算主要和次要发布频率的增加，并计算业务案例期限内的收益。

由于提高开发人员的工作效率和缩短的发布时间不需要额外的资源，因此将每个工作负载的净收益项目添加到业务案例现金流模型中，以便包含在折扣现金流、净现值、投资回报率、MIRR 和投资回报计算中。