本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 了解初始評估資料需求
<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)，適用於全向商業案例，TCO 比較和包含遷移和現代化成本的定向商業案例需要
+ O，用於選用
+ N/A，適用於 不適用

**應用程式**


| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| --- |--- |--- |--- |--- |
| 唯一識別符 | 例如，應用程式 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | R (D) | 高 | 
| Application name (應用程式名稱) | 您的組織已知此應用程式的名稱。適用時包括商用off-the-shelf(COTS) 廠商和產品名稱。 | R | R (D) | 中高 | 
| 是 COTS 嗎？ | 是或否。無論是商業應用程式還是內部開發 | R | R (D) | 中高 | 
| COTS 產品和版本 | 商業軟體產品名稱和版本  | R | R (D) | 中 | 
| Description | 主要應用程式函數和內容 | R | O | 中 | 
| 重要性 | 例如，策略或產生收入的應用程式，或支援關鍵 函數 | R | O | 中高 | 
| Type | 例如，資料庫、客戶關係管理 (CRM)、Web 應用程式、多媒體、IT 共用服務 | R | O | 中 | 
| Environment | 例如，生產、生產前、開發、測試、沙盒 | R | R (D) | 中高 | 
| 合規與法規 | 適用於工作負載的架構 （例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP) 和法規要求 | R | R (D) | 中高 | 
| 相依性 | 對內部和外部應用程式或服務的上游和下游相依性。非技術相依性，例如操作元素 （例如維護週期） | O | O | 中低 | 
| 基礎設施映射 | 映射到組成應用程式的實體和/或虛擬資產 | O | O | 中 | 
| 授權 | 商品軟體授權類型 （例如 Microsoft SQL Server Enterprise) | O | R | 中高 | 
| Cost | 軟體授權、軟體操作和維護的成本 | N/A | O | 中 | 

