本文为您介绍标签设计的背景、原则、最佳实践以及相关示例。
标签设计的背景
当企业云上资源只有几个或十几个的时候,通过人脑记忆或人工记录即可完成资源的分类。但是,随着企业云上资源不断增加(大型企业资源数量甚至成千上万),单纯依靠人工进行资源的分类变得越来越不可靠。此时,需要借助平台化能力来解决这个问题。
在阿里云,我们推荐您使用标签对资源进行标记,从而实现资源的分类。每个用户在创建资源时都要对资源的业务归属、财务归属等资源属性进行标记,例如:按创建者、地域或项目等。否则,后续再去梳理每个资源的资源属性往往变得事倍功半。
标签设计的原则
-
互斥原则
互斥原则是指避免对同一个资源使用两个或以上的标签键。例如:如果已经使用了标签键 owner 来标识资源的所有者,就不要再使用 own 、 belonger 或 所有者 等类似的标签键。
-
集体详尽原则
集体详尽原则是指所有资源都必须绑定已规划的标签键及其对应的标签值。例如:某公司有3个游戏项目部,标签键是 project ,则应至少有3个标签值分别代表这 3个项目部。
集体详尽原则是后续基于标签维度进行资源检索、分账、自动化运维和访问控制的必要条件。
-
有限值原则
有限值原则是指为资源只保留核心标签值,删除多余的标签值。例如:某公司共有5个部门,那么应该有且仅有这5个部门的标签,方便管理。
有限值原则简化了资源检索、分账、自动化运维和访问控制的流程。
-
考虑未来变化原则
考虑未来变化原则是指在设计标签时要考虑后续工作中增加或者减少标签值的影响,尽可能将业务边界划分得更加清晰一点,提高标签修改的灵活性。例如:企业在上云初期业务比较集中,就采用部门标签 department 来管理部门相关的资源归属、财务归属和自动化运维。随着企业的发展,这一个标签已经承载了一些日常业务,想要区分开就需要耗费一定成本。因此,我们建议,企业在上云初期需要先评估标签的业务诉求,如在上述例子中则需规划同时采用 department 、 costcenter 和 ops 标签。
当您修改标签时,可能会引起基于标签的访问控制、自动化运维或相关账单报表的变化。无论是公司或个人层面的业务,推荐您创建与业务相关的标签,以便从技术、业务和安全维度管理资源。使用自动化运维来管理资源及服务时,还需要设计额外的自动化运维专用标签,帮助您完成自动化运维工作。
-
简化设计原则
简化设计原则是指在设计标签时使用固定的标签,简化标签的使用。标签的设计尽量简化key和value的值,满足业务诉求即可。例如:在设计项目环境维度的标签时,测试环境相关的标签键尽量统一成 测试环境 ,不要同时保有多个,如 预测试环境 、 正式测试环境 等。
简化设计原则可以减少由于过多的标签键导致的操作报错。
-
命名标准化原则
命名标准化原则是指标签采用标准化命名格式,尽量兼容不同开源工具,使后续的API集成更加便捷。例如:标签命名涉及英文时,建议使用小写英文字母。
标签设计的最佳实践

为了满足上述需求,该公司从以下几个方面进行了标签设计。
需求 | 标签设计 | 说明 |
---|---|---|
检索和管理资源 |
为所有资源创建并绑定以下3个层级的标签:
|
如果企业的组织架构层级比较深,可以考虑更高层级的标签,例如:分公司(company)等。 |
管理成本和分账 |
为所有资源创建并绑定成本中心标签:
|
无 |
资源访问控制 | 限制非项目组成员对项目内ECS等资源的访问。 | 具体操作,请参见 使用标签控制ECS资源的访问 。 |
自动化运维 | 创建用途标签键 purpose 来进行日常资源巡检,标签值为 autocheck-8am ,即每日早8点自动巡检。如果巡检发现异常,通过资源持有者标签 owner 来通知具体责任人进行处理。 | 无 |
标签设计示例
下表列举了常见维度的标签设计示例。
划分维度 | 标签键(key) | 标签值(value) |
---|---|---|
组织架构 |
|
相关名称 |
业务架构 |
|
相关名称 |
角色架构 |
|
|
用途 |
|
用途值 |
项目 |
|
据实填写 |
业务部门(实现成本分配和业务跟踪) |
|
据实填写 |
财务维度责任人(确定资源负责人) | owner | 人名或邮箱等 |
财务维度客户(识别资源服务的客户) | 自定义或真实值 | 客户名称 |
财务维度项目(确定资源支持的项目) | project | 项目名称 |
财务维度订单 | order | 订单分类ID |