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

# 了解初始评估数据要求
<a name="understanding-initial-assessment-data-requirements"></a>

数据收集可能需要大量时间，当不清楚需要哪些数据以及何时需要数据时，数据收集很容易成为障碍。关键是要理解对于这个阶段的结果来说，什么是太少的数据和过多的数据之间的平衡。要专注于投资组合评估的早期阶段所需的数据和保真度，请采用迭代方法进行数据收集。

## 数据源和数据要求
<a name="data-sources-data-requirements"></a>

第一步是确定您的数据来源。首先确定组织内可以满足数据要求的关键利益相关者。他们通常是服务管理、运营、容量规划、监控和支持团队的成员，以及应用程序所有者。与这些小组的成员建立工作会议。沟通数据要求并获取可提供数据的工具和现有文档的列表。

要指导这些对话，请使用以下一组问题：
+ 当前基础架构和应用程序库存的准确性和最新性如何？ 例如，对于公司配置管理数据库 (CMDB)，我们是否已经知道差距在哪里？
+ 我们是否有活跃的工具和流程来保持 CMDB（或等效工具）的更新？ 如果是，它的更新频率有多高？ 最新的刷新日期是什么时候？
+ 当前清单（例如 CMDB）是否包含 application-to-infrastructure映射？ 每项基础设施资产是否都与应用程序相关联？ 每个应用程序是否都映射到基础架构？
+ 库存中是否包含每种产品的许可证和许可协议目录？
+ 清单中是否包含依赖关系数据？ 注意存在通信数据，例如服务器到服务器、应用程序到应用程序、应用程序或服务器到数据库。
+ 环境中还有哪些其他工具可以提供应用程序和基础架构信息？ 请注意是否存在可用作数据源的性能、监控和管理工具。
+ 托管我们的应用程序和基础设施的不同位置有哪些，例如数据中心？

回答完这些问题后，请列出您已识别的数据来源。然后为他们每个人分配一个忠诚度或信任级别。最近（30 天内）从活跃的程序来源（例如工具）中验证的数据具有最高的保真度。静态数据被认为保真度较低，可信度较低。静态数据的示例包括文档、工作簿、手动更新的 CMDBs数据或任何其他非编程维护的数据集，或者其上次刷新日期超过 60 天的数据集。

下表中的数据保真度级别仅作为示例。我们建议您评估组织对假设的最大容忍度以及相关风险的要求，以确定什么是适当的保真度。在表中，机构知识是指任何未记录在案的有关应用程序和基础设施的信息。


| **数据源** | **保真度等级** | **投资组合覆盖范围** | **注释** | 
| --- |--- |--- |--- |
| 机构知识 | 低-最多 25% 的准确数据、75% 的假设值或数据超过 150 天。 | 低 | 稀缺，专注于关键应用程序 | 
| 知识库 | 中低——35-40％的准确数据，65-60％的假设值或数据存在120-150天。 | 中 | 手动维护，细节层次不一致 | 
| CMDB | 中-大约 50% 的准确数据，大约 50% 的假设值或数据已存在 90-120 天。 | 中 | 包含来自混合来源的数据，多个数据缺口 | 
| VMware vCenter 导出 | 中高——75-80% 的准确数据，25-20% 的假设值或数据的存在时间为 60-90 天。 | 高 | 覆盖 90% 的虚拟化资产 | 
| 应用程序性能监控 | 高-大部分数据是准确的，假设值约为 5% 或数据已有 0-60 天的时间。 | 低 | 仅限于关键生产系统（占应用程序组合的 15%） | 

下表指定了每个资产类别（应用程序、基础架构、网络和迁移）、特定活动（清单或业务案例）的必需和可选数据属性，以及此评估阶段的建议数据保真度。这些表使用以下缩写：
+ R，表示必填项
+ (D)，用于方向性业务案例，需要进行总拥有成本 (TCO) 比较和定向业务案例
+ (F)，用于全方位业务案例，用于总体拥有成本比较和定向业务案例（包括迁移和现代化成本）
+ O，表示可选
+ 不适用，因为不适用

**应用程序**


| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| --- |--- |--- |--- |--- |
| 唯一标识符 | 例如，应用程序 ID。通常适用于现有 CMDBs或其他内部库存和控制系统。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R (D) | 高 | 
| 应用程序名称 | 您的组织知道此应用程序的名称。如果适用，请包括商业 off-the-shelf (COTS) 供应商和产品名称。 | R | R (D) | 中高 | 
| 是 COTS 吗？ | 是或否。 无论是商业应用程序还是内部开发 | R | R (D) | 中高 | 
| COTS 产品和版本 | 商用软件产品名称和版本  | R | R (D) | 中 | 
| 说明 | 主要应用程序功能和上下文 | R | O | 中 | 
| 严重性 | 例如，战略或创收应用程序，或支持关键功能 | R | O | 中高 | 
| Type | 例如，数据库、客户关系管理 (CRM)、Web 应用程序、多媒体、IT 共享服务 | R | O | 中 | 
| 环境 | 例如，生产、预制版、开发、测试、沙箱 | R | R (D) | 中高 | 
| 合规与监管 | 适用于工作负载的框架（例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP）和监管要求 | R | R (D) | 中高 | 
| 依赖项 | 内部和外部应用程序或服务的上游和下游依赖关系。非技术依赖关系，例如操作要素（例如维护周期） | O | O | 中低 | 
| 基础设施映射 | 映射到构成应用程序的物理 and/or 虚拟资产 | O | O | 中 | 
| 许可证 | 商用软件许可证类型（例如，微软 SQL Server Enterprise） | O | R | 中高 | 
| 成本 | 软件许可、软件操作和维护成本 | 不适用 | O | 中 | 

**基础设施**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| 唯一标识符 | 例如，服务器 ID。通常适用于现有 CMDBs 或其他内部库存和控制系统。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R | 高 | 
| 网络名称 | 网络中的资产名称（例如，主机名） | R | O | 中高 | 
| DNS 名称（完全限定域名或 FQDN） | DNS 名称 | O | O | 中 | 
| IP 地址和网络掩码 | 内部 and/or 公有 IP 地址 | R | O | 中高 | 
| 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 | O | 中高 | 
| 许可证 | 商品许可证类型（例如 RHEL 标准） | R | R | 中 | 
| 是共享基础架构吗？ | “是” 或 “否” 表示提供共享服务的基础架构服务，例如身份验证提供商、监控系统、备份服务和类似服务 | R | R (D) | 中 | 
| 应用程序映射 | 在此基础架构中运行的应用程序或应用程序组件 | O | O | 中 | 
| 成本 | 裸机服务器的满负荷成本，包括硬件、维护、操作、存储（SAN、NAS、Object）、操作系统许可证、机架空间份额和数据中心管理费用 | 不适用 | O | 中高 | 

**网络**


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

**迁移**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| 重新托管 | 客户和合作伙伴每项工作量（人日）、客户和合作伙伴每天的成本费率、工具成本、工作负载数量 | 不适用 | R (F) | 中高 | 
| 更换平台 | 客户和合作伙伴为每项工作负载付出的努力（人日）、客户和合作伙伴每天的成本费率、工作负载数量 | 不适用 | R (F) | 中高 | 
| 重构 | 客户和合作伙伴为每项工作负载付出的努力（人日）、客户和合作伙伴每天的成本费率、工作负载数量 | 不适用 | O | 中高 | 
| 停用 | 服务器数量，平均停用成本 | 不适用 | O | 中高 | 
| 登录区 | 重复使用现有的 (Y/N)、所需 AWS 区域列表、成本 | 不适用 | R (F) | 中高 | 
| 人与变革 | 接受云运营和开发培训的员工人数、每人培训成本、每人培训时间成本 | 不适用 | R (F) | 中高 | 
| Duration | 范围内工作负载迁移的持续时间（月） | O | R (F) | 中高 | 
| 并行成本 | 迁移期间可以消除原样成本的时间范围和比率 | 不适用 | O | 中高 | 
| 迁移期间推出 AWS 产品和服务的时间范围和速度以及其他基础设施成本 | 不适用 | O | 中高 | 

## 评估对发现工具的需求
<a name="discovery-tooling"></a>

您的组织需要发现工具吗？ 产品组合评估需要高度可信的应用程序和基础架构 up-to-date数据。投资组合评估的初始阶段可以使用假设来填补数据空白。

