数据质量 SLA 治理：从定义到责任闭环

数据质量治理最容易被误解的地方，是以为"质量"等于"检测规则"。实际上规则引擎解决的是"这一行数据对不对"，而数据质量 SLA 解决的是"这份数据能不能按承诺被消费"。两者分层：SLA/SLO 定义承诺，规则与监控是度量承诺的手段。数据质量 SLA 治理的核心动作是三个：把质量承诺写成可度量的目标，围绕目标建立告警与升级机制，再把目标绑定到具体的人与团队形成责任闭环。

先厘清 SLA、SLO、SLI 三个词的关系。SLI（Service Level Indicator）是可量化的质量指标，比如"订单表每日 08:00 前完成更新""核心表非空字段缺失率低于 0.1%"；SLO（Service Level Objective）是基于 SLI 设定的目标值，是团队承诺要达到的阈值；SLA（Service Level Agreement）是面向数据消费方（下游分析师、业务报表、模型训练）的正式承诺，往往附带未达标时的后果与处理流程。三者是"指标→目标→协议"的递进：没有 SLI 的 SLA 是一句空话，没有 SLO 的 SLI 只是一堆监控数字。业界实践（如 dbt 的数据 SLA 最佳实践）通常建议从 SLO 开始，先给关键表定目标，再逐步升级为正式 SLA。

数据质量 SLA 该定义哪些维度？围绕"消费方何时能依赖这份数据"，最常用的是四类。第一是新鲜度（freshness）：数据多久更新一次、最晚什么时候必须到位，例如"每日报表数据在次日 08:00 前就绪"。第二是完整性（completeness）：关键字段的非空比例、行数与上游的匹配度，例如"订单表行数波动不超过前 7 日均值的 5%"。第三是可用性（availability）：表与任务在承诺时间内可查询、可运行，例如"核心表月度可用性不低于 99.5%"。第四是准确性（accuracy）：与权威源的偏差，例如"对账差异率低于 0.01%"。TDWI 的研究（WP047）也强调，质量维度要按业务影响裁剪，不是维度越多越好，而是把资源集中在消费方感知最强的维度上。

度量是 SLA 治理的技术底座。每个 SLI 需要明确三件事：数据来源（监控任务的输出、数仓系统表、还是日志）、统计口径（时间窗口、过滤条件、聚合方式）、以及基线。基线尤其关键：很多质量指标是相对值，比如"行数波动""延迟分布"，需要先积累一段时间的历史数据算出正常范围，再据此设定阈值，而不是拍脑袋定一个绝对数字。阈值要区分"硬阈值"（触发即告警）与"趋势阈值"（连续 N 天恶化才告警），前者抓急性问题，后者抓慢性退化。度量结果要落库并保留历史，否则无法做趋势分析和复盘。

告警与升级机制决定 SLA 能否被兑现。核心原则是"告警要少而准"：告警疲劳是 SLA 治理最常见的失败模式之一，当告警每天刷屏，团队就会习惯性忽略，真正的故障反而被淹没。缓解手段包括分级告警（P1 立即强提醒，P2 工作时间处理，P3 仅记录）、聚合告警（同类问题合并成一条）、以及延迟确认（连续两个周期触发才升级）。升级路径要提前设计好：告警先到数据 owner，owner 未在约定时间内响应则升级到 on-call 负责人，再升级到平台团队。gable.ai 关于数据 SLA的实践指出，升级路径的价值不在"找到背锅的人"，而在保证任何一条质量告警最终都有人处理、有明确时限。

责任闭环是把 SLA 从技术指标变成组织机制的关键，四个要素缺一不可。一是 owner：每张关键表必须有明确的数据 owner，owner 对表的 SLA 负责，owner 缺失是 SLA 悬空的头号原因。二是 on-call：面向关键表的告警要有轮值机制，确保非工作时间也有人响应。三是复盘：SLA 违约后做轻量复盘，回答"度量口径是否合理、根因是什么、如何防止复发"，复盘结论要回流到规则与任务配置。四是 SLO 预算：给每个 SLO 设一个可接受的违约额度（error budget），比如"每月允许 0.5% 的时间不达标"，预算耗尽即停止该表的快速迭代、优先修复质量。dbt 与 decube 等团队的实践都验证了同一个结论：没有责任闭环的 SLO 只是报表，有了闭环才变成治理。

落地时按五步推进。第一步盘点：梳理核心数据资产，按消费方影响排序，圈出首批纳入 SLA 的表，通常 10 到 30 张即可，不要贪多。第二步定义：为每张表选定 2 到 3 个维度，写出 SLI 的精确口径并指派 owner。第三步度量：把监控任务接入调度，积累至少两周基线，再设定阈值与告警级别。第四步闭环：建立告警响应、升级、复盘的流程，把 SLO 预算写进团队例会。第五步扩展：稳定运行一个季度后，再按同样流程扩展到下一批表。常见失败模式除了告警疲劳和无 owner，还有指标口径不清：同一张表的"新鲜度"在不同团队眼里可能是完全不同的定义，口径必须在定义阶段书面固化，并在后续变更时走评审。

度量体系要尽量复用现有设施，而不是为 SLA 另起炉灶。SLI 的数据来源通常是现成的：任务调度系统能告诉你任务几点跑完（新鲜度）、数仓元数据里有表行数与分区信息（完整性）、监控平台已经在采集查询延迟与失败率（可用性）。建议的集成方式是：SLA 层只负责"定义与裁决"，从这些系统拉取指标、按口径计算 SLI、与 SLO 阈值比较并触发告警，而不是重新采集一遍数据。一个新鲜度 SLI 的典型计算是：取表最近一个成功分区的时间戳，用当前时间减去它得到延迟时长，再与"目标延迟"比较；口径里要写清楚"成功分区"如何判定（是任务成功标记还是数据校验通过），否则任务标记成功但数据为空时，新鲜度指标会给出假阳性。这类口径细节要在定义阶段与数据团队逐条确认，并把确认结果写成文档，作为后续评审的依据。准确性维度在落地时最容易变成"摆设"，因为它依赖外部权威源；可以先从已有对账机制的表（如交易对账、库存核对）开始定义准确性 SLI，没有权威源的维度宁可暂缓，也不要用估算值冒充度量。

最后给一个可执行的下一步：从你的核心报表链路里挑一张"延迟一小时就会引发业务投诉"的表，为它写出一条 SLI（比如"每日 08:00 前数据就绪"），挂上监控与 owner，运行两周后回顾。你收获的不只是一个指标，而是一套可以复制到其他表的治理模板。