本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 任务 4：定义应用程序的深入研究流程
现在，您已经完成了应用程序优先级划分规则和流程的制定，接下来您将对应用程序进行深入研究，这将帮助您细化每个应用程序的优先级。您可以按优先级从高到低的顺序逐个对一个应用程序进行深入研究。对于有多个项目组合团队的项目，每个团队可以同时对不同的应用程序进行深入研究。
在深入研究过程中，您可能会遇到一些意想不到的问题，例如依赖关系，这些问题会影响应用程序迁移的复杂性。发生这种情况时，您应该修改在上一步中定义的复杂度评分标准，并相应地更新分数表，以便为未来的应用获得更准确的复杂度分数。然后，您可以使用新的复杂度分数来更新应用程序的优先级。
此任务包括以下步骤：
+ [第 1 步：定义应用研讨会流程](#deep-dive-1)
+ [步骤 2：定义应用程序映射过程](#deep-dive-2)
+ [步骤 3：（可选）定义应用程序目标状态](#deep-dive-3)
+ [第 4 步：完成应用程序深度研究流程](#deep-dive-4)
## 第 1 步：定义应用研讨会流程
研讨会流程是深入研究应用程序的最有效方法之一。使用此流程，您可以与利益相关者、应用程序所有者和项目组合团队合作评估和分析应用程序。目标是清楚地了解应用程序的当前状态，包括其架构、业务目的、依赖关系和环境。然后，您可以使用有关应用程序大小和复杂性的详细信息来设计应用程序的目标状态。
每个研讨会通常持续 1-8 个小时，但您可能会发现需要更多时间来处理高复杂性的应用程序。您也可以将研讨会分成多个会议，具体取决于资源的可用性、您的偏好以及应用程序的大小和复杂性。
### 确定预期结果
在举办应用研讨会之前，您应该制定议程并定义研讨会的预期结果或需要在研讨会上收集的信息。这使研讨会参与者能够为研讨会做准备，有助于使会议按目标进行，并确保在研讨会结束时，您拥有确定优先级、波浪计划和迁移应用程序所需的所有信息。
我们建议您定义一组标准的预期结果，并将其记录在应用程序优先级排序操作手册中。在准备研讨会时，您可以使用标准的预期结果，并为特定应用程序添加新的预期结果。
定义应用研讨会的标准预期成果，如下所示：
1. 打开您的应用程序优先级排序操作手册。
1. 在*应用研讨会的预期结果*部分，为应用研讨会制定一套标准的预期结果。在准备研讨会时，您可以根据应用程序的特定需求对其进行自定义。
1. 保存应用程序优先级排序运行手册。
1. 在应用程序优先级划分运行手册中保持预期结果。在举办应用研讨会并继续进行投资组合评估和浪潮规划时，您可能会确定新的预期结果或完善现有结果。
以下是应用研讨会的预期结果示例。
****
| 优先级 | 应用研讨会的预期成果 |
| --- | --- |
| 1 | 清楚地了解应用程序的当前架构，包括关联的服务器、依赖关系、环境和应用程序层。 |
| 2 | 该团队已收集元数据以支持目标架构的设计。需要以下元数据：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | 应用程序所有者问卷已完成，所有关键问题都已得到解答。 |
| 4 | 该团队收集了所有应用程序文档，例如用户指南、应用程序架构文档、测试文档、设计文档和应用程序编程接口 (API) 文档。 |
### 定义应用程序研讨会规则
在举办应用程序研讨会之前，您应该定义管理研讨会的规则。常见规则包括研讨会时长、研讨会可能需要的工具以及需要考虑的任何日程安排考虑因素或截止日期。这有助于使会议按目标进行，并确保在研讨会上做出的决策与迁移时间表保持一致。
我们建议您在应用程序优先级划分运行手册中记录应用程序研讨会的规则。
按如下方式定义您的应用程序研讨会规则：
1. 打开您的应用程序优先级排序操作手册。
1. 在*应用程序研讨会规则*部分，定义管理研讨会的规则。
1. 保存应用程序优先级排序运行手册。
1. 维护应用程序优先级排序运行手册中的规则。在举办应用研讨会并继续进行投资组合评估和浪潮规划时，您可能会确定新规则或完善现有规则。
以下是应用程序研讨会的规则示例。
****
| 优先级 | 研讨会规则 |
| --- | --- |
| 1 | 研讨会应安排在周二和周四每节课最多2小时。 |
| 2 | 基础设施定于 12 月 1 日至 1 月 15 日冻结。 |
| 3 | 有一个关于迁移工具的实践研讨会。 |
| 4 | 数据中心合同将于3月31日到期。必须在 3 月 31 日之前撤出工作量，以避免罚款和代价高昂的合同延期。 |
| 5 | 生物识别应用程序和考勤申请将被保留。 |
### 定义应用程序研讨会流程
定义举办应用研讨会的标准流程非常重要。这样可以确保持续的体验，并为研讨会参与者设定期望，从而提高研讨会的效率。
申请研讨会流程分为三个阶段：
+ **为研讨会做准备** — 为研讨会做准备有助于确保会议顺利进行，并确保参与者知道预期的内容。要为研讨会做准备，您需要制定议程并定义预期成果，确定研讨会所需的参与者、工具和信息，然后安排研讨会。至少提前一周安排研讨会可以让团队有时间安排日历、为研讨会做准备并收集任何有用的信息。
+ **举办研讨会** — 在举办研讨会时，应将讨论限制在议程上的项目上，并确保实现预期的结果。请注意您认为有帮助但未包含在议程中的主题。录制研讨会可能会有所帮助。
+ **最终确定研讨会成果** — 研讨会结束后，您的团队应清楚地了解应用程序的当前状态以及可能影响优先级划分和迁移的潜在痛点、风险、挑战和障碍。研讨会结束后的常见任务包括：重新确定应用程序的优先级，起草应用程序的未来状态，以及使用可能对下一次研讨会有所帮助的任何预期结果、规则或流程变更来更新运行手册。
*用于确定应用程序优先级的 Runbook 模板*包括准备、举办和最终确定应用程序研讨会的标准 step-by-step流程。按如下方式定义您的应用研讨会流程：
1. 打开您的应用程序优先级排序操作手册。
1. 在*应用程序研讨会流程*部分，修改标准流程以满足您的用例需求。
1. 保存应用程序优先级排序运行手册。
1. 在应用程序优先级排序运行手册中维护该流程。在举办应用程序研讨会时，您可能会确定要对此流程进行哪些更改。
### 步骤退出标准
+ 您已经定义了研讨会的议程以及支持研讨会所需的资源和工件。
+ 您已经定义了研讨会的预期结果，并确定了需要在研讨会上收集的信息。
+ 您已经试用了研讨会流程，并获得了支持应用程序映射和设计目标状态所需的信息。
+ 您已在应用程序优先级排序运行手册中记录了以下内容：
+ 应用研讨会的预期成果
+ 应用程序研讨会规则
+ 申请研讨会流程
## 步骤 2：定义应用程序映射过程
*应用程序映射*是将每个应用程序分配到迁移模式的过程，您在中识别并验证了迁移模式[步骤 4：验证迁移模式](discovery.md#discovery-4)。在此步骤中，您将定义用于评估应用程序的规则。然后，您可以定义用于评估每个应用程序的流程。将每个应用程序映射到迁移模式的用例可以帮助您确定迁移工具、完成迁移所需的任何技能以及迁移模式的复杂性。
您并不总是将应用程序迁移到单一模式。有关何时可能需要为同一个应用程序使用多个模式的更多信息，请参阅本节[定义应用程序映射过程](#deep-dive-2-process)后面的部分。
### 应用程序映射规则
应用程序映射规则可帮助您评估应用程序并确定适当的迁移模式。每条规则都包含您应该用来评估应用程序和匹配模式标准的所有信息。
在[产品组合手册模板](samples/portfolio-playbook-templates.zip)中，*用于确定应用程序优先级的 Runbook 模板包括一个用于记录应用程序*映射规则的部分。按如下方式定义您的流程：
1. 打开您的应用程序优先级排序操作手册。
1. 在*应用程序映射规则*部分，定义您的应用程序映射规则。
1. 保存应用程序优先级排序运行手册。
1. 维护应用程序优先级排序运行手册中的规则。
下表提供了应用程序映射规则的示例。
**注意**
此表中的模式 IDs 和名称对应于中的样本模式[步骤 4：验证迁移模式](discovery.md#discovery-4)。使用您在应用程序优先级排序运行手册中定义的模式 IDs 和名称。
****
| 优先级 | 映射规则 |
| --- | --- |
| 1 | 使用利用率数据或监控工具，确定应用程序是僵尸应用程序还是空闲应用程序。如果应用程序是僵尸应用程序或空闲应用程序，请选择*模式 8：停用该应用程序*，然后关闭应用程序堆栈中的服务器。 |
| 2 | 确定将此应用程序迁移到云端是否能带来商业价值。仅在内部使用且不跨分支机构或地理位置共享的应用程序（例如考勤和考勤应用程序）通常不需要迁移到云端。如果迁移此应用程序不能提供商业价值，请选择*模式 9：在本地保留*。 |
| 3 | 确定应用程序的操作系统 (OS) 是否受 AWS 迁移服务 AWS、供应商或您的重新托管迁移工具的支持，然后执行以下操作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 4 | 确定应用程序是否具有软件即服务 (SaaS) 版本或同等版本，然后评估迁移到这个新平台的收益和成本。如果满足这些标准，请选择*模式 10：回购并升级到 SaaS*。 |
| 5 | 确定应用程序的本地数据库是否可以迁移到云中的同构服务，例如将本地 Oracle 数据库迁移到 Amazon RDS for Oracle，或者将本地 MySQL 数据库迁移到兼容 Amazon Aurora MySQL 的版本数据库。如果满足这些标准，则使用*模式 2：使用 AWS DMS 和 AWS SCT重定向到 Amazon RDS*。 |
| 6 | 确定应用程序是使用微软.NET Core（.NET 5 或.NET 6）、Java、PHP 还是其他开源编程语言，以及应用程序是否托管在微软 Windows Server 中。评估平台重塑的成本是否合理。如果满足这些标准，请选择*模式 7：在 Amazon EC2 上将平台从 Windows 迁移到 Linux*。 |
| 7 | 确定您的应用程序所依赖的本地和共享文件存储，然后确定是否必须将其包含在迁移中。如果必须迁移本地和共享文件存储，请选择*模式 4：使用 AWS DataSync 或 AWS Transfer Family将平台重新部署到 Amazon EFS*。 |
| 8 | 确定应用程序的服务器是大型机还是中端服务器，例如 IBM AS/400 或 Apache Spark，并确认应用程序与仿真器兼容。如果满足这些标准，请使用*模式 6：使用仿真器将大型机或中端服务器重新平台到 Amazon EC2*。 |
| 9 | 确定这是传统的、单片的还是基于大型机的应用程序，由于其局限性而无法再满足业务需求。例如，确定应用程序是否可以扩展、与相关应用程序集成，或者成本高昂且难以维护。如果应用程序符合这些条件中的任何一个，请选择*模式 11：重新架构应用程序*。 |
### 定义应用程序映射过程
在将应用程序映射到迁移模式时，向发现团队请求应用程序的发现数据会很有帮助。这些数据通常包括建议的迁移模式（有时称为 *R 模式或 R* *分数*）、利用率信息、应用程序依赖关系等信息，以及您可以在评估中使用的其他信息。在详细探索此应用程序时，您可能会决定更改先前确定的迁移模式。
获得数据后，您可以将应用程序与您在中确定的业务和技术标准进行比较[第 2 步：确定业务和技术驱动因素](discovery.md#discovery-2)。您在应用程序优先级排序运行手册中记录了驱动程序。根据标准评估应用程序可能会导致您为应用程序选择多种迁移模式，或者可能导致您消除基于成本、时间表或其他限制的模式。
以下是业务驱动因素的示例，它要求您在单个应用程序上使用多种迁移模式。您想将本地 SQL Server 数据库迁移到 Amazon DynamoDB，但由于数据中心的合同即将到期，因此企业希望在建议的时间表之前提前迁移该数据库，以便对其进行平台重组。为了解决这一业务驱动因素，您需要将应用程序的迁移计划修改为两种模式的方法。首先，将应用程序重新托管到云中，以便将其从数据中心移除。稍后，在应用程序进入云端后，您可以根据建议的时间表对其进行重新平台。
您还应该考虑该应用程序是否是 n 层应用程序，即由多个层组成的应用程序。*应用程序层*是一组托管应用程序水平层的物理服务器。N 层应用程序更为复杂，因为每个层级可能需要不同的策略，而且您可能会选择以不同的浪潮迁移应用程序层。例如，如果您的应用程序由演示层、业务服务和数据库层组成，则有可能为每个层映射不同的模式。
然后，根据您在应用程序优先级划分运行手册中定义的应用程序映射规则，对应用程序进行评估。有关更多信息，请参阅本部分前面的[应用程序映射规则](#deep-dive-2-rules)。
将应用程序映射到一个或多个模式后，请与应用程序所有者一起查看并验证此决定。应用程序所有者应确认所选模式，他们应帮助您规划和执行迁移。此时，应用程序所有者还可以根据自己的经验提供见解，或者分享他们在迁移中预期的任何问题。
将应用程序映射到一个或多个迁移模式并与应用程序所有者确认模式后，可以在应用程序优先级排序运行手册的应用程序映射表中记录应用程序、模式 ID、模式名称和相关驱动程序。
在[产品组合手册模板](samples/portfolio-playbook-templates.zip)中，*用于确定应用程序优先级的 Runbook 模板包括应用程序*映射的标准 step-by-step流程。按如下方式定义您的流程：
1. 打开您的应用程序优先级排序操作手册。
1. 在*应用程序研讨会流程*部分，修改标准流程以满足您的用例需求。
1. 保存应用程序优先级排序运行手册。
1. 在应用程序优先级排序运行手册中维护该流程。
下表是示例应用程序映射表。提供的*用于应用程序优先级划分的 Runbook 模板*包括一个空表，您可以在其中记录应用程序映射过程的结果。
**注意**
此表中的模式 IDs 和名称对应于中的样本模式[步骤 4：验证迁移模式](discovery.md#discovery-4)。使用您在应用程序优先级排序运行手册中定义的模式 IDs 和名称。
****
| 应用程序名称 | 图案标识 | 模式名称 | 解决了业务和技术驱动因素 |
| --- | --- | --- | --- |
| 企业网站 | 1 | 使用应用程序迁移服务或云迁移工厂重新托管到 Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 人力资源系统 | 8 | 停用应用程序 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 考勤申请 | 9 | 在本地保留 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| PO 系统 | 3 | 使用平台重定向 Amazon EC2 CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 客户关系管理系统 | 10 | 回购并升级到 SaaS | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 固定资产系统 | 7 | 在亚马逊 EC2 上将平台从 Windows 迁移到 Linux | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| ERP 文件存储 | 4 | 使用或将平台重定向 Amazon EFS AWS DataSync AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 账本系统 | 6 | 使用模拟器将大型机或中端服务器重新托管到 Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 总账本 | 11 | 重新架构应用程序 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### 步骤退出标准
+ 您已在应用程序优先级排序运行手册中记录了以下内容：
+ 应用程序映射规则
+ 应用程序映射过程
+ 您已使用一个或多个 proof-of-concept (POC) 应用程序验证了映射规则和流程。
## 步骤 3：（可选）定义应用程序目标状态
在此步骤中，您将定义用于记录应用程序的目标状态或目标状态*的*属性和流程。目标状态是迁移后应用程序在目标云环境中的运行方式。目标环境因您的目标平台或服务以及业务需求而异。目标环境可能是 AWS Cloud 或 AWS Managed Services (AMS)。
定义目标状态有助于项目经理、迁移顾问、架构师、应用程序所有者和利益相关者有效地协作。通过使用此流程，团队可以提前识别和解决问题，并更有效地实施目标状态环境。
对于某些应用程序，此步骤是可选的。如果您要迁移的应用程序是独立的或复杂性较低的，则可以跳过此步骤。不修改应用程序的迁移策略（例如重新托管）可能不需要执行此步骤。但是，对于更复杂的迁移策略，例如重新平台和重新架构，您应该在开始迁移之前定义目标状态。
研讨会让你深入了解应用程序的当前状态，因此最好在完成研讨会后起草目标状态。此外，将应用程序映射到其迁移模式可以提供更多见解，并帮助您确定是否需要定义目标状态。例如，如果您*使用应用程序迁移服务或云迁移工厂将应用程序映射到模式重新托管到 Amazon EC2*，则您已确定策略是重新托管，并且您可能不需要为此应用程序定义目标状态。
### 目标状态属性
在定义目标状态和做出有关应用程序的决策时，我们建议您考虑以下目标状态属性：
+ **AWS Well-Architected Tool**— 对照 Well-Architect AWS ed Framework 查看应用程序目标状态，以帮助提高云端应用程序的安全性、性能和弹性。
+ **目标着陆区** — 通常，在[动员阶段](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html)结束时，你应该已经建成一个可以运行试点应用程序的完整着陆区。landing zone 应该已经配置了多账户架构、身份和访问管理、治理、数据安全、网络设计和日志记录。您可以使用试点应用程序来验证 landing zone 是否已完成。验证您是否可以在现有目标着陆区启动和运行您的试点应用程序。如果您需要修改应用程序的着陆区，请将您的要求告知着陆区团队。例如，您的应用程序可能需要访问托管在单独账户中的服务，或者您的应用程序可能需要特殊路由到虚拟私有云 (VPC)。
+ **依赖关系**-确定您的应用程序为正常运行而依赖的所有应用程序。例如，您的应用程序可能依赖于数据库、存储或第三方服务，例如支付网关或外部 Web 服务，或者您的应用程序可能依赖于环境中的其他应用程序。为了访问这些依赖关系，您可能需要特殊的路由或配置，例如连接到目录服务进行身份验证。
+ **依赖应用程序**-识别依赖您的应用程序才能正常运行的所有应用程序。您可能需要重新配置和更新这些应用程序，以防止迁移期间出现停机。
+ **安全与合规性**-与安全与合规团队一起审查目标环境，并找出任何差距。应用程序可能由多个组件、逻辑层或多个层组成。根据您的合规性要求，您可能无法将其中一些组件迁移到目标环境，或者在迁移工作负载时可能需要额外的安全措施。常见的安全和合规要求包括数据驻留、传输中的加密和静态加密。这些需要在目标环境中进行额外的配置。例如，您可能需要配置证书以保护通信，或者可能需要加密密钥来保护静态数据。您可能还需要为应用程序选择多种迁移模式，以便某些应用程序层保留在本地，而其他层则迁移到云中。
+ **存储依赖关系**-检查您的应用程序存储依赖关系，并确定将应用程序迁移到目标环境将如何影响这些依赖关系。例如，如果应用程序依赖网络存储，例如网络连接存储 (NAS) 或存储区域网络 (SAN)，则需要规划云中的存储服务，例如亚马逊简单存储服务 (Amazon S3) Simple Storage Service 或 Amazon。 FSx您还需要计划如何将数据迁移到目标云环境，以保持应用程序的运行。
+ **数据库**-查看应用程序使用的任何数据库的迁移策略。您是否打算重新使用新的数据库服务，例如亚马逊关系数据库服务（Amazon RDS）、亚马逊 Aurora 或 Amazon DynamoDB？ 您打算在目标环境中重新托管数据库吗？ 在某些情况下，特别是对于单体数据库，您需要重构数据库以满足技术要求，例如亚秒级延迟，或者利用特定类型数据库的功能。 AWS 与数据驻留合规性要求一样，您需要确定哪些数据应保留在本地，哪些应迁移到云端。例如，您可能需要为客户信息保留本地数据库表，然后可以将数据库的其余部分迁移到云端。
+ **应用程序组件**-查看您的应用程序所依赖的组件。确定您的应用程序是否依赖于目标环境不支持的组件。如果目标环境不支持所有应用程序组件，则需要重构应用程序以缓解问题。例如，如果您的.NET Framework 应用程序依赖于仅限 Windows 的组件，例如组件对象模型 (COM) Interop、COM\+ 或 Windows 注册表，则要在 Linux 操作系统上重新构建该应用程序，则必须将该应用程序重构为.NET Core。
+ **应用程序层**-确定应用程序中的层数。应用程序是 n 层、双层还是独立应用程序？ 确认您了解每个层的迁移模式。例如，您的应用程序可能具有托管用户界面的演示（或 *Web*）层、托管业务服务的应用程序层和托管数据库的数据库层，每个层可能需要不同的迁移模式。
+ **灾难恢复**-确定应用程序的当前和未来状态灾难恢复 (DR) 计划，包括恢复点目标 (RPO) 和恢复时间目标 (RTO)。决定是使用现有的本地灾难恢复计划，还是探索新的云端灾难恢复策略。有关更多信息，请参阅《*工作负载[灾难恢复 AWS：云端恢复》白皮书中的 “云中的灾难恢复选项](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)[” 和 “恢复目标（RTO 和 RPO）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo)”* 部分。
### 定义目标状态进程
要定义应用程序目标状态，我们建议您使用提供的模板*应用程序目标状态工作表*（Excel 格式），该工作表可在[投资组合剧本模板](samples/portfolio-playbook-templates.zip)中找到。该模板包含您可以使用或修改的标准属性。定义记录应用程序目标状态的流程，如下所示：
1. 打开 “*应用程序目标状态” 工作表*。
1. 查看默认属性并根据您的用例进行任何更改。
1. 保存工作表。
1. 打开您的应用程序优先级排序操作手册。
1. 在 “*目标应用程序状态*” 部分中，执行以下操作：
1. 在 “*何时完成此流程*” 部分中，制定标准，使项目组合团队能够确定是否需要定义应用程序的目标状态。
1. 根据需要更新属性部分。
1. 根据您的用例的需要更新流程部分。
1. 保存应用程序优先级排序运行手册。
#### 应用程序目标状态示例
下表显示了如何使用*应用程序目标状态*工作表记录应用程序的目标状态的示例。
****
| 应用程序 | 示例 |
| --- | --- |
| **目标平台** | AWS Cloud |
| **登录区** | 需要访问本地目录服务
AWS Control Tower 需要集中管理整个组织的多个账户和服务 |
| **依赖关系** | 活动目录、支付网关、库存系统 |
| **依赖应用程序** | 无 |
| **安全性** | 静态和动态加密 |
| **合规** | PCI，SOC |
| **存储依赖关系** | 已连接启动驱动器、NAS、网络共享 |
| **数据库** | 当前：甲骨文数据库
云：适用于 Oracle 的 Amazon RDS |
| **应用程序组件** | .NET Framework 4.5 |
| **应用程序层** | N 级
前端、商业服务、数据服务和代理、数据库 |
| **灾难恢复** | RPO：1 分钟，RTO：5 分钟
当前的灾难恢复策略是热待机
美国任何地区的灾难恢复 |
### 步骤退出标准
+ 在*应用程序目标状态工作表中*，您已经定义了要包含在目标状态流程中的属性。
+ 在应用程序优先级排序运行手册中，您已完成以下操作：
+ 您已经为投资组合团队应在何时定义应用程序的目标状态制定了标准。
+ 您已经根据自己的用例更新了定义目标状态的流程。
## 第 4 步：完成应用程序深度研究流程
现在，您可以定义投资组合工作流如何使用您在本任务中建立的研讨会、规则和流程来深入研究应用程序。这是项目组合工作流在迁移的实施阶段所引用的流程。
在应用程序优先级划分运行手册中自定义此流程，如下所示：
1. 打开您的应用程序优先级排序操作手册。
1. 在 “第 *2 阶段：深入研究应用程序*” 部分，根据您的用例和环境修改流程。
1. 保存应用程序优先级排序运行手册。
1. 与团队共享您的应用程序优先级排序操作手册以供审阅。