設計階段的最佳實務 - AWS 方案指引
建立交付時間表和景觀圖了解區域服務和文件決策建立命名慣例記錄所有決策

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

設計階段的最佳實務

綠地 SAP 實作的設計階段是建置階段成功的基礎。在此階段中，您會與基礎設施利益相關者合作，收集需求並記錄架構。您還必須考慮其他事項。必須確保各種專案利益相關者就時間表、總體策略和 SAP on AWS 架構達成共識，包括高可用性 (HA) 和災難復原 (DR) 環境。本節提供了解決專案設計階段可能遇到的一些挑戰的建議。

建立交付時間表和景觀圖

與您共用業務轉型專案時間表後，應立即建立基礎設施交付時間表。這有助於您提前規劃並在基礎設施團隊內保持一致。用於建置時間表的主要輸入來自 SAP 專案團隊的系統整合商 (SI)。回溯以取得 SAP Basic 團隊應該完成其工作的日期，以及基礎設施應準備好讓 SAP Basis 團隊安裝 SAP 應用程式的日期。

考量：

  • 交付時間表的可視化展示可讓團隊快速了解正在建置的內容、需求日期以及可能的資源衝突。它還允許關鍵利益相關者以易於理解的方式視覺化正在建置的環境、專案的持續時間，以及 AWS 和 SAP Basis 團隊之間的交接。

    SAP on AWS Greenfield 專案的交付時間表。

  • 典型的綠地 SAP 實作需要一年或更長時間。它包括基礎設施團隊沒有主動建置基礎設施元件的時間，因此請務必考慮這段時間的活動和可交付成果。要對應的活動範例包括 HA 設定和測試、DR 設定和測試、效能測試以及樓宇自動化指令碼。

  • 在綠地實作中，景觀和環境的概念可能會令人困惑，難以理解。區分環境與景觀 (N、N+1、N+2) 的彩色編碼時間表可協助利益相關者快速了解此資訊矩陣。

    以下是典型的高層級 SAP 景觀圖範例。這些方塊代表環境，它們是應用程式的集合 (例如，SAP S/4HANA)，而景觀則是用於特定版本的環境集合。

    SAP on AWS Greenfield 專案的景觀圖。

  • 當您建立藍圖時，我們建議您重新瀏覽高階藍圖，並每季執行長期規劃，直到團隊建立為止。除了遷移之外，還包含其他藍圖項目，例如雲端卓越中心 (CCoE) 的工作流、操作自動化、安全性和合規性，以及雲端災難復原。

了解區域服務和文件決策

在設計階段開始時，我們建議您花時間了解和討論特定 提供的服務， AWS 區域 以便正確選擇主要區域。具體而言，SAP 通常需要高效能執行個體，因此必須確保這些資源可在主要或次要區域中使用。選擇一個已通過認證可用於 SAP 應用程式的執行個體類型。確定執行個體類型在選擇的 AWS 區域 中可用。確定這一點的快速簡便方法是使用適用於執行個體類型方案的AWS Command Line Interface (AWS CLI) 命令。如果要用於實作的區域目前無法使用服務，請考慮為該區域訂購基礎設施的交付週期。

確認、再確認及記錄地區相關決策。在更大的專案團隊中公佈這些決策，以便關鍵利益相關者知悉。如果專案有架構審查委員會，請務必提出此主題，讓每個人都有機會在制定決策之前發表意見。

考量：

  • 一個關鍵的考量事項是與 SAP 整合的邊界系統。如果您要在 上託管邊界或衛星應用程式 AWS，最好在同一主要區域託管 SAP，以防止任何不必要的延遲討論。即使您確認延遲不是問題，也很難向利益相關者解釋為什麼邊界應用程式建置在與 SAP 應用程式不同的區域中。

  • 對於 SAP 和與 SAP 整合的系統，災難復原 (DR) 網站也應該相同，以便能夠實際地協調 DR 測試。不同的系統可能需要不同的解決方案。例如，BusinessObjects 或 Winshuttle 等大型 SAP 系統可能無法使用 ， AWS Elastic Disaster Recovery 並且可能需要使用 Amazon Relational Database Service (Amazon RDS) 資料庫的不同解決方案。

建立命名慣例

徹底審核和記錄主機、SAP 環境、虛擬私有雲端 (VPC) 和 AWS 帳戶的命名慣例。請務必遵循現有的標準或慣例。在綠地實作中，可能必須從頭開始定義命名慣例。保持一致。例如，如果您呼叫 VPC Pre-Prod、SAP 環境 UAT 和 AWS 帳戶 TST，從支援角度建立這三個名稱的關聯將會很困難。確保獲得共識並分配每個角色都有意義的名稱，但要保持靈活性。例如，請勿將區域名稱硬編碼為伺服器名稱，以防將來必須切換為其他區域。避免使用內部部署伺服器所使用的命名慣例。相反地，如果您的組織還沒有一個靈活的雲端命名慣例，建議使用它。

考量：

  • 對於可變更的資訊使用 AWS 標記。

  • 請勿將非生產環境置於生產 VPC 中。如果這是一個要求，請確保在同意之前有合理的理由。

記錄所有決策

建議您徹底記錄每個決策的每個變化，誰做出決策，在什麼日期，以及誰在場。將決策儲存在公共場所，例如 Atlassian Confluence 或試算表，並確保正確簽署決策。利益相關者或團隊成員可能會忘記達成的共識，並在稍後的設計或建置階段對決策提出質疑。如果發生這種情況，您會希望有現成的資料來解決任何問題。以下是要記錄的關鍵決策範例：

  • 區域決策

  • HA 相關的應用程式

  • 災難復原選項

  • 專案階段中的環境支援模型

  • 備份和還原方法以及工具

  • VPC 結構

  • AWS 帳戶決策

  • 安全決策

此外，追蹤所有產品功能請求，並記錄團隊實作變更所需的時間。