但是，随着进展的推进，高保真数据可以制定成功的迁移计划并正确估计目标基础架构，从而降低成本并最大限度地提高收益。它还通过启用考虑依赖关系的实施来降低风险，并避免迁移陷阱。云迁移计划中发现工具的主要用例是通过以下方式降低风险并提高数据的可信度：
+ 自动或编程数据收集，生成经过验证、高度可信的数据
+ 加快数据获取速度，提高项目速度并降低成本
+ 提高了数据的完整性，包括通信数据和依赖关系中通常不可用 CMDBs
+ 获取诸如自动应用程序识别、TCO 分析、预计运行率和优化建议等见解
+ 高可信度的迁移浪潮规划

当不确定系统是否存在于给定位置时，大多数发现工具可以扫描网络子网并发现那些响应 ping 或简单网络管理协议 (SNMP) 请求的系统。请注意，并非所有网络或系统配置都允许 ping 或 SNMP 流量。与您的网络和技术团队讨论这些选项。

应用程序组合评估和迁移的后续阶段在很大程度上依赖于准确的依赖关系映射信息。依赖关系映射可让您了解中所需的基础设施和配置 AWS （例如安全组、实例类型、账户放置和网络路由）。它还有助于对必须同时移动的应用程序（例如必须通过低延迟网络进行通信的应用程序）进行分组。此外，依赖关系映射为业务案例的发展提供了信息。

在决定使用发现工具时，重要的是要考虑评估过程的所有阶段并预测数据需求。数据缺口有可能成为障碍，因此通过分析未来的数据需求和数据源来预测这些缺口是关键。该领域的经验表明，大多数停滞不前的迁移项目都有一个有限的数据集，其中无法清楚地识别范围内的应用程序、相关的基础设施及其依赖关系。这种缺乏识别可能导致错误的指标、决策和延迟。获取 up-to-date数据是成功迁移项目的第一步。

*如何选择发现工具？*

市场上有几种发现工具提供了不同的特性和功能。考虑您的要求。然后决定最适合您的组织的选项。在决定迁移发现工具时，最常见的因素如下：

*安全性*
+ 访问工具数据存储库或分析引擎的身份验证方法是什么？ 
+ 谁可以访问数据，以及访问该工具的安全控制措施有哪些？ 
+ 该工具如何收集数据？ 它需要专用凭证吗？ 
+ 该工具需要什么凭证和访问级别才能访问我的系统和获取数据？ 
+ 如何在刀具组件之间传输数据？ 
+ 该工具是否支持静态和传输中的数据加密？ 
+ 数据是集中在我的环境内部还是外部的单个组件中？ 
+ 网络和防火墙要求是什么？ 

确保安全团队参与有关发现工具的早期对话。

*数据主权*
+ 数据存储和处理在哪里？ 
+ 该工具是否使用软件即服务 (SaaS) 模式？ 
+ 它是否有可能将所有数据保留在我的环境范围内？ 
+ 能否在数据离开我的组织边界之前对其进行筛选？ 

根据数据驻留要求考虑您的组织需求。

*架构*
+ 需要什么基础架构，有哪些不同的组件？
+ 是否有多个架构可用？ 
+ 该工具是否支持在气锁安全区域中安装组件？

*性能*
+ 数据收集对我的系统有什么影响？ 

*兼容性和范围*
+ 该工具是否支持我的全部或大部分产品和版本？ 查看工具文档，根据有关您的范围的当前信息来验证支持的平台。
+ 我的大多数操作系统是否支持数据收集？ 如果您不知道自己的操作系统版本，请尝试将发现工具列表的范围缩小到支持系统范围更广的版本。

*收集方法*
+ 该工具是否需要在每个目标系统上安装代理？
+ 它是否支持无代理部署？ 
+ 代理和无代理提供相同的功能吗？ 
+ 收款流程是怎样的？

*功能*
+ 有哪些可用的功能？ 
+ 它能否计算出总拥有成本 (TCO) 和估计的 AWS 云 运行率？ 
+ 它是否支持迁移规划？ 
+ 它能衡量绩效吗？ 
+ 它能否推荐目标 AWS 基础架构？ 
+ 它会执行依赖关系映射吗？ 
+ 它提供了什么级别的依赖关系映射？ 
+ 它是否提供 API 访问权限？ （例如，能否通过编程方式访问它来获取数据？）

