4、标签策略的制定与实施：强制标签与自动化标签
说实话，标签这件事，我在很多客户那里都见过同一个问题——标签打了一堆，分摊的时候发现根本用不上。为什么？因为标签没有策略，没有强制，也没有自动化。
今天我们就来聊聊，怎么把标签从「爱打不打」变成「不打不行」，再变成「自动打好」。
4.1 为什么标签策略这么重要？
我见过最夸张的一个案例：某公司有300多个标签键，但真正用于成本分摊的只有3个。剩下的标签，要么是开发随手打的，要么是运维批量生成的，要么是历史遗留的。
你想想看，标签越多，管理成本越高。而且没有策略的标签，就像没有交通规则的路口——谁都想走，谁都走不快。
所以，标签策略的核心就两件事：
- 强制标签：哪些标签必须打？不打会怎样？
- 自动化标签：怎么让标签自动生成？减少人工干预。
核心原则：标签不是越多越好，而是越「有用」越好。一个能分摊成本的标签，胜过一百个无用的标签。
4.2 强制标签：让不打标签的人「疼」
我记得有一次，帮一家电商公司做成本优化。他们的问题很简单——标签覆盖率不到30%。我问运维负责人：「为什么不打标签？」他说：「打了也没奖励，不打也没惩罚，谁愿意多干活？」
嗯，这就是人性。所以强制标签的核心，就是让不打标签的人「疼」。
4.2.1 哪些标签必须强制？
我个人习惯，强制标签不要超过5个。太多了，大家记不住，也容易出错。我常用的强制标签清单：
| 标签键 | 标签值示例 | 用途 |
|---|---|---|
| CostCenter | FC-001, FC-002 | 成本中心分摊 |
| Environment | prod, staging, dev | 环境区分 |
| Owner | team-a, team-b | 责任归属 |
| Project | project-x, project-y | 项目维度 |
| AutoShutdown | true, false | 非生产环境自动关闭 |
小技巧：标签值尽量用「短编码」，比如 FC-001 比「财务中心-北京-研发部」好得多。为什么？因为编码容易匹配，中文容易出错。
4.2.2 强制标签的实施方式
不同云厂商的强制标签机制不太一样，但思路是相通的。我以 AWS 和阿里云为例：
AWS 的 SCP（服务控制策略）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"Null": {
"aws:RequestTag/CostCenter": "true"
}
}
}
]
}这段策略的意思是：创建 EC2 实例时，如果没打 CostCenter 标签，直接拒绝。嗯，这就是「不打不让用」的典型做法。
阿里云的标签策略：
# 通过 RAM 策略强制标签
{
"Statement": [
{
"Effect": "Deny",
"Action": "ecs:CreateInstance",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"acs:RequestTag/Environment": ["prod", "staging", "dev"]
}
}
}
]
}注意：强制标签要「逐步推行」。我见过一家公司，第一天就全量强制，结果开发集体罢工——因为他们的自动化脚本没来得及改。建议先试点，再推广。
4.3 自动化标签：让机器替你干活
强制标签解决了「不打不行」的问题，但还有一个问题——人工打标签太慢了。尤其是大规模资源创建时，几百台机器等着打标签，运维手都打酸了。
所以，自动化标签是必须的。说白了，就是让机器替你干活。
4.3.1 基于资源属性的自动标签
我记得在帮一家游戏公司做自动化时，他们有个需求：所有按量付费的实例，自动打上「BillingType=PayAsYouGo」标签。这个用 Lambda 函数就能搞定。
示例代码（AWS Lambda + Python）：
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
# 获取所有按量付费实例
instances = ec2.describe_instances(
Filters=[
{'Name': 'instance-lifecycle', 'Values': ['normal']}
]
)
for reservation in instances['Reservations']:
for instance in reservation['Instances']:
instance_id = instance['InstanceId']
# 检查是否已有 BillingType 标签
tags = instance.get('Tags', [])
has_billing_tag = any(
tag['Key'] == 'BillingType' for tag in tags
)
if not has_billing_tag:
# 自动打标签
ec2.create_tags(
Resources=[instance_id],
Tags=[
{'Key': 'BillingType', 'Value': 'PayAsYouGo'}
]
)
print(f'已为 {instance_id} 自动打标签')
这个函数可以定时运行，比如每天凌晨跑一次。新创建的实例，第二天就会被自动打上标签。
4.3.2 基于命名规范的自动标签
还有一种更聪明的做法——从资源名称中提取标签。比如你的实例命名规范是：
prod-web-server-001
staging-api-server-001
dev-db-server-001那么，通过正则表达式就能自动提取出 Environment、Service、Role 等标签。
示例代码：
import re
def extract_tags_from_name(resource_name):
# 命名规范: {environment}-{service}-{role}-{number}
pattern = r'^(\w+)-(\w+)-(\w+)-\d+$'
match = re.match(pattern, resource_name)
if match:
return {
'Environment': match.group(1),
'Service': match.group(2),
'Role': match.group(3)
}
return None我的经验：命名规范 + 自动标签，是最省力的方式。你只需要在创建资源时遵守命名规范，剩下的交给脚本。我曾经用这个方法，帮一个客户把标签覆盖率从40%提升到了95%。
4.4 标签治理的持续运营
标签策略不是「一次搞定，终身受益」的事。它需要持续运营。我建议做三件事：
- 定期审计：每周跑一次脚本，检查未打标签的资源，生成报告发给负责人。
- 标签健康度看板：在 Grafana 或云厂商的仪表盘上，展示标签覆盖率、合规率等指标。
- 违规通知：发现未打标签的资源，自动发邮件或钉钉消息给 Owner。
我曾经遇到过一个场景：某团队为了省事，把所有资源都打上了「Environment=dev」的标签。结果成本分摊时，dev 环境的成本高得离谱，prod 环境反而很低。这就是标签滥用的问题。
所以，除了强制和自动化，还要有标签值校验。比如 Environment 只能取 prod、staging、dev 三个值，其他值一律拒绝。
总结一下：
- 强制标签解决「打不打」的问题
- 自动化标签解决「怎么打」的问题
- 持续运营解决「打得好不好」的问题
嗯，标签策略做到这个程度，基本上就能支撑起成本分摊和预算管控了。下一章我们会聊聊，怎么用这些标签来做实际的分摊计算。