给指标承诺产出时间
为指标标注时效级别，例如次日晨间、次日上午、小时级、分钟级，并监控产出时间的达成率；延迟时自动通知消费方，先公告再修复。SLA 要与值班和告警联动，不同级别配置不同的告警通道与响应要求。所有指标共用一个宽泛的 SLA 等于没有 SLA，因为没有人能从中判断自己依赖的指标是不是已经违约。
基本信息
| 分级 | 次日晨间、次日上午、小时级、分钟级 |
|---|---|
| 监控 | 产出时间达成率 |
| 告警 | 超时自动通知消费方与值班 |
| 联动 | 与值班制度、响应时限挂钩 |
| 公告 | 延迟先公告，修复后复盘 |
典型使用场景
- 关键经营日报的产出时间保障，晨会前必须就绪
- 大促期间时效要求升级，切换为小时级监控
- 下游系统依赖的上游指标，提前约定产出时点
- 延迟公告：让消费方知情并调整决策节奏
- 季度复盘：统计各指标的 SLA 达成率，推动链路优化
- 上游任务改动后重新评估产出时点，避免连带违约
- 按级别配置告警通道，避免所有延迟都触发同一种通知
- 新建指标时同步登记承诺产出时点与责任团队
达成监控
达成监控
-- 达成监控：实际产出时间与承诺时点比较
SELECT metric_code, dt, finished_at,
CASE WHEN finished_at <= sla_time THEN 1 ELSE 0 END AS sla_ok
FROM metric_task_run
WHERE dt = '2026-10-12';
-- 达成率：按月统计各指标的达标比例要素说明
| 要素 | 说明 | 异常表现 |
|---|---|---|
| 分级 | 不同指标不同承诺时点 | 共用一个宽泛 SLA 形同虚设 |
| 监控 | 产出时间与承诺比对 | 无监控则用户先发现延迟 |
| 告警 | 超时自动通知 | 只预警不通知，消费方不知情 |
| 公告 | 延迟说明与预计恢复时间 | 不公告会导致决策用错数 |
SLA 承诺要与实际能力匹配：链路本身要跑到上午十点，却对外承诺八点产出，只会持续违约并消耗信任。
延迟公告比修复本身更重要：消费方知道数据晚到，可以调整决策时点；不公告则可能直接拿旧数据做判断。