Tous les produits
Search
Centre de documentation

Resource Management:Bonnes pratiques de conception des tags

Dernière mise à jour :Sep 08, 2026

Cette rubrique présente le contexte, les principes, les bonnes pratiques et des exemples de conception des tags.

Contexte

Lorsqu'une entreprise ne dispose que de quelques ressources cloud, il est possible de les classer de mémoire ou à l'aide de registres manuels. Toutefois, à mesure que le nombre de ressources cloud augmente, atteignant parfois plusieurs milliers dans les grandes entreprises, la classification manuelle devient peu fiable et une solution basée sur une plateforme s'impose.

Sur Alibaba Cloud, utilisez des tags pour marquer et classer vos ressources. Lors de la création d'une ressource, attribuez-lui des tags indiquant ses propriétés, telles que sa propriété commerciale et financière. Par exemple, vous pouvez taguer les ressources par créateur, région ou projet. Si vous ne taguez pas les ressources lors de leur création, l'organisation de leurs propriétés devient beaucoup plus difficile par la suite.

Principes de conception des tags

  • Principe d'exclusion mutuelle

    Le principe d'exclusion mutuelle empêche l'utilisation de plusieurs clés de tag pour un même attribut de ressource. Par exemple, si vous utilisez la clé de tag owner pour identifier le propriétaire d'une ressource, n'utilisez pas de clés similaires telles que own, belonger ou owner_cn.

  • Principe d'exhaustivité collective

    Le principe d'exhaustivité collective exige que toutes les ressources disposent des clés de tag planifiées et de leurs valeurs de tag correspondantes. Par exemple, si une entreprise compte trois départements de projets de jeux et utilise la clé de tag project, il doit exister au moins trois valeurs de tag pour représenter ces départements.

    Un taguage complet et exhaustif est une condition préalable aux opérations basées sur les dimensions des tags, telles que la récupération des ressources, l'allocation des coûts, l'exploitation et la maintenance (O&M) automatisées et le contrôle d'accès.

  • Principe de limitation des valeurs

    Le principe de limitation des valeurs consiste à ne conserver que les valeurs de tag essentielles pour une ressource et à supprimer les valeurs redondantes. Par exemple, si une entreprise compte cinq départements, il ne devrait y avoir que cinq valeurs de tag correspondantes pour la clé de tag du département. Cela simplifie la gestion.

    Ce principe simplifie la récupération des ressources, l'allocation des coûts, l'exploitation et la maintenance (O&M) automatisées ainsi que le contrôle d'accès.

  • Principe de prise en compte des évolutions futures

    Lorsque vous concevez des tags, anticipez les évolutions futures en tenant compte de l'impact de l'ajout ou de la suppression de valeurs de tag. La définition claire des limites commerciales rend vos tags plus flexibles et plus faciles à modifier. Par exemple, une entreprise qui débute dans le cloud peut avoir des opérations commerciales centralisées et utiliser un seul tag, tel que department, pour gérer la propriété des ressources, la propriété financière et l'exploitation et la maintenance (O&M) automatisées. À mesure que l'entreprise se développe, ce tag unique peut devenir surchargé de logique métier, ce qui rend sa séparation ultérieure coûteuse et difficile. Par conséquent, évaluez vos besoins commerciaux en matière de tags dès la phase initiale d'adoption du cloud. Dans cet exemple, il est préférable d'utiliser dès le départ les tags department, costcenter et ops.

    La modification des tags peut affecter le contrôle d'accès basé sur les tags, l'exploitation et la maintenance (O&M) automatisées ou les rapports de facturation associés. Pour les cas d'utilisation professionnels et personnels, créez des tags liés à l'activité pour gérer les ressources selon les dimensions techniques, commerciales et de sécurité. Lorsque vous utilisez l'exploitation et la maintenance (O&M) automatisées pour gérer les ressources et les services, concevez des tags supplémentaires et dédiés pour faciliter les tâches d'automatisation.

  • Principe de conception simplifiée

    Le principe de conception simplifiée consiste à utiliser un ensemble fixe de tags avec des clés et des valeurs simples qui répondent à vos besoins commerciaux. Par exemple, lorsque vous concevez des tags pour les environnements de projet, utilisez une clé de tag cohérente pour les environnements de test, telle que test-environment. Ne maintenez pas plusieurs clés similaires, telles que pre-test-environment ou formal-test-environment.

    Ce principe permet de réduire les erreurs opérationnelles causées par un nombre excessif de clés de tag.

  • Principe de nommage standardisé

    Le principe de nommage standardisé consiste à utiliser un format de nommage standard pour les tags afin de garantir la compatibilité avec différents outils open source et de simplifier l'intégration future des API. Par exemple, si les noms de tags incluent des mots anglais, utilisez uniquement des lettres minuscules.

