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

# 详细的应用程序评估
<a name="detailed-application-assessment"></a>

详细的应用程序评估的目标是全面了解目标应用程序及其相关基础架构（计算、存储和网络）。高保真数据是避免陷阱所必需的。例如，组织通常会假设他们完全了解该应用程序。这是很自然的，在许多情况下也是如此。但是，为了最大限度地降低业务风险，必须通过尽可能多地获取计划数据来验证机构知识和静态文档。这将完成发现过程的繁重工作。您可以专注于来自其他来源的数据元素，例如特定于业务的信息、战略路线图等。

关键是要避免在迁移期间和迁移之后进行最后一刻的更改。例如，在迁移时，重要的是要避免基于未识别的依赖关系进行更改，因为这些更改可能需要将服务器纳入正在进行的迁移浪潮中。迁移后不久，重要的是要避免根据相关的平台要求进行更改，以允许流量或部署其他服务。这类计划外更改会增加出现安全和操作问题的风险。我们强烈建议在执行详细的应用程序评估时使用编程发现工具来验证流量模式和依赖关系。

在评估开始时，您必须确定应用程序的利益相关者。这些通常是以下内容：
+ 业务部门负责人
+ 应用程序所有者
+ 建筑师
+ 运营和支持
+ 云支持团队
+ 特定平台团队，例如计算、存储和网络

详细发现有两种方法。自上而下的发现从应用程序开始，甚至从用户开始，一直延伸到基础架构。当应用程序的标识很清楚时，推荐使用这种方法。相反，自下而上的发现从基础架构开始，一直延伸到应用程序或服务及其用户。当迁移计划由基础设施团队推动且 application-to-infrastructure映射不清楚时，这种方法非常有用。通常，您可能会将两者结合使用。

要深入研究应用程序，现有的架构图是一个不错的开端。如果这些都不可用，请根据当前知识创建一个。不要低估这项任务的重要性，即使对于简单的重新托管或搬迁迁移策略也是如此。绘制架构图可以帮助您识别低效问题，在云端进行细微更改即可快速解决这些问题。

根据您执行的是自上而下还是自下而上的方法，初始图表将绘制应用程序组件和服务或基础设施组件（例如服务器和负载均衡器）。识别出主要组件和接口后，使用发现工具和应用程序性能监控工具中的编程数据对其进行验证。这些工具必须支持依赖关系分析并提供组件之间的通信信息。必须标识构成此应用程序的每个组件。接下来，记录与其他应用程序和服务（包括内部和外部）的依赖关系。

由于缺乏用于验证依赖关系和映射的工具，因此需要手动方法。例如，您可以登录基础架构组件并运行脚本来收集通信信息，例如打开的端口和已建立的连接。同样，您可以识别正在运行的进程和已安装的软件。不要低估手动发现所需的精力。编程工具可以在几天内捕获并报告大多数依赖关系，但间隔较长（通常是很小的百分比）的依赖关系除外。手动发现可能需要数周时间才能收集和合并所有数据点，而且仍然很容易出现错误和数据丢失。

继续获取[数据要求](understanding-detailed-assessment-data-requirements.md)部分中为每个优先级应用程序和映射的基础架构指定的信息。接下来，使用以下问卷指导您完成详细的评估过程。与已确定的利益相关者会面，讨论这些问题的答案。

## General
<a name="general"></a>
+ 此应用程序的临界程度是多少？ 它能创造收入吗？ 它是业务战略应用程序还是支持业务应用程序？ 它是其他系统共享的核心基础设施服务吗？
+ 此应用程序是否有正在进行的改造项目？
+ 这是面向内部还是面向外部的应用程序？

## 架构
<a name="architecture"></a>
+ 当前的架构类型是什么（例如 SOA、微服务、整体架构）？ 架构有多少层？ 它是紧耦合还是松耦合？
+ 有哪些组件（例如，计算、数据库、远程存储、负载均衡器、缓存服务）？
+ 什么是 APIs？ 描述这些内容，包括 API 名称 URLs、操作、端口和协议。
+ 组件之间以及组件与其他应用程序或服务之间允许的最大延迟是多少？

