数据质量规则分级：不是所有异常都该半夜叫人
一、质量监控太敏感，会把团队训练成忽略告警
数据质量监控是数据治理的基础。空值、重复、波动、延迟、枚举异常都要检查。但如果所有异常都用同一等级告警，很快就会告警疲劳。半夜被低风险字段波动叫醒几次后，真正严重的问题也可能被忽视。
数据质量规则需要分级。哪些问题会影响核心指标，哪些只影响边缘报表，哪些可以工作时间处理。分级不是降低要求，而是让处理优先级和业务影响匹配。
二、按影响面、紧急度和可恢复性分级
质量规则可以按 P0 到 P3 管理。P0 影响核心指标或数据安全，立即处理；P1 影响重要报表，当日处理；P2 影响局部分析，排期处理；P3 只是提示。
flowchart TD A[质量规则触发] --> B[判断影响面] B --> C[判断紧急度] C --> D[判断可恢复性] D --> E{等级} E -->|P0| F[立即告警] E -->|P1| G[工作群通知] E -->|P2| H[生成治理任务] E -->|P3| I[记录趋势]同一条规则在不同表上等级也可能不同。核心指标表的空值，比临时分析表的空值严重得多。
三、规则配置要带负责人和处理动作
质量规则如果只定义阈值，没有负责人和处理建议，触发后还是没人管。
rule_id: order_amount_not_null table: dwd_order_item_di field: pay_amount check: not_null severity: P0 owner: data_platform action: "暂停下游核心指标产出，检查订单同步链路"规则配置里写清处理动作，可以降低排障时间。尤其是 P0 规则，不能只告诉人“出错了”，还要告诉人第一步查哪里。
四、质量规则要评估误报和漏报
规则上线后，要看触发频率、处理时长、误报比例和漏报案例。一个每天触发但没有业务影响的规则，应该降级或调整阈值。一个从不触发却漏掉事故的规则，说明覆盖不够。
还要处理依赖关系。上游表延迟会导致多个下游规则同时报警。系统应合并根因相同的告警，避免一处延迟炸出一屏通知。
最后，质量规则要和数据 SLA 绑定。核心报表的产出时间、完整性和准确性，都应该有可观测指标。规则不是治理的终点，而是治理动作的入口。
规则还要有静默窗口。大促、迁移、历史回刷期间，部分规则可能会预期触发。静默不是关闭治理，而是给特殊操作设置审批、时间范围和复盘要求。没有记录的静默，会让真实事故被掩盖。
根因分析要沉淀到规则库。一次空值事故如果来自上游接口字段变更，就应该增加 schema 变更检测，而不是只修当天数据。质量治理的成熟度，体现在规则能从事故中变得更准。
最后，质量看板要看趋势。单次触发只是事件，长期误报率、修复时长和重复问题才反映治理水平。数据质量不是靠一次巡检变好，而是靠规则、流程和负责人持续闭环。
质量规则还应接入发布流程。新表上线前，至少要配置主键、分区、行数波动和核心字段校验。旧表新增字段时，也要同步补规则。等事故发生后再补监控，治理成本会高很多。
告警文案也要可执行。只写“表异常”没有意义，应包含表名、分区、规则、当前值、阈值、负责人和建议动作。值班人员看到告警时，第一眼就应该知道该查同步、查上游，还是查口径变更。
最后，分级要定期复盘。业务重点变化后，原来的 P2 表可能变成核心链路，原来的 P0 规则也可能不再关键。规则等级如果不更新，监控会慢慢偏离真实业务风险。
五、总结
数据质量规则要按业务影响分级。P0 立即处理，P1 当日处理，P2 排期治理，P3 记录趋势。规则配置应包含负责人、阈值、处理动作和依赖关系。好的质量监控不是异常越多越专业，而是让真正重要的问题被及时看见。
