本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 运营模式
<a name="operating-model"></a>

 *运营模式*是一种融合了人员、流程和技术的框架，有助于组织以可扩展、一致、高效的方式实现业务价值。机器学习运营模式为组织内的各团队提供了标准的产品开发流程。根据规模、复杂性和业务驱动因素，有三种实施运营模式的模型：
+  **集中式数据科学团队** — 在此模型中，所有数据科学活动都集中发生在单个团队或组织中。这类似于卓越中心 (COE) 模型，即所有业务部门都交给该团队进行数据科学项目。
+  **分布式数据科学团队** — 在此模型中，数据科学活动分布在不同的业务职能或部门，或者基于不同的产品线。
+  **联合数据科学团队** — 在此模型中，集中式团队负责管理代码存储库、持续集成和持续交付 (CI/CD) 管道等共享服务功能，而分布式团队负责管理各业务部门或产品级功能。这类似于星型拓扑连接模型，即每个业务部门都有专门的数据科学团队，但这些团队会与集中式团队协调活动。

 在决定为制作用例启动您的第一个工作室域名之前，请考虑您的运营模式和组织环境 AWS 的最佳实践。有关更多信息，请参阅[使用多个帐户组织您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)。

下一节将指导如何针对各种运营模式来组织账户结构。

## 推荐的账户结构
<a name="recommended-account-structure"></a>

 本节简要介绍了一种运营模式账户结构，以便您根据组织的运营要求初步应用并进行修改。无论您选择哪种运营模式，亚马逊都建议您实施以下常见的最佳实践：
+  使用 [AWS Control Tower](https://aws.amazon.com/controltower/) 设置、管理并监管账户。
+  使用您的身份提供商 (IdP) 集中您的身份，AWS IAM使用委派的[管理员 Securitiy Tooling 帐户集中[身份](https://aws.amazon.com/iam/identity-center/)中心，并启用对工作负载的安全](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)访问。
+  使用跨开发、测试和生产工作负载的账户级隔离，运行机器学习工作负载。
+  将机器学习工作负载日志流式传输到日志存档账户，然后在可观测性账户中筛选并应用日志分析。
+  运行集中式监管账户，用于预置、控制并审核数据访问权限。
+  根据您的组织和工作负载要求，在每个账户中嵌入带有适当预防和侦查防护栏的安全和治理服务 (SGS)，以确保安全性和合规性。

### 集中式模型账户结构
<a name="centralized-model-account-structure"></a>

 在此模型中，机器学习平台团队负责提供：
+  一个共享服务工具账户，用于满足数据科学团队的 Machine Learning Operations ([MLOps](https://en.wikipedia.org/wiki/MLOps)) 要求。
+  跨数据科学团队共享账户，可开发、测试并生产机器学习工作负载。
+  监管策略，可确保独立运行各数据科学团队的工作负载。
+  常见的最佳实践。

![\[图中描述了集中式运营模式账户结构。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/sagemaker-studio-admin-best-practices/images/com-account-structure.png)


### 分布式模型账户结构
<a name="decentralized-model-account-structure"></a>

 在此模型中，每个机器学习团队均独自负责预置、管理并治理机器学习账户和资源。亚马逊建议机器学习团队使用支持可观测性和数据治理的集中式模型，以简化数据治理和审计管理流程。

![\[图中描述了分布式运营模式账户结构。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/sagemaker-studio-admin-best-practices/images/decentralized-model.png)


### 联合模型账户结构
<a name="federated-model-account-structure"></a>

 该模型与集中式模型类似；但是，主要区别在于，每个数据science/ML team gets their own set of development/test/production工作负载都允许对其机器学习资源进行强大的物理隔离，并且还使每个团队能够在不影响其他团队的情况下独立扩展。

![\[文档描述了联合运营模式账户结构。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/sagemaker-studio-admin-best-practices/images/fom-account-structure.png)


## 机器学习平台多租户架构
<a name="ml-platform-multitenancy"></a>

 *多租户*是一种软件架构，其中的单个软件实例可以为多个不同的用户组提供服务。*租户*是一组用户，共享对软件实例的特定访问权限。例如，您在开发多个机器学习产品时，可以将具有相似访问权限要求的产品团队都视为租户或团队。

 虽然可以在一个 SageMaker AI Studio 实例（例如 AI [Dom SageMaker ain）中部署多个团队，但当您将多个团队引入单个 A SageMaker I Studio 域](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-entity-status.html)时，请权衡这些优势和爆炸半径、成本归因和账户等级限制等权衡。以下章节详细说明了这些利弊和最佳实践。

如果您需要绝对的资源隔离，可以考虑为不同账户中的每个租户实现 SageMaker AI Studio 域。根据您的隔离要求，您可以在单个账户和区域内将多个业务线 (LOBs) 作为多个域名实施。使用共享空间在同一团队的成员之间进行近乎实时的协作/LOB. 对于多个域，您仍将使用身份访问管理 (IAM) 策略和权限来确保资源隔离。

SageMaker 从域创建的 AI 资源会自动使用域 [Amazon 资源名称](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) (ARN) 和用户配置文件或空间ARN进行标记，以便于资源隔离。有关示例策略，请参阅[域资源隔离文档](https://docs.aws.amazon.com/sagemaker/latest/dg/domain-resource-isolation.html)。[在这里，您可以看到有关何时使用多账户或多域策略的详细参考以及文档中的功能比较，还可以查看用于回填存储库中现有域名标签的示例脚本。GitHub ](https://github.com/aws-samples/sm-studio-best-practices/tree/main/domain-management)

最后，您可以使用将 SageMaker AI Studio 资源自助部署到多个账户[AWS Service Catalog](https://aws.amazon.com/servicecatalog/)。有关更多信息，请参阅[管理多个 AWS 账户 和中的 AWS Service Catalog 商品 AWS 区域](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions.html)。