詳細的應用評估 - AWS 規範指南
一般架構作業效能软件生命周遷移彈性安全和合規資料庫相依性

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

詳細的應用評估

詳細應用程式評估的目標是完整瞭解目標應用程式及其相關基礎架構 (運算、儲存和網路)。高保真度數據是避免陷阱的必要條件。例如，組織通常會假設他們完全了解應用程序。這是很自然的，在許多情況下都是如此。但是，為了最大限度地減少對業務的風險，通過盡可能獲取程序數據來驗證機構知識和靜態文檔非常重要。這將負責發現過程的繁重工作。您可以專注於來自替代來源的資料元素，例如業務特定資訊、策略藍圖等。

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

在評估開始時，您必須確定應用程序利益相關者。這些通常如下：

  • 業務單位領導

  • 應用擁有者

  • 建築師

  • 營運與支援

  • 支援雲端的團隊

  • 特定平台團隊，例如運算、儲存和網路

有兩種方法可進行詳細的探索。由上而下的探索始於應用程式，甚至與使用者，並一直到基礎結構。當應用程序的識別清晰時，建議使用這種方法。相反地，由下而上的探索始於基礎結構，一直到應用程式或服務及其使用者。當移轉程式由基礎架構團隊驅動，以及 application-to-infrastructure對應不清楚時，此方法非常有用。通常，您可能會使用兩者的組合。

為了深入研究應用程序，現有的架構圖是良好的開始。如果這些不可用，請根據當前知識創建一個。不要低估此工作的重要性，即使是簡單的重新裝載或重新定位移轉策略也是如此。繪製建築圖可幫助您識別低效率問題，這些問題可以在雲中通過輕微的變化快速解決。

根據您執行的是由上而下還是由下而上的方法，初始圖表將繪製應用程式元件和服務或基礎架構元件 (例如伺服器和負載平衡器)。識別主要元件和介面之後，請使用探索工具和應用程式效能監視工具的程式化資料來驗證它們。這些工具必須支援相依性分析，並提供元件之間的通訊資訊。構成此應用程序的每個組件必須被識別。接下來，文件依賴於其他應用程序和服務，內部和外部。

如果沒有用於驗證依賴關係和映射的工具，則需要手動方法。例如，您可以登入基礎結構元件並執行指令碼來收集通訊資訊，例如開啟的連接埠和已建立的連線。同樣，您可以識別正在運行的進程和已安裝的軟件。不要低估手動發現所需的努力。程序化工具可以在幾天內捕獲並報告大多數依賴關係，但以較大的間隔（通常是很小的百分比）發生的依賴關係除外。手動探索可能需要數週的時間來收集和合併所有資料點，而且仍可能容易發生錯誤和資料遺失。

繼續取得每個優先順序應用程式和對應基礎結構的資料需求區段中指定的資訊。接下來，使用以下問卷來指導您完成詳細的評估過程。與已確定的利益相關者會面，討論這些問題的答案。

一般

  • 此應用程序的關鍵性級別是多少？ 它會產生收入嗎？ 它是商業策略還是支援商業應用程式？ 它是由其他系統共享的核心基礎架構服務嗎？

  • 這個應用程序是否有任何正在進行的轉換項目？

  • 這是一個面向內部還是外部的應用程序？

架構

  • 目前的架構類型是什麼 (例如，SOA、微服務、整體式)？ 該架構有多少層？ 它是緊密耦合還是鬆散耦合？

  • 哪些元件 (例如，運算、資料庫、遠端儲存、負載平衡器、快取服務)？

  • 什麼是 API？ 描述這些資訊，包括 API 名稱、作業、URL、連接埠和通訊協定。

  • 組件之間以及此應用程序或服務之間容忍的最大延遲是多少？

作業

  • 此應用程式在哪些位置運作？

  • 應用程式和基礎架構的運作是誰？ 這些是由內部團隊還是 AWS 合作夥伴團隊運營？

  • 如果此應用程序出現故障會發生什麼？ 誰會受到影響？ 有什麼影響？

  • 使用者或客戶位於何處？ 他們如何訪問應用程序？ 同時使用者的數量是多少？

  • 上一次技術更新是什麼時候？ future 是否排定重新整理？ 如果是這樣，什麼時候？

  • 此應用程序的已知風險和問題是什麼？ 中斷和中等嚴重程度和高嚴重性事件的歷史是什麼？

  • 什麼是使用週期（以工作時間計）？ 什麼是操作時區？

  • 什麼是變更凍結期？

  • 什麼解決方案用於監視此應用程序？

效能

  • 收集的效能資訊會顯示什麼？ 使用率高低還是恆定且可預測？ 可用成效資料的時間範圍、間隔和日期為何？

  • 是否有排程批次作業屬於此應用程式的一部分，或與此應用程式互動？

软件生命周

  • 目前的變動率 (每週、每月、每季或每年) 是多少？

  • 什麼是開發生命週期（例如，測試，開發，QA，UAT，預生產，生產）？

  • 什麼是應用程序和基礎設施的部署方法？

  • 什麼是部署工具？

  • 此應用程式或基礎架構是否使用持續整合 (CI)/持續交付 (CD)？ 什麼是自動化的水平？ 什麼是手動任務？

  • 應用程式和基礎架構的授權要求為何？

  • 什麼是服務等級協議 (SLA)？

  • 目前的測試機制是什麼？ 測試階段是什麼？

遷移

  • 有哪些移轉考量？

此時，請注意移轉此應用程式時的任何考量。要獲得更完整和準確的評估，請從不同的利益相關者那裡獲得此問題的答案。然後對比他們的知識和意見。

彈性

  • 目前的備份方法是什麼？ 備份使用哪些產品？ 備份時間表是什麼？ 什麼是備份保留政策？

  • 什麼是目前的復原點目標 (RPO) 和復原時間目標 (RTO)？

  • 這個應用程序是否有災難恢復（DR）計劃？ 如果是這樣，DR 解決方案是什麼？

  • 上一次 DR 測試是什麼時候？

安全和合規

  • 適用於此應用程序的合規性和監管框架是什麼？ 上次和下一個稽核日期是什麼？

  • 此應用程序是否託管敏感數據？ 什麼是數據分類？

  • 資料是否在傳輸過程中或靜態時加密，或兩者都加密？ 什麼是加密機制？

  • 此應用程序是否使用安全套接字層（SSL）證書？ 什麼是發行機構？

  • 使用者、元件以及其他應用程式和服務的驗證方法是什麼？

資料庫

  • 這個應用程序使用什麼數據庫？

  • 數據庫的典型並發連接數是多少？ 連線的最小數目和最大數目是多少？

  • 什麼是連接方法（例如，JDBC，ODBC）？

  • 連接字符串是否記錄？ 如果是這樣，在哪裡？

  • 什麼是數據庫模式？

  • 資料庫是否使用自訂資料類型？

相依性

  • 組件之間的依賴關係是什麼？ 請注意無法解析且需要一起遷移組件的任何依賴關係。

  • 元件是否會跨位置分割？ 這些位置 (例如 WAN、VPN) 之間的連線能力為何？

  • 這個應用程序與其他應用程序或服務的依賴關係是什麼？

  • 什麼是操作依賴關係？ 例如，維護和釋放週期，例如修補窗口。