**基礎設施**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| 唯一識別符 | 例如，伺服器 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | R | 高 | 
| 網路名稱 | 網路中的資產名稱 （例如主機名稱） | R | O | 中高 | 
| DNS 名稱 （完整網域名稱，或 FQDN) | DNS 名稱 | O | O | 中 | 
| IP 地址和網路遮罩 | 內部和/或公有 IP 地址 | R | O | 中高 | 
| 資產類型設定 | 實體或虛擬伺服器、Hypervisor、容器、裝置、資料庫執行個體等。 | R | R | 中高 | 
| 產品名稱 | 商業廠商和產品名稱 （例如 VMware ESXi、IBM Power Systems、Exadata) | R | R | 中 | 
| 作業系統 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 中高 | 
| Configuration | 配置的 CPU、核心數量、每個核心的執行緒、總記憶體、儲存、網路卡 | R | R | 中高 | 
| 使用率 | CPU、記憶體和儲存峰值和平均值。資料庫執行個體輸送量。 | R | O | 中高 | 
| 授權 | 商品授權類型 （例如 RHEL Standard) | R | R | 中 | 
| 是共用基礎設施嗎？ | 是或否表示提供共用服務的基礎設施服務，例如身分驗證提供者、監控系統、備份服務和類似服務 | R | R (D) | 中 | 
| 應用程式映射 | 在此基礎設施中執行的應用程式或應用程式元件 | O | O | 中 | 
| Cost | 裸機伺服器的完全負載成本，包括硬體、維護、操作、儲存 (SAN、NAS、物件）、作業系統授權、機架空間共用和資料中心額外負荷 | N/A | O | 中高 | 

**網路**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| 管道大小 (Mb/s)、備援 (Y/N) | 目前的 WAN 連結規格 （例如，1000 Mb/s 備援） | O | R | 中 | 
| 連結使用率 | 尖峰和平均使用率、傳出資料傳輸 (GB/月） | O | R | 中 | 
| 延遲 （毫秒） | 連線位置之間的目前延遲。 | O | O | 中 | 
| Cost | 每月的目前成本 | N/A | O | 中 | 

**移轉**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的擬真度等級 （最低）** | 
| 重新託管 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、客戶和合作夥伴每天成本、工具成本、工作負載數量 | N/A | R (F) | 中高 | 
| 平台重建 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、每天的客戶和合作夥伴成本、工作負載數量 | N/A | R (F) | 中高 | 
| 重構 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、每天的客戶和合作夥伴成本、工作負載數量 | N/A | O | 中高 | 
| 淘汰 | 伺服器數量、平均除役成本 | N/A | O | 中高 | 
| 登陸區域 | 重複使用現有的 （是/否）、所需的 AWS 區域清單、成本 | N/A | R (F) | 中高 | 
| 人員和變更 | 要在雲端營運和開發中訓練的員工人數、每個人的訓練成本、每個人的訓練時間成本 | N/A | R (F) | 中高 | 
| 持續時間 | 範圍內工作負載遷移的持續時間 （月） | O | R (F) | 中高 | 
| 平行成本 | 在遷移期間可以移除現狀成本的時間範圍和速率 | N/A | O | 中高 | 
| 在遷移期間引入 AWS 產品和服務和其他基礎設施成本的時間範圍和速率 | N/A | 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 個月。不過，缺少探索工具通常會導致更高的手動工作量和內部成本。

*支援模型*
+ 預設會提供哪些層級的支援？ 
+ 是否有任何可用的支援計畫？ 
+ 事件回應時間為何？

*專業服務*
+ 供應商是否提供專業服務來分析探索輸出？ 
+ 它們可以涵蓋本指南的元素嗎？ 
+ 工具 \+ 服務是否有任何折扣或套件？

**提示**  
若要尋找和評估探索工具，請使用[探索、規劃和建議](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)網站。

*探索工具的建議功能*

為了避免隨著時間的推移佈建和合併來自多個工具的資料，探索工具應涵蓋下列最低功能：
+ **軟體** – 探索工具應該能夠識別執行中的程序和已安裝的軟體。
+ **相依性映射** – 它應該能夠收集網路連線資訊，並建置伺服器和執行中應用程式的傳入和傳出相依性映射。此外，探索工具應該能夠根據通訊模式從基礎設施群組推斷應用程式。
+ **設定檔和組態探索** – 它應該能夠報告基礎設施設定檔，例如 CPU 系列 （例如 x86、PowerPC)、CPU 核心數量、記憶體大小、磁碟數量和大小，以及網路介面。
+ **網路儲存探索** – 它應該能夠從網路連接儲存 (NAS) 偵測和描述網路共用。
+ **效能** – 它應該能夠報告 CPU、記憶體、磁碟和網路的峰值和平均使用率。
+ **差距分析** – 它應該能夠提供有關資料數量和保真度的洞察。
+ **網路掃描** – 它應該能夠掃描網路子網路並探索未知的基礎設施資產。
+ **報告** – 它應該能夠提供收集和分析狀態。
+ **API 存取** – 它應該能夠提供以程式設計方式存取收集的資料。

*要考慮的其他功能*
+ **TCO 分析**可提供目前現場部署成本和預計 AWS 成本之間的成本比較。
+ 在重新託管和轉換案例中，Microsoft SQL Server 和 Oracle 系統的**授權分析和最佳化建議**。
+ **遷移策略建議** （探索工具是否可以根據目前的技術提出預設遷移 R 類型建議？)
+ **庫存匯出** （至 CSV 或類似格式）
+ **正確調整大小的建議 **（例如，它是否可以對應建議的目標 AWS 基礎設施？)
+ **相依性視覺化** （例如，是否可以在圖形模式中視覺化相依性映射？)
+ **架構檢視** （例如，是否可以自動產生架構圖？)
+ **應用程式優先順序 **（是否可以為應用程式和基礎設施屬性指派權重或相關性，以建立遷移的優先順序條件？)
+ **波浪規劃** （例如，建議的應用程式群組和建立遷移波浪計劃的能力）
+ **遷移成本估算 **（遷移的工作量估算）

*部署考量*

在您選取並取得探索工具之後，請考慮下列問題，以推動與負責在組織中部署工具的團隊進行對話：
+ 伺服器或應用程式是否由第三方操作？ 這可能會要求團隊參與並遵循程序。
+ 取得部署探索工具的核准之高階程序是什麼？
+ 存取伺服器、容器、儲存和資料庫等系統的主要身分驗證程序是什麼？ 伺服器登入資料是本機還是集中式？ 取得登入資料的程序為何？ 需要登入資料才能從您的系統收集資料 （例如容器、虛擬或實體伺服器、Hypervisor 和資料庫）。為探索工具取得憑證以連線至每個資產可能具有挑戰性，尤其是當這些資產未集中時。
+ 什麼是網路安全區域大綱？ 網路圖表是否可用？
+ 在資料中心請求防火牆規則的程序是什麼？
+ 與資料中心操作 （探索工具安裝、防火牆請求） 相關的目前支援服務層級協議 (SLAs) 是什麼？