答案先说
告警标签不是装饰字段。它决定 Flashduty 后续能不能稳定完成路由、分派、聚合、静默、抑制和分析。
第一版标签规范不要追求字段越多越好，先保证这五个标签稳定：
service
team
env
severity
resource
再逐步补充：
check
cluster
source
如果这些标签缺失或取值混乱，后续规则就会变成标题正则、描述关键字和例外条件的堆砌。
为什么标签决定告警治理质量
只有标题的告警，例如 CPU usage high，系统很难判断它属于哪个服务、哪个团队、哪个环境、应该通知谁、是否需要电话升级，以及应该和哪些告警聚合。
带有结构化标签的告警就不同：
service=payment
team=payment-sre
env=production
severity=critical
cluster=prod-shanghai-01
resource=pod/payment-api-7d9c
check=http_5xx_rate
source=prometheus
这类告警可以按 team 路由，按 severity 命中分派策略，按 service 找值班表，按 resource 和 check 聚合，按 env 做静默或降级。
核心标签怎么定义
| 标签 | 含义 | 示例 | 主要用途 |
|---|---|---|---|
service |
业务服务或平台能力 | payment、gateway |
路由、分派、聚合、分析 |
team |
第一响应团队 | payment-sre、dba |
共享集成路由、责任统计 |
env |
运行环境 | production、staging、test |
分级通知、静默、Pipeline |
severity |
严重程度 | critical、warning、info |
通知强度、升级策略、报表 |
resource |
具体出问题对象 | 10.0.1.12、rds-payment-main |
排障、聚合 |
check |
告警检查项 | cpu_usage、http_5xx_rate |
噪音分析、规则治理 |
cluster |
集群、地域或部署单元 | prod-shanghai-01 |
基础设施归因、抑制 |
source |
告警来源系统 | prometheus、zabbix |
接入质量和噪音来源分析 |
service 和 team 不要混用。service 表达业务对象，team 表达响应责任。一个团队可以负责多个服务，一个服务也可能在不同阶段由不同团队负责。
标签值命名规则
标签值要稳定、可匹配、可读。建议：
使用小写英文
中划线或下划线二选一
不要在标签值里放空格
不要混用缩写和全称
不要把多个含义塞进一个标签
不要写：
service=payment-prod-critical
应该拆成：
service=payment
env=production
severity=critical
展示给人的中文名称，可以放在协作空间名称、通知模板、CMDB 或映射表里。用于规则匹配的标签值，尽量机器友好。
不同告警源要映射到同一套标签
Prometheus、Zabbix、云监控和自研系统的原始字段通常不同。不要让每个源保留自己的标签体系，要统一映射到标准标签。
| 原始字段 | 标准标签 |
|---|---|
labels.app |
service |
labels.owner |
team |
| Zabbix 主机组 | team 或 service |
CMDB owner_team |
team |
CMDB service_name |
service |
| 云资源地域 | cluster |
| 云产品类型 | source_product |
能在源头改的，就在源头改。源头短期改不了的，再用 Flashduty 标签增强提取、映射或补齐。
标签增强、Pipeline 和路由的顺序
Flashduty 中告警处理的大致顺序是：
告警事件进入集成
→ 标签增强
→ 告警处理 Pipeline
→ 路由分发
→ 协作空间内降噪、分派、通知
简单原则：
| 问题 | 用什么能力 |
|---|---|
| 缺标签 | 标签增强 |
| 脏数据 | Pipeline |
| 归属空间 | 路由规则 |
| 通知给谁 | 分派策略 |
| 重复太多 | 降噪配置 |
不要把所有责任判断都写进 Pipeline。Pipeline 负责让告警变干净，路由负责决定进入哪个空间，分派策略负责决定通知谁。
标签如何支撑自动化
| 自动化能力 | 常用标签 | 设计重点 |
|---|---|---|
| 路由 | team、service、env、severity、cluster |
标签要少而稳定，必须有兜底路由 |
| 聚合 | service、check、resource、cluster、env |
先定义哪些告警应该一起处理 |
| 静默和抑制 | env、service、cluster、check |
少依赖标题和描述关键字 |
| 分派 | service、team、severity、env |
贴近责任边界和通知强度 |
| 分析 | service、team、source、check |
找出噪音来源和规则治理重点 |
落地步骤
- 选一个试点空间，不要全公司同时推进。
- 找 20 条真实高频告警，覆盖主要告警源。
- 列出现有字段，映射到标准标签。
- 决定哪些字段源头改，哪些用标签增强补。
- 用真实告警预览标签增强和 Pipeline 效果。
- 再配置路由、降噪、静默和分派策略。
顺序不要反。先有稳定标签，再写自动化规则。
上线验收清单
每条生产告警是否都有 service
每条生产告警是否都有 team
env 是否统一使用 production/staging/test/dev
severity 是否统一映射到 critical/warning/info/ok
resource 是否稳定，不会每次触发都变
check 是否能表达告警类型
共享集成路由是否能用 team 或 service 命中
无法匹配的告警是否进入兜底空间
Critical 告警是否能按 severity 命中分派策略
测试环境告警是否不会走生产电话升级
静默和抑制是否不用依赖标题关键字
分析看板是否能按服务、团队、来源看出噪音
常见问题
标签字段是不是越多越好？
不是。第一版只保留后续响应链路一定会用到的字段。字段越多，越容易出现命名不一致、值不稳定和规则不可维护。
service 和 team 有什么区别？
service 是告警影响的业务对象，team 是第一响应团队。路由和分派时，两者都重要，但含义不同。
中文标签值能不能用？
能用，但不推荐作为规则匹配字段。中文、空格、标点和大小写会增加跨系统匹配、脚本处理和模板维护成本。
什么时候用标签增强？
存量系统短期改不动时，用标签增强补字段、做映射、删敏感标签。高频告警源最终应该回到源头标准化。
为什么要有兜底空间？
兜底空间不是长期承接全部告警，而是暴露标签缺失、路由错误和规则遗漏。兜底空间告警越多，说明标签治理越需要优先做。
