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

# 詳細的應用程式評估
<a name="detailed-application-assessment"></a>

詳細的應用程式評估目標是完全了解目標應用程式及其相關聯的基礎設施 （運算、儲存和網路）。為了避免陷阱，高保真度資料是必要的。例如，組織通常會假設他們完全了解應用程式。這是自然的，在許多情況下也是如此。不過，為了將業務風險降至最低，請務必盡可能取得程式設計資料來驗證機構知識和靜態文件。這將處理探索程序的繁重工作。您可以專注於來自替代來源的資料元素，例如業務特定資訊、策略藍圖等。

關鍵是避免遷移期間和之後的最後一分鐘變更。例如，遷移時，請務必避免根據無法識別的相依性進行變更，這些相依性可能需要將伺服器包含在持續的遷移波中。遷移後不久，請務必避免根據相關聯的平台需求進行變更，以允許流量或部署其他服務。這些類型的意外變更會增加安全和操作問題的風險。我們強烈建議在執行詳細的應用程式評估時，使用程式設計探索工具來驗證流量模式和相依性。

在評估開始時，您必須識別應用程式利益相關者。這些通常如下：
+ 業務單位主管
+ 應用程式擁有者
+ 架構師
+ 操作和支援
+ 雲端啟用團隊
+ 特定的平台團隊，例如運算、儲存和網路

有兩種方法可進行詳細探索。由上而下探索從應用程式開始，甚至從使用者開始，一路向下到基礎設施。這是明確識別應用程式時的建議方法。相反地，由下而上的探索從基礎設施開始，一路延伸到應用程式或服務及其使用者。當遷移計劃由基礎設施團隊驅動，以及application-to-infrastructure映射不清楚時，這種方法很有用。一般而言，您可能會使用兩者的組合。

若要深入探索應用程式，現有的架構圖是很好的開始。如果這些不可用，請根據目前的知識建立一個。請勿低估此任務的重要性，即使是簡單的重新託管或重新放置遷移策略也一樣。繪製架構圖可協助您識別在雲端中發生細微變更時可以快速解決的效率低下問題。

根據您是否執行由上而下或由下而上的方法，初始圖表將繪製應用程式元件和服務或基礎設施元件，例如伺服器和負載平衡器。識別主要元件和界面之後，請使用探索工具和應用程式效能監控工具中的程式設計資料進行驗證。這些工具必須支援相依性分析，並提供元件之間的通訊資訊。必須識別構成此應用程式的每個元件。接下來，記錄對其他應用程式和服務的相依性，包括內部和外部。

如果缺少驗證相依性和映射的工具，則需要手動方法。例如，您可以登入基礎設施元件並執行指令碼來收集通訊資訊，例如開放連接埠和已建立的連線。同樣地，您可以識別執行中的程序和已安裝的軟體。請勿低估手動探索所需的工作量。程式設計工具可以在幾天內擷取和報告大多數相依性，但間隔較大的相依性除外 （通常為小百分比）。手動探索可能需要數週的時間來收集和合併所有資料點，而且仍然容易發生錯誤和遺失資料。

繼續取得每個優先應用程式和映射基礎設施[的資料需求](understanding-detailed-assessment-data-requirements.md)區段中指定的資訊。接著，使用以下問卷引導您完成詳細的評估程序。與已識別的利益相關者會面，討論這些問題的答案。

## 一般
<a name="general"></a>
+ 此應用程式的關鍵程度為何？ 是否產生營收？ 這是商業策略還是支援業務應用程式？ 這是其他系統共用的核心基礎設施服務嗎？
+ 此應用程式是否有任何持續的轉換專案？
+ 這是面向內部或外部的應用程式？

## Architecture
<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) 計劃？ 若是如此，什麼是 DR 解決方案？
+ 上次 DR 測試是何時？

## 安全和合規
<a name="security-compliance"></a>
+ 適用於此應用程式的合規和法規架構有哪些？ 上次和下一個稽核日期為何？
+ 此應用程式是否託管敏感資料？ 什麼是資料分類？
+ 資料是傳輸中還是靜態，還是兩者同時加密？ 什麼是加密機制？
+ 此應用程式是否使用 SSL 憑證？ 什麼是發行授權機構？ 
+ 使用者、元件和其他應用程式和服務的身分驗證方法是什麼？

## 資料庫
<a name="databases"></a>
+ 此應用程式使用哪些資料庫？
+ 與資料庫並行連線的典型數量是多少？ 連線數量下限和上限是多少？
+ 什麼是連線方法 （例如 JDBC、ODBC)？
+ 是否記錄連線字串？ 如果是，在哪裡？
+ 什麼是資料庫結構描述？
+ 資料庫是否使用自訂資料類型？

## 相依性
<a name="dependencies"></a>
+ 元件之間的相依性為何？ 請注意，任何無法解析且需要將元件遷移到一起的相依性。
+ 元件是否跨位置分割？ 這些位置之間的連線為何 （例如 WAN、VPN)？
+ 此應用程式與其他應用程式或服務有何相依性？
+ 什麼是操作相依性？ 例如，維護和發行週期，例如修補時段。