

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Best practice
<a name="best-practice-tagging"></a>

Quando si utilizzano i tag, è importante comprendere la struttura aziendale attuale o potenziale e i casi d'uso. Utilizzando queste informazioni, puoi scegliere i tag giusti. Ad esempio, se state creando un data lake per il reparto prevendita e sapete che è prevista l'espansione del data lake per includere i dati del reparto post-vendita, l'utilizzo del tag `department` aiuterà a identificare i costi e le prestazioni di ciascun reparto separatamente. La pianificazione, l'allocazione dei costi e l'ottimizzazione del codice o dei dati possono essere identificate con maggiore precisione. Senza il `department` tag, se i dati di prevendita richiedono 15 minuti per la modellazione dei dati e i dati post-vendita richiedono 45 minuti, gli sviluppatori devono dedicare più tempo all'analisi delle cause principali. Grazie al `department` tag, gli sviluppatori saprebbero esattamente dove cercare.

## Ontologia dei tag
<a name="ontology"></a>

Il business e la tecnologia insieme svolgono un ruolo importante nell'identificazione dei tag giusti da utilizzare. Dal punto di vista aziendale, un'azienda e un progetto seguiranno sempre una certa struttura. Ad esempio, nella *regione* EMEA, nel *dipartimento* delle risorse umane, potrebbe esserci un *progetto* sulla previsione della necessità di assumere. In questo caso, l'inclusione dei metadati della struttura esistente sarebbe importante per la rendicontazione, il monitoraggio, la pulizia e l'implementazione. Allo stesso tempo, l'ufficio tecnico comprende che il progetto avrà bisogno di quanto segue: 
+ *Fasi* della raccolta dei dati attraverso una pipeline di dati composta dall'ingestione, dalla pulizia e dall'elaborazione dei dati
+ Un team di machine learning per la modellazione dei dati**** per le previsioni
+ Una DevOps pipeline per l'orchestrazione del codice, diffusa attraverso un ambiente di sviluppo, test e produzione

Tutte le parole chiave in corsivo sono strutture di gruppi aziendali e tecnici che è importante associare ai componenti di un'applicazione. Questo è un esempio di una tipica ontologia dei tag. Utilizzando l'esempio, la tabella seguente mostra le coppie chiave-valore corrispondenti per i tag.


|  |  | 
| --- |--- |
| **Chiave** | **Valori** | 
| `department` | `human resources` | 
| `region` | `EMEA` | 
| `project` | `hiring forecast` | 
| `phase` | `3` | 
| `process` | `data ingestion`, `data cleaning`, `processing`, `modeling` oppure `sales forecasting` | 
| `domain` | `machine learning` o `data pipeline` | 
| `creation` | `cdk`,`x framework`, o `ingest pipeline` `manual - empty` | 
| `status` | `development`, `testing`, `production access`, `reporting` oppure `onboarding` | 

## Gestione dei tag
<a name="governance"></a>

L'impostazione di meccanismi di governance aiuta a rendere l'etichettatura coerente e programmabile su tutte le risorse: AWS 
+ *Una governance reattiva* significa trovare risorse che non sono etichettate correttamente. Puoi utilizzare strumenti come l'[API Resource Groups Tagging](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html), [AWS Config regole](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) e script personalizzati.
+ *Una governance proattiva* significa che agli utenti non è consentito creare risorse prive di tag. Puoi utilizzare strumenti come [AWS CloudFormation[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/userguide/end-user-console.html)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html), [tag policy in o autorizzazioni a livello di](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) AWS Organizations risorsa IAM.