数据指标 SLA：报表准时不代表指标可信

一、SLA 不能只看任务成功

很多数据团队把 SLA 理解成调度任务准时完成。确实，任务失败会影响报表使用，但指标可信度不只取决于任务状态。数据是否完整、口径是否变更、上游是否延迟、质量规则是否通过，同样决定看板能不能被使用。

指标 SLA 应该描述"这个指标在什么时间、什么质量条件下可以被信任"，而不是只描述任务有没有跑完。

为什么"任务成功 ≠ 指标可信"这件事容易被忽视？因为大多数调度系统（Airflow、DolphinScheduler）的 DAG 状态只有三种：成功、失败、运行中。任务标记为"成功"只说明 SQL 跑完了没报错，不代表数据是对的。上游 ODS 表延迟了 30 分钟，你的 DWD 任务仍然能"成功"——它只是扫了一个还没更新完的表。业务方看到报表准时出了，拿去给老板汇报，回头发现数据差了一大截。SLA 的任务是防止这种事发生——在报表被人使用之前，先自检一遍数据是否真的可用。

二、指标 SLA 要覆盖链路

flowchart TD A[上游数据到达] --> B[清洗任务完成] B --> C[质量校验通过] C --> D[指标产出] D --> E[BI 刷新] E --> F[可用状态]

任何一环异常，都可能让指标不可用。上游日志延迟、维表未更新、质量规则失败、BI 缓存没刷新，都应该进入 SLA 视野。

metric_sla: metric: daily_gmv ready_before: "09:30" max_delay_minutes: 20 require_quality_pass: true notify_on_partial_data: true

require_quality_pass很关键。任务跑完但质量没过，指标不应该显示成正常。

为什么require_quality_pass是 SLA 里最重要的字段？因为质量校验是在任务"成功"之后但数据"可用"之前的最后一道关卡。如果昨天 GMV 的日环比波动在 ±5% 以内，今天突然涨了 200%，质量规则应该捕获并暂停 SLA。没有这个字段，SLA 只会告诉业务方"数据在 09:30 之前出了"，不会告诉业务方"这个数据可能是错的"。

三、状态要面向使用者

type MetricStatus = { metric: string status: "ready" | "delayed" | "partial" | "failed" updatedAt: string reason?: string }

BI 看板可以把指标状态展示出来。比如"数据已更新至 08:50，上游支付流水延迟，今日 GMV 暂不可用于最终判断"。这比静默展示一个不完整数字更负责。

指标状态还要区分 partial 和 failed。部分数据可用时，运营可能可以观察趋势，但不能做最终结论；完全失败时，则需要隐藏或标红。

四、SLA 要和通知闭环绑定

指标延迟时，通知对象要明确。数据工程师需要知道任务和日志，分析师需要知道哪些看板受影响，业务方需要知道数据能不能用。一个告警打给所有人，只会让每个人都觉得和自己无关。

sla_notification: data_engineer: message: task_and_table analyst: message: metric_and_dashboard business_user: message: availability_and_eta

还要记录 SLA 违约原因。长期因为同一个上游延迟，说明应该改采集或调整指标发布时间；长期因为质量规则误报，说明规则需要重新校准。SLA 不是用来贴罚单的，而是发现系统性问题。

指标口径变更也要进入 SLA。如果今天任务准时完成，但 GMV 口径刚改过且没有通知，下游仍然会误读。可信指标不仅要准时，还要可解释、可追踪。

最后，可以给核心指标做可用性月报：准时率、质量通过率、延迟原因、影响看板、平均恢复时间。数据团队用这些指标管理自己的交付质量，才算把工程化落到实处。

SLA 还要和指标等级绑定。核心经营指标可以要求更早产出、更严格质量校验和更快恢复；低频分析指标则可以接受较长延迟。所有指标使用同一套 SLA，看似公平，实际会浪费资源。

metric_sla_tier: p0: ready_before: "09:00" max_recovery_minutes: 30 p2: ready_before: "12:00" max_recovery_minutes: 240

分级之后，团队才能把工程投入放在真正影响决策的指标上。

为什么 SLA 分级不是"内卷"而是"资源优化"？一个常见的错误是给 200 个指标全设ready_before: 09:00。结果 ETL 每天早上 6 点到 9 点跑满集群资源，所有指标都抢计算和 IO。P0 指标（比如 GMV、DAU）可能只需要 5 个表的数据，但因为 P2 指标（比如"新手引导第 37 步的点击率"）也在同时跑全量聚合，占用了大批资源，导致 P0 被拖慢了 20 分钟。SLA 分级就是给 P0 留"快车道"：8:00-9:00 集群只跑 P0 任务，9:00 以后再来跑 P2。这不是优待某个指标，是保证最重要的事情先完成。

🚨 踩坑提醒

1. 不要把ready_before设成任务的schedule_interval + 1 分钟。许多团队设"任务 8:00 跑，SLA 9:00 前完成"，看起来留了一小时 buffer。但上游日志如果延迟了 40 分钟才到，任务 8:40 才开始跑，9:00 根本完不成。ready_before应该从业务的"用数时间"倒推，而不是从调度时间正推。如果业务 9:00 开会要用数，SLA 至少设 8:30，预留 30 分钟应急窗口。

2. partial 状态不标注原因等于没标注。看板上显示"数据部分可用"，但不说哪些维度缺失、缺了多少，运营还是不敢用。标准格式是"2026-07-01 GMV：已完成省份维度（31省中有 28省），缺失广东/浙江/江苏（上游支付流水延迟），预计 10:30 补齐"。给具体的、可操作的信息。

3. SLA 违约告警不能只发钉钉/企微，要落到 BI 看板的指标状态栏上。因为业务方开会时不一定看手机，但一定在看报表。如果看板上每个指标旁边有一个小绿灯/黄灯/红灯，看一眼就知道哪些指标能信、哪些不能信——这才是 SLA 的最终价值：不是给数据团队看的，是给用数的人看的。

五、总结

数据指标 SLA 要覆盖任务、质量、上游、BI 刷新和口径变更，最终面向使用者给出可用状态。

报表准时不代表指标可信。真正的 SLA，是让读者知道什么时候可以放心用数据做决策。