## 操作
<a name="operations"></a>
+ 此应用程序在哪些位置运行？
+ 谁在运营应用程序和基础架构？ 这些是由内部团队还是 AWS 合作伙伴团队运营？
+ 如果此应用程序出现故障，会发生什么？ 谁受到影响？ 什么是影响？
+ 用户或客户在哪里？ 他们如何访问应用程序？ 并发用户数量是多少？
+ 上一次技术更新是什么时候？ 将来会安排更新吗？ 如果是，什么时候？
+ 此应用程序有哪些已知风险和问题？ 中断、中等严重程度和高严重性事件的历史如何？
+ 使用周期是多少（以工作时间为单位）？ 运营时区是什么？
+ 变更冻结期是多少？
+ 使用什么解决方案来监视此应用程序？

## 性能
<a name="performance"></a>
+ 收集的绩效信息显示了什么？ 使用量是尖峰还是恒定且可预测？ 可用性能数据的时间范围、间隔和日期是多少？
+ 是否有此应用程序的一部分或与之交互的定时批处理作业？

## 软件生命周期
<a name="software-lifecycle"></a>
+ 当前的变化率是多少（每周、每月、每季度或每年）？
+ 什么是开发生命周期（例如，测试、开发、QA、UAT、预生产、生产）？
+ 应用程序和基础架构的部署方法有哪些？ 
+ 什么是部署工具？ 
+ 此应用程序或基础架构是否使用持续集成 (CI) /持续交付 (CD)？ 自动化水平是多少？ 手动任务有哪些？
+ 应用程序和基础设施的许可要求是什么？
+ 什么是服务级别协议 (SLA)？
+ 目前的测试机制是什么？ 测试阶段是什么？

## 迁移
<a name="migration"></a>
+ 迁移注意事项有哪些？ 

此时，请注意迁移此应用程序时的所有注意事项。要获得更完整、更准确的评估，请从不同的利益相关者那里获得这个问题的答案。然后对比他们的知识和观点。

## 弹性
<a name="resiliency"></a>
+ 当前的备份方法是什么？ 哪些产品用于备份？ 备份时间表是什么？ 什么是备份保留政策？
+ 当前的恢复点目标 (RPO) 和恢复时间目标 (RTO) 是什么？
+ 此应用程序是否有灾难恢复 (DR) 计划？ 如果是，灾难恢复解决方案是什么？
+ 上一次灾难恢复测试是什么时候？

## 安全与合规
<a name="security-compliance"></a>
+ 适用于此应用程序的合规和监管框架有哪些？ 上次和下次审计日期是什么时候？
+ 此应用程序是否托管敏感数据？ 什么是数据分类？
+ 数据是在传输中加密还是静态加密，还是两者兼而有之？ 加密机制是什么？
+ 此应用程序是否使用 SSL 证书？ 什么是签发机构？ 
+ 用户、组件以及其他应用程序和服务的身份验证方法是什么？

## 数据库
<a name="databases"></a>
+ 此应用程序使用什么数据库？
+ 数据库的典型并发连接数是多少？ 最小连接数和最大连接数是多少？
+ 连接方法是什么（例如，JDBC、ODBC）？
+ 连接字符串是否记录在案？ 如果是，在哪里？
+ 数据库架构有哪些？
+ 数据库是否使用自定义数据类型？

## 依赖项
<a name="dependencies"></a>
+ 组件之间的依赖关系是什么？ 请注意任何无法解决且需要将组件一起迁移的依赖关系。
+ 组件是否在不同位置拆分？ 这些位置（例如，广域网、VPN）之间的连接如何？
+ 此应用程序与其他应用程序或服务有哪些依赖关系？
+ 操作依赖关系是什么？ 例如，维护和发布周期，例如修补窗口。