4. 资源标记与成本分配策略

在 Azure 中，成本数据天然带有资源 ID、资源组、订阅、区域等维度，但这些维度往往无法回答“这笔钱属于哪个业务线、哪个项目、哪个环境、由谁负责”。标签（Tag）是弥补这一缺口的核心手段。标签是附加在资源、资源组和订阅上的键值对，最多 50 个，键名大小写不敏感但保留原始大小写，值区分大小写。成本管理、Azure Policy、自动化脚本都依赖标签来筛选、分组和归因。因此，标签体系不是“顺手打几个标记”，而是一套需要提前设计的分类法。

一、设计标签分类法：先定维度，再定取值

标签分类法的核心是回答“成本要按什么口径分摊”。常见维度包括：业务归属（业务线、产品、项目）、责任归属（成本中心、负责人、团队）、技术属性（环境、应用、组件）、生命周期（创建日期、到期日期、合规级别）。维度不宜过多，建议控制在 6～10 个必选标签，否则维护成本会迅速超过收益。

每个维度必须定义受控词表，而不是让用户自由填写。例如“环境”只允许 prod、staging、dev、test 四个值；“成本中心”使用财务系统已有的编码，如 CC-1024。自由文本会导致 “Prod”“production”“PROD” 被当成三个不同值，成本报表随即失真。键名建议统一采用小写加连字符，如 cost-center、business-unit、environment，避免同一含义出现多种写法。

下表给出一个可直接参考的标签分类法示例，字段和取值均属于教学示例，实际使用时需替换为本组织的真实编码。

二、强制标记策略：从“建议”到“拒绝”

仅有分类法并不够，必须让未打标签的资源无法创建或无法通过合规检查。Azure Policy 提供三种典型效果：Deny 直接拒绝不合规的创建请求；Audit 只记录不合规但不阻断；Modify 在资源创建或更新时自动补充标签。实践中通常组合使用：对生产订阅使用 Deny 保证硬约束，对开发订阅先用 Audit 观察一段时间，再逐步收紧。

一个常见的强制标记策略定义如下，它要求资源必须带有 cost-center 和 environment 两个标签，否则拒绝创建：

{
  "if": {
    "allOf": [
      { "field": "type", "notEquals": "Microsoft.Resources/subscriptions" },
      { "anyOf": [
        { "field": "tags['cost-center']", "exists": "false" },
        { "field": "tags['environment']", "exists": "false" }
      ]}
    ]
  },
  "then": { "effect": "deny" }
}

将该策略分配到管理组或订阅后，任何缺少这两个标签的部署都会在 ARM 层被拒绝，错误信息会明确指出缺失的标签键。这样就把“事后补标签”变成了“事前必须填”。

三、标记继承：用 Modify 效果补齐资源组标签

资源组通常承载了业务归属信息，而资源本身未必重复填写。利用 Azure Policy 的 Modify 效果配合 addOrReplace，可以把资源组上的标签自动继承到其下资源。策略的 if 条件判断资源缺少某个标签，then 使用 [[resourceGroup().tags['cost-center']]] 这样的函数取值并写入资源。

{
  "if": {
    "allOf": [
      { "field": "tags['cost-center']", "exists": "false" },
      { "field": "type", "notEquals": "Microsoft.Resources/subscriptions" }
    ]
  },
  "then": {
    "effect": "modify",
    "details": {
      "roleDefinitionIds": [
        "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
      ],
      "operations": [
        {
          "operation": "addOrReplace",
          "field": "tags['cost-center']",
          "value": "[[resourceGroup().tags['cost-center']]]"
        }
      ]
    }
  }
}

注意 Modify 需要策略分配的身份具备参与者权限，因此 roleDefinitionIds 中引用了参与者角色。策略生效后，新建资源会自动带上资源组的 cost-center，已有资源在下次更新时也会被补齐。继承不是万能的：如果资源组本身没有该标签，继承结果为空，因此资源组层面的强制标记同样不可省略。

四、成本归属：从标签到报表

标签写入后，成本管理中的“成本分析”可以按标签键筛选和分组。例如按 cost-center 分组，即可得到各成本中心的月度支出；按 environment 分组，可以对比生产与非生产的开销比例。若某些资源仍缺少标签，它们会落入“未分配”类别，这个类别的金额就是标记治理的缺口指标。建议把“未分配成本占比”作为 FinOps 的常规监控项，目标通常控制在 5% 以内。

下图展示了从标签分类法、策略强制、继承补齐到成本归属的完整关系，以及未标记资源如何形成治理缺口。

五、落地要点与常见陷阱

第一，标签策略要分层分配。管理组级别分配通用标签策略，订阅级别补充业务特有标签，避免一处修改影响全部订阅。第二，Modify 策略不会追溯已有资源，除非资源被更新；对存量资源可用 Remediation 任务批量修复。第三，标签值不要放敏感信息，标签对订阅内有读取权限的用户可见。第四，成本导出到存储账户或 Power BI 时，标签会作为列出现，因此键名一旦确定就不要频繁改名，否则历史报表会断裂。

把上述环节串起来，就形成了“分类法定义 → 策略强制 → 继承补齐 → 成本归属 → 缺口反馈”的闭环。真正决定成本归属准确性的，不是标签数量，而是必选标签的覆盖率与受控词表的执行力度。