本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 操作模型
*操作模型*是一種架構，可將人員、程序和技術結合在一起，以協助組織以可擴展、一致、有效率的方式提供商業價值。ML 操作模型為整個組織的團隊提供標準產品開發程序。根據大小、複雜性和業務驅動因素，實作操作模型有三種模型：
+ **集中式資料科學團隊**：在此模型中，所有資料科學活動都會集中在單一團隊或組織中。這與卓越中心 (COE) 模型類似，其中所有業務單位都會前往此團隊進行資料科學專案。
+ **分散式資料科學團隊**：在此模型中，資料科學活動會分散到不同的業務職能或部門，或根據不同的產品線。
+ **聯合資料科學團隊** — 在此模型中，程式碼儲存庫、持續整合和持續交付 (CI/CD) 管道等共用服務函數由集中式團隊管理，而每個業務單位或產品層級函數則由分散團隊管理。這類似於中樞和發言模型，每個業務單位都有自己的資料科學團隊；但是，這些業務單位團隊會與集中式團隊協調其活動。
在決定為生產使用案例啟動第一個 Studio 網域之前，請考慮您的操作模型和 AWS 最佳實務來組織您的環境。如需詳細資訊，請參閱[使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)。
下一節提供針對每個操作模型組織帳戶結構的指引。
## 建議的帳戶結構
在本節中，我們簡要介紹了操作模型帳戶結構，您可以根據組織的操作需求，從 開始修改。無論您選擇何種操作模型，我們建議實作下列常見最佳實務：
+ 使用 [AWS Control Tower](https://aws.amazon.com/controltower/) 設定、管理和控管您的帳戶。
+ 使用 Identity Provider (IdP) 和 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 與委派管理員 [Securitiy Tooling 帳戶](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)集中您的身分，並啟用工作負載的安全存取。
+ 跨開發、測試和生產工作負載，以帳戶層級隔離執行 ML 工作負載。
+ 將 ML 工作負載日誌串流到日誌封存帳戶，然後在可觀測性帳戶中篩選和套用日誌分析。
+ 執行集中式控管帳戶，以佈建、控制和稽核資料存取。
+ 根據您的組織和工作負載需求，在每個帳戶中嵌入具有適當預防性和偵測性防護機制的安全和管理服務 (SGS)，以確保安全性和合規性。
### 集中化模型帳戶結構
在此模型中，ML 平台團隊負責提供：
+ 共用服務工具帳戶，可解決跨資料科學團隊的Machine Learning操作 ([MLOps](https://en.wikipedia.org/wiki/MLOps)) 需求。
+ 跨資料科學團隊共用的 ML 工作負載開發、測試和生產帳戶。
+ 確保每個資料科學團隊工作負載獨立執行的控管政策。
+ 常見最佳實務。
![\[描述集中式操作模型帳戶結構的圖表。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/sagemaker-studio-admin-best-practices/images/com-account-structure.png)
### 分散式模型帳戶結構
在此模型中，每個 ML 團隊都會獨立運作，以佈建、管理和管理 ML 帳戶和資源。不過，我們建議 ML 團隊使用集中式可觀測性和資料控管模型方法來簡化資料控管和稽核管理。
![\[描述分散式操作模型帳戶結構的圖表。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/sagemaker-studio-admin-best-practices/images/decentralized-model.png)
### 聯合模型帳戶結構
此模型與集中式模型類似；不過，關鍵差異在於每個資料science/ML team gets their own set of development/test/production工作負載帳戶，其可對其 ML 資源進行強健的實體隔離，並使每個團隊能夠獨立擴展，而不會影響其他團隊。
![\[描述聯合操作模型帳戶結構的文件。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/sagemaker-studio-admin-best-practices/images/fom-account-structure.png)
## ML 平台多租戶
*多租戶*是一種軟體架構，單一軟體執行個體可以提供多個不同的使用者群組。*租用戶*是一組使用者，這些使用者共用軟體執行個體的特定權限。例如，如果您正在建置數個 ML 產品，則具有類似存取要求的每個產品團隊都可以被視為租戶或團隊。
雖然可以在 SageMaker AI Studio 執行個體 （例如 [SageMaker AI Domain](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-entity-status.html)) 中實作多個團隊，但當您將多個團隊帶入單一 SageMaker AI Studio 網域時，可以權衡這些優勢與權衡，例如爆量半徑、成本歸因和帳戶層級限制。在以下各節中進一步了解這些權衡和最佳實務。
如果您需要絕對資源隔離，請考慮為不同帳戶中的每個租戶實作 SageMaker AI Studio 網域。根據您的隔離需求，您可以在單一帳戶和區域中實作多行業務 (LOBs) 做為多個網域。使用共用空間，在同一團隊的成員之間進行近乎即時的協同合作/LOB。使用多個網域時，您仍然會使用身分存取管理 (IAM) 政策和許可來確保資源隔離。
SageMaker 從網域建立的 AI 資源會使用網域 [Amazon Resource Name](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)。