本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 設計階段的最佳實務 綠地 SAP 實作的設計階段是建置階段成功的基礎。在此階段中，您會與基礎設施利益相關者合作，收集需求並記錄架構。您還必須考慮其他事項。必須確保各種專案利益相關者就時間表、總體策略和 SAP on AWS 架構達成共識，包括高可用性 (HA) 和災難復原 (DR) 環境。本節提供了解決專案設計階段可能遇到的一些挑戰的建議。 ## 建立交付時間表和景觀圖 與您共用業務轉型專案時間表後，應立即建立基礎設施交付時間表。這有助於您提前規劃並在基礎設施團隊內保持一致。用於建置時間表的主要輸入來自 SAP 專案團隊的系統整合商 (SI)。回溯以取得 SAP Basic 團隊應該完成其工作的日期，以及基礎設施應準備好讓 SAP Basis 團隊安裝 SAP 應用程式的日期。 考量： + 交付時間表的可視化展示可讓團隊快速了解正在建置的內容、需求日期以及可能的資源衝突。它還允許關鍵利益相關者以易於理解的方式視覺化正在建置的環境、專案的持續時間，以及 AWS 和 SAP Basis 團隊之間的交接。 ![SAP on AWS Greenfield 專案的交付時間表。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/sap-greenfield-implementations/images/timeline.png) + 典型的綠地 SAP 實作需要一年或更長時間。它包括基礎設施團隊沒有主動建置基礎設施元件的時間，因此請務必考慮這段時間的活動和可交付成果。要對應的活動範例包括 HA 設定和測試、DR 設定和測試、效能測試以及樓宇自動化指令碼。 + 在綠地實作中，景觀和環境的概念可能會令人困惑，難以理解。區分環境與景觀 (N、N\+1、N\+2) 的彩色編碼時間表可協助利益相關者快速了解此資訊矩陣。 以下是典型的高層級 SAP 景觀圖範例。這些方塊代表環境，它們是應用程式的集合 (例如，SAP S/4HANA)，而景觀則是用於特定版本的環境集合。 ![SAP on AWS Greenfield 專案的景觀圖。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/sap-greenfield-implementations/images/landscape.png) + 當您建立藍圖時，我們建議您重新瀏覽高階藍圖，並每季執行長期規劃，直到團隊建立為止。除了遷移之外，還包含其他藍圖項目，例如雲端卓越中心 (CCoE) 的工作流、操作自動化、安全性和合規性，以及雲端災難復原。 ## 了解區域服務和文件決策 在設計階段開始時，我們建議您花時間了解和討論特定 提供的服務， AWS 區域 以便正確選擇主要區域。具體而言，SAP 通常需要高效能執行個體，因此必須確保這些資源可在主要或次要區域中使用。選擇一個[已通過認證可用於 SAP 應用程式的執行個體類型](https://aws.amazon.com/sap/instance-types/)。確定執行個體類型在選擇的 AWS 區域 中可用。確定這一點的快速簡便方法是使用[適用於執行個體類型方案的AWS Command Line Interface (AWS CLI) 命令](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instance-type-offerings.html)。如果要用於實作的區域目前無法使用服務，請考慮為該區域訂購基礎設施的交付週期。 確認、再確認及記錄地區相關決策。在更大的專案團隊中公佈這些決策，以便關鍵利益相關者知悉。如果專案有架構審查委員會，請務必提出此主題，讓每個人都有機會在制定決策之前發表意見。 考量： + 一個關鍵的考量事項是與 SAP 整合的邊界系統。如果您要在 上託管邊界或衛星應用程式 AWS，最好在同一主要區域託管 SAP，以防止任何不必要的延遲討論。即使您確認延遲不是問題，也很難向利益相關者解釋為什麼邊界應用程式建置在與 SAP 應用程式不同的區域中。 + 對於 SAP 和與 SAP 整合的系統，災難復原 (DR) 網站也應該相同，以便能夠實際地協調 DR 測試。不同的系統可能需要不同的解決方案。例如，BusinessObjects 或 Winshuttle 等大型 SAP 系統可能無法使用 ， AWS 彈性災難復原 並且可能需要使用 Amazon Relational Database Service (Amazon RDS) 資料庫的不同解決方案。 ## 建立命名慣例 徹底審核和記錄主機、SAP 環境、虛擬私有雲端 (VPC) 和 AWS 帳戶的命名慣例。請務必遵循現有的標準或慣例。在綠地實作中，可能必須從頭開始定義命名慣例。保持一致。例如，如果您呼叫 VPC *Pre-Prod*、SAP 環境 *UAT* 和 AWS 帳戶 *TST*，從支援角度建立這三個名稱的關聯將會很困難。確保獲得共識並分配每個角色都有意義的名稱，但要保持靈活性。例如，請勿將區域名稱硬編碼為伺服器名稱，以防將來必須切換為其他區域。避免使用內部部署伺服器所使用的命名慣例。相反地，如果您的組織還沒有一個靈活的雲端命名慣例，建議使用它。 考量： + 對於可變更的資訊使用 [AWS 標記](https://docs.aws.amazon.com/ARG/latest/userguide/tagging.html)。 + 請勿將非生產環境置於生產 VPC 中。如果這是一個要求，請確保在同意之前有合理的理由。 ## 記錄所有決策 建議您徹底記錄每個決策的每個變化，誰做出決策，在什麼日期，以及誰在場。將決策儲存在公共場所，例如 Atlassian Confluence 或試算表，並確保正確簽署決策。利益相關者或團隊成員可能會忘記達成的共識，並在稍後的設計或建置階段對決策提出質疑。如果發生這種情況，您會希望有現成的資料來解決任何問題。以下是要記錄的關鍵決策範例： + 區域決策 + HA 相關的應用程式 + 災難復原選項 + 專案階段中的環境支援模型 + 備份和還原方法以及工具 + VPC 結構 + AWS 帳戶決策 + 安全決策 此外，追蹤所有產品功能請求，並記錄團隊實作變更所需的時間。