本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 设计阶段的最佳实践 全新 SAP 实施的设计阶段是成功的构建阶段的基础。在此阶段，您将与基础设施利益相关者合作，收集需求并记录架构。您还必须考虑其他对齐方式。您必须确保各项目利益相关者就时间表、情形战略和 SAP on AWS 架构达成共识，包括高可用性（HA）和灾难恢复（DR）环境。本节为解决您在项目设计阶段可能遇到的一些挑战提供了建议。 ## 创建交付时间表和情形图标 与您共享业务转型项目时间表后，立即构建基础设施交付时间表。这可以帮助您提前计划并在基础设施团队中保持一致。制定时间表的主要意见来自 SAP 项目团队的系统集成商 (SIs)。回过头来得出 SAP Basis 团队应当完成工作的时间，以及基础设施准备就绪，SAP Basis 团队可以安装 SAP 应用程序的世时间。 注意事项： + 以可视化形式展现交付时间表使团队能够快速了解正在构建的内容、要求的截止日期以及可能的资源争用。它还允许关键利益相关者以一种易于理解的方式可视化正在构建的环境、项目的持续时间以及与 SAP Basis 团队之间的 AWS 交接。 ![SAP 新 AWS 建项目的交付时间表。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/sap-greenfield-implementations/images/timeline.png) + 进行典型的全新 SAP 实施需要一年或更长时间。这包括基础设施团队不积极构建基础设施组件时的时间，因此考虑这段时间内的活动和可交付成果非常重要。要映射的活动示例包括 HA 设置和测试、灾难恢复设置和测试、性能测试以及构建自动化脚本。 + 在全新的实施中，情形和环境的概念可能不太好理解。区分环境和情形（N、N\+1、N\+2）的彩色编码时间表可以帮助利益相关者快速了解这一信息矩阵。 以下是典型的高级 SAP 情形图示例。这些框代表环境，环境是应用程序的集合（例如，SAP S/4HANA），而情形是用于特定版本的环境的集合。 ![SAP 新 AWS 建项目的景观图。](http://docs.aws.amazon.com/zh_cn/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）站点也应相同，以便可以实际协调灾难恢复测试。不同的系统可能需要不同的解决方案。例如，像 Winshuttle 这样的大型 SAP 系统可能无法使用 AWS 弹性灾难恢复 ，可能需要使用亚马逊关系数据库服务 (Amazon RDS) 数据库的不同解决方案。 BusinessObjects ## 建立命名约定 彻底审查并记录主机、SAP 环境、虚拟私有云 (VPC) 和 AWS 账户的命名惯例。请遵循现有标准或约定。在全新实施中，您可能必须从头开始定义命名约定。请使用一致的方式行事。例如，如果您调用 VPC P *re-Prod*、SAP 环境 *U* AT 和 AWS 账户 *TST*，那么从支持的角度来看，将这三个名称关联起来会很困难。一定要达成共识，给每个角色都指定有含义的名字，但要留出灵活的余地。例如，不要将区域名称硬编码到服务器名称中，以防将来需要切换到另一个区域。请避免使用您的本地服务器使用的命名约定。相反，如果您的组织还没有灵活的云命名约定，建议您使用灵活的云命名约定。 注意事项： + 使用 [AWS 标记](https://docs.aws.amazon.com/ARG/latest/userguide/tagging.html)以获取可能变化的信息。 + 不要将非生产环境置于生产环境中。 VPCs如果这是一项要求，请确保在同意之前有正当的理由。 ## 记录所有决策 我们建议您全面记录每项决策的每一个差异、谁做出了决定、决定日期以及谁在场。将决策存储在公共场所，例如 Atlassian Confluence 或电子表格，并确保对决策进行适当的签署。利益相关者或团队成员可能会忘记达成的共识，并在设计或构建阶段的后期对决策提出质疑。如果发生这种情况，您会希望用随时可用的数据来解决所有问题。以下是需要记录的关键决策示例： + 区域决策 + 与 HA 相关的应用程序 + 灾难恢复决策 + 项目阶段中的环境支持模型 + 备份和还原的方法以及工具 + VPC 结构 + AWS 账户决策 + 安全决策 此外，跟踪所有产品功能请求并记录团队实施变更花费了多长时间。