质量规则的版本管理
质量规则既是配置也是资产：它决定告警行为，也决定指标口径，改动应当留痕。做法是把规则用代码或平台版本化，记录谁改的、改了什么、为什么改，变更走评审与回放验证。直接在生产页面调阈值不留记录，等告警行为变了再回头查，往往无从追溯，也无法快速回滚到上一版。
基本信息
| 管理方式 | Git 仓库代码化，或平台内置版本记录 |
|---|---|
| 变更流程 | 提交 → 评审 → 历史回放验证 → 发布 |
| 必要字段 | 规则 id、表、类型、列、阈值、级别、owner |
| 追溯内容 | 谁改的、改了什么、为什么改、何时生效 |
| 配套机制 | 规则与调度任务同仓，流水线自动跑自测 |
典型使用场景
- 阈值调整：通过提交记录说明调整依据与验证结果
- 规则新增：评审时确认影响的链路与告警级别
- 故障复盘：定位告警行为变化由哪一次规则改动引入
- 多环境同步：测试与生产使用同一份规则定义
- 人员交接：每条规则有 owner，接手人清楚它的意图与边界
规则定义（示例）
规则定义（示例）
# rules/orders.yaml
- id: orders_pk_unique # 规则唯一标识，告警与追溯都用它
table: dwd_orders_di # 作用对象
type: uniqueness # 规则类型
column: order_id
threshold: 0 # 允许的异常条数上限
severity: P1 # 告警级别，决定通知渠道
owner: data_team_a # 负责人，评审与处置的第一联系人
updated: 2026-10-12 # 最近一次变更日期变更留痕（Git）
变更留痕（Git）
git add rules/orders.yaml
git commit -m "rules: 调整 orders_pk_unique 阈值并写明依据" # 说明为什么改
git log -p -- rules/orders.yaml # 查看该规则的全部历史变更
git revert <commit> # 改动引入误报时回到上一版版本管理三要素
| 要素 | 做法 | 解决的问题 |
|---|---|---|
| 记录 | 规则入 Git，变更带提交说明 | 查得到谁在何时改了什么 |
| 评审 | 变更需 owner 与下游确认 | 避免单方面改口径影响他人 |
| 验证 | 合并前跑回放与自测 | 上线前就知道误报率与命中量 |
规则与调度任务同仓管理时，可以在发布流水线里自动跑规则自测，防止把坏规则带上线。
在平台页面直接改规则也要留痕：至少记录操作人、改前值、改后值与原因，否则等于没有版本管理。