Bonnes pratiques de conception des tags

Une entreprise Internet compte trois départements : Business, Marketing et O&M. Chaque département gère un ou plusieurs projets. Chaque projet dispose d'environnements de production, de développement et de test pour différentes étapes du cycle de vie. L'équipe O&M doit surveiller les ressources de l'entreprise en temps réel, allouer périodiquement les coûts pour chaque projet, contrôler l'accès aux ressources et mettre en œuvre l'exploitation et la maintenance (O&M) automatisées.企业组织架构

Pour répondre à ces exigences, l'entreprise a conçu ses tags comme suit.

Besoin

Conception des tags

Description

Récupérer et gérer les ressources

Créez et associez les trois niveaux de tags suivants à toutes les ressources :

  • department : le département auquel la ressource appartient.

  • project : le projet auquel la ressource appartient.

  • environment : le contexte environnemental de la ressource.

Si votre entreprise possède une hiérarchie organisationnelle profonde, envisagez d'ajouter des tags de niveau supérieur, tels qu'un tag pour la succursale (company).

Gérer les coûts et l'allocation des coûts

Créez et associez un tag de centre de coûts à toutes les ressources :

  • Clé de tag : costcenter

  • Valeurs de tag : proj-1, proj-2, proj-3 ou proj-4

Aucune

Contrôle d'accès aux ressources

Restreignez l'accès des non-membres du projet aux ressources du projet, telles que les instances ECS.

Pour plus d'informations, consultez Utiliser des tags pour restreindre la gestion d'instances ECS spécifiées par les utilisateurs RAM.

Exploitation et maintenance (O&M) automatisées

Créez un tag d'objectif avec la clé purpose pour les inspections quotidiennes des ressources. Définissez la valeur sur autocheck-8am pour indiquer une inspection automatique à 8 h 00 tous les jours. Si une inspection révèle une anomalie, utilisez le tag de propriétaire de ressource owner pour notifier la personne responsable afin qu'elle traite le problème.

Aucune

Exemples de conception de tags

Le tableau suivant répertorie des exemples de conceptions de tags pour des dimensions courantes.

Dimension de classification

Clé de tag

Valeur de tag

Structure organisationnelle

  • company

  • department

  • organization

  • team

  • group

Noms pertinents

Architecture commerciale

  • product

  • business

  • module

  • service

Noms pertinents

Architecture des rôles

  • role

  • user

  • network administrator

  • application administrator

  • system administrator

  • O&M administrator

  • Research and Development

  • Test

Objectif

  • purpose

  • use

Valeur d'objectif

Projet

  • Dimension du projet :

    • project

    • risk

    • schedule

    • subtask

    • environment

  • Dimension du personnel :

    • sponsor

    • member

    • owner

    • creator

Veillez à fournir des informations exactes.

Département commercial (pour l'allocation des coûts et le suivi commercial)

  • costcenter

  • businessunit

  • biz

  • financecontact

Valeurs réelles

Propriétaire de la dimension financière (pour identifier le propriétaire de la ressource)

owner

Nom ou adresse e-mail

Client de la dimension financière (pour identifier le client du service de ressource)

Valeur personnalisée ou réelle

Nom du client

Projet de la dimension financière (pour identifier le projet pris en charge par la ressource)

project

Nom du projet

Commande de la dimension financière

order

ID de catégorie de commande