📚 课程目录第4章标签策略与治理工程

4. 标签策略与治理工程

标签治理的核心矛盾在于：分摊模型要求标签完整、准确、及时，而云环境的资源创建是分布式的，几十上百个团队、流水线、自动化脚本每天都在产生新资源。如果只靠“发一份标签规范文档”，三个月后标签覆盖率通常不会超过 60%。因此标签治理必须工程化——把规范变成机器可校验、可阻断、可自动补齐的策略，而不是一份靠自觉遵守的文档。

一、强制标签规范：先定义“最小可用标签集”

规范的第一步不是列一张二十个字段的大表，而是确定最小可用标签集（Minimum Viable Tag Set）。判断标准很简单：缺少这个标签，分摊或归属就无法计算。对绝大多数组织，最小集只有四个：

CostCenter：成本归属主体，分摊账本的唯一主键，必须来自受控字典（如 CC-1024），不允许自由文本。
Owner：资源责任人，用于异常成本追责与清理，取值建议为邮箱前缀或工号。
Environment：环境枚举，固定为 prod / staging / dev / sandbox，用于区分生产与非生产成本口径。
Application：应用或服务名，用于按业务维度二次聚合，取值需与 CMDB 中的应用清单对齐。

其余标签（如 Project、DataClass、ExpireAt）属于扩展集，按资源类型选择性强制。规范中必须明确每个标签的：键名大小写、允许值来源、是否可继承、是否参与分摊、缺失时的默认值。键名大小写尤其容易被忽略——AWS 标签键区分大小写，costcenter 与 CostCenter 是两个不同的键，账单里会分裂成两行，这是标签治理中最常见的“隐性成本泄漏”。

二、标签继承与传播：让子资源自动带上父级标签

云资源的标签不会自动向下传递。创建一个 EKS 集群并打上 CostCenter，其下的节点组、EBS 卷、弹性 IP 默认都没有这个标签；Auto Scaling 组扩容出的实例同样不会继承。如果只给顶层资源打标签，账单中真正花钱的计算与存储资源反而是“无主”的。

解决思路有三层。第一层是创建时注入：在 IaC 模板（Terraform 的 default_tags、CloudFormation 的 propagate_tags）或 CI/CD 流水线中统一注入标签，让标签随资源定义一起进入版本控制。第二层是运行时传播：利用云平台的原生机制，例如 Auto Scaling 组的标签传播、ECS 服务的 propagateTags、EKS 的节点标签同步，把父级标签带到动态创建的子资源上。第三层是事后补齐：对无法自动传播的资源，用定时任务扫描并回填。

下面这张图展示了一个典型的标签传播链路：从成本中心定义出发，经过 IaC 注入与运行时传播，最终落到可分摊的账单资源上，同时标出了三个容易断链的环节。

三、用策略工具把规范变成“硬约束”

AWS 侧的主力工具是 Tag Policies（组织级标签策略）与 SCP（服务控制策略）。Tag Policies 负责定义“某个标签键允许哪些值”，例如强制 Environment 只能取四个枚举值，一旦资源打了 Production 这种非法值，在合规报告中会被标记为不合规。需要特别注意的是：Tag Policies 本身不阻断资源创建，它只做合规评估与报告；真正能阻断的是 SCP 中的 aws:RequestTag 条件。

下面是一段 SCP 示例，作用是：创建资源时若未携带 CostCenter 标签，或标签值不在受控前缀内，则拒绝该 API 调用。这是把“规范”升级为“强制”的关键一步。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCreateWithoutCostCenter",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "rds:CreateDBInstance",
        "s3:CreateBucket"
      ],
      "Resource": "*",
      "Condition": {
        "Null": { "aws:RequestTag/CostCenter": "true" }
      }
    },
    {
      "Sid": "DenyInvalidCostCenterValue",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotLike": { "aws:RequestTag/CostCenter": "CC-*" }
      }
    }
  ]
}

Azure 侧的对应工具是 Azure Policy，它比 SCP 更灵活，支持 deny、audit、modify、append 四种效果。其中 modify 与 append 可以实现“自动补齐标签”——当资源缺少 CostCenter 时，策略自动从资源组继承该标签写入资源，这正是标签继承在策略层的落地方式。一个典型的 Azure Policy 定义片段如下：

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

四、治理闭环：从合规报告到覆盖率指标

策略上线后必须建立可观测的治理闭环，否则无法判断治理是否有效。建议跟踪三个指标：

指标	定义	目标值	数据来源
标签覆盖率	已带最小标签集的资源数 / 总资源数	≥ 95%	Config / Resource Graph 定时查询
非法值比例	标签值不在受控字典内的资源占比	≤ 1%	Tag Policies 合规报告
待认领成本	无 CostCenter 标签资源产生的月度成本	≤ 总成本 2%	账单 + 标签关联分析

对于未打标资源，不要简单丢弃或平均分摊，而应进入“待认领池”，按预设规则暂挂到平台成本中心，并在每周治理例会上推动责任人认领。这样既保证了分摊账本的完整性，又形成了持续收敛的压力。

治理推进节奏建议：第一阶段只做 audit（只报告不阻断），让团队看到自己的不合规资源；第二阶段对新建资源启用 deny；第三阶段对存量资源用 modify 自动补齐。直接上 deny 容易引发业务中断，反而让治理失去支持。

常见误区：把标签治理当成一次性项目。云环境每天都有新资源产生，标签覆盖率是“活指标”，必须配合定时扫描、周报和责任人机制持续运营，否则上线三个月后覆盖率会重新下滑。

总结来说，标签治理工程由三部分咬合而成：规范定义最小标签集与受控值，传播机制保证标签从顶层资源流向子资源，策略工具把规范变成创建时的硬约束与事后的自动补齐。三者缺一，分摊账本就会出现“无主成本”，而 Showback 的可信度正是建立在高覆盖率、高准确度的标签基础之上。