Tagging — 驱动成本分配80%的20%

Source: Dev.to

常见 FinOps 错误：过度设计的标签

一个 Series B SaaS 团队花了三个月时间设计了一个包含 47 个字段的标签分类（例如 Environment、Service、Owner、Business unit、Cost center、Data classification、Compliance zone、Criticality、Expiry、PII flag、Migration source、CI pipeline ID）。

• 他们无法强制执行。
• 他们的 Terraform 代码库包含约 80 个模块，而一半的资源是在标签体系出现之前就已经创建的。
• rollout 计划估计需要六个月；团队在四个月后放弃了。

与此同时，他们的成本分配报告仍然是：

Sum by service:
- EC2 = 34%
- RDS = 22%
- Datadog = 18%
- Others = 26%

这套 47 字段的模式 没有 为业务带来任何价值。

有效的 80/20 标签方法

只需要五个标签，通过服务控制策略（SCP）、CI 门和 IaC 策略强制执行：

# Example IaC policy (pseudo‑code)
required_tags:
  - team
  - service
  - env
  - cost_center
  - expiry
enforcement: block_if_missing
auto_flag: true

• 强制：如果缺少任何标签，资源创建将被阻止。
• 自动标记：如果标签违反策略，将被自动标记。

这个五标签模式覆盖了 ≈95 % 的 FinOps 报告需求，足以满足你将来的所有需求。

经验法则： 只有在有具体问题需要答案时，才根据供应商的建议额外构建其余 42 个标签。绝不要预先创建它们。

标签策略成熟度曲线

1. 从简单开始 – 采用上面的五标签模式。
2. 迭代 – 仅在出现特定且有正当理由的需求时才添加额外标签。
3. 保持文档简短 – 如果你的标签 RFC 超过三页，请重写它。更短的文档更易落地。

Tags: AWS FinOps CloudCost DevOps Tagging InfrastructureAsCode IndiaSaaS Engineering Founders