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

# 最佳實務
<a name="best-practice-tagging"></a>

使用標籤時，請務必了解目前或潛在的公司和使用案例結構。使用此資訊，您可以選擇正確的標籤。例如，如果您要為售前部門建置資料湖，而且您知道計劃擴展資料湖以包含售後部門的資料，則使用 標籤`department`將有助於分別識別每個部門的成本和效能。您可以更精確地識別程式碼或資料的規劃、成本分配和最佳化。如果沒有 `department`標籤，如果售前資料需要 15 分鐘進行資料建模，而售後資料需要 45 分鐘，開發人員必須花更多時間進行根本原因分析。使用 `department`標籤，開發人員會確切知道要看哪裡。

## 標記本體
<a name="ontology"></a>

商業和技術共同在識別要使用的正確標籤方面扮演重要角色。從業務角度來看，公司和專案將一律遵循特定結構。例如，在 EMEA *區域中*，在 HR *部門*中，可能有預測招聘需求的*專案*。在這種情況下，包括現有結構的中繼資料對於報告、監控、清理和推展至關重要。同時，技術部門了解專案將需要下列項目：
+ 透過由資料擷取、清理和處理組成之資料管道的資料收集*階段* 
+ ** **執行資料建模以進行預測的 ML 團隊
+ 用於程式碼協同運作的 DevOps 管道，透過開發、測試和生產環境傳播

所有斜體關鍵字都是與應用程式元件建立關聯的重要商業和技術群組結構。這是典型標記本體的範例。使用 範例，下表顯示標籤的對應鍵值對。


|  |  | 
| --- |--- |
| **Key (金鑰)** | **Values (數值)** | 
| `department` | `human resources` | 
| `region` | `EMEA` | 
| `project` | `hiring forecast` | 
| `phase` | `3` | 
| `process` | `data ingestion`、`data cleaning`、`processing`、`modeling` 或 `sales forecasting` | 
| `domain` | `machine learning` 或 `data pipeline` | 
| `creation` | `cdk`、`ingest pipeline`、 `x framework`或 `manual - empty` | 
| `status` | `development`、`testing`、`production access`、`reporting` 或 `onboarding` | 

## 標籤的控管
<a name="governance"></a>

設定控管機制有助於使標記在所有 AWS 資源之間保持一致和可程式設計：
+ *被動控管*是指尋找未正確標記的資源。您可以使用[資源群組標記 API](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html)、[AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)和自訂指令碼等工具。
+ *主動控管*表示不允許使用者建立任何未標記的資源。您可以使用 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)、[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/userguide/end-user-console.html)、 中的[標籤政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) AWS Organizations或 IAM 資源層級許可等工具。