考虑具有强大的应用程序和基础架构依赖关系映射功能的工具，以及那些可以从通信模式中推断出应用程序的工具。

*成本*
+ 许可模式是什么？ 
+ 许可费用是多少？ 
+ 是每台服务器的定价吗？ 是分层定价吗？ 
+ 是否有任何功能有限的选项可以按需授权？ 

发现工具通常用于迁移项目的整个生命周期。如果您的预算有限，请考虑至少 6 个月。但是，缺少发现工具通常会导致更高的手动工作量和内部成本。

*Support 模型*
+ 默认提供什么级别的支持？ 
+ 有支持计划吗？ 
+ 事件响应时间是多少？

*专业服务*
+ 供应商是否提供专业服务来分析发现结果？ 
+ 他们能否涵盖本指南的内容？ 
+ tooling \$1 服务有折扣或捆绑包吗？

**提示**  
要查找和评估发现工具，请使用[发现、规划和推荐](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)网站。

*发现工具的推荐功能*

为避免随着时间的推移配置和合并来自多个工具的数据，发现工具应涵盖以下最低功能：
+ **软件**-发现工具应该能够识别正在运行的进程和已安装的软件。
+ **依赖关系映射** — 它应该能够收集网络连接信息，并构建服务器和正在运行的应用程序的入站和出站依赖关系图。此外，发现工具应该能够根据通信模式从基础架构组中推断出应用程序。
+ **配置文件和配置发现** — 它应该能够报告基础架构配置文件，例如 CPU 系列（例如 x86、PowerPC）、CPU 核心数量、内存大小、磁盘数量和大小以及网络接口。
+ **网络存储发现** — 它应该能够检测和分析来自网络连接存储 (NAS) 的网络共享。
+ **性能**-它应该能够报告 CPU、内存、磁盘和网络的峰值和平均利用率。
+ **差距分析** — 它应该能够提供有关数据数量和保真度的见解。
+ **网络扫描** — 它应该能够扫描网络子网并发现未知的基础架构资产。
+ **报告** — 它应该能够提供收集和分析状态。
+ **API 访问权限** — 它应该能够提供编程方式来访问收集的数据。

*需要考虑的其他功能*
+ **TCO 分析**，用于对当前本地成本和预计 AWS 成本进行成本比较。
+ 在重新托管和平台方案中，为微软 SQL Server 和 Oracle 系统提供@@ **许可分析和优化建议**。
+ **迁移策略建议**（发现工具能否根据当前技术提出默认的迁移 R 类型建议？）
+ **库存导出**（格式为 CSV 或类似格式）
+ **合理调整规模的建议**（例如，它能否映射推荐的目标 AWS 基础架构？）
+ **依赖关系可视化**（例如，依赖关系映射能否在图形模式下可视化？）
+ **建筑视图**（例如，可以自动生成建筑图吗？）
+ **应用程序优先级**（它能否为应用程序和基础设施属性分配权重或相关性，以创建迁移的优先级标准？）
+ **波浪规划**（例如，推荐的应用程序组和创建迁移浪潮计划的能力）
+ **迁移成本估算**（迁移工作量估算）

*部署注意事项*

选择并购买了发现工具后，请考虑以下问题，以推动与负责在组织中部署该工具的团队的对话：
+ 服务器或应用程序是否由第三方运营？ 这可能决定要参与的团队和要遵循的流程。
+ 获得批准部署发现工具的高级流程是什么？
+ 访问服务器、容器、存储和数据库等系统的主要身份验证过程是什么？ 服务器凭证是本地的还是集中的？ 获取证书的流程是怎样的？ 需要凭据才能从您的系统（例如，容器、虚拟或物理服务器、虚拟机管理程序和数据库）收集数据。获取用于连接每项资产的发现工具的凭证可能具有挑战性，尤其是在这些资产未集中化的情况下。
+ 网络安全区域的轮廓是什么？ 网络图是否可用？
+ 在数据中心请求防火墙规则的流程是什么？
+ 当前与数据中心运营（发现工具安装、防火墙请求SLAs）相关的支持服务级别协议 () 是什么？