微批管道的端到端延迟 SLI 到底锚定「事件到 broker」还是「批次可查询」：批窗口的结构性延迟该不该算进 SLO？

【背景】 做了 8 年算法，近两年主做 B 端指标体系与数据管道。核心链路：Kafka（16 分区）→ Flink 微批聚合（微批窗口 10s，watermark 允许 30s 迟到）→ ClickHouse → 业务看板。业务方对新鲜度的要求是「事件发生后 90s 内可查」，这条 SLA 我们目前只写在指标字典文档里，没有对应的可执行 SLI。

【现象：从现象倒推，我觉得问题出在「延迟的起点定义」上】 1）同一条事件，选不同锚点算出来的延迟差一个量级：event_time → Flink 写出（3~15s）、event_time → 批次可查询（15~120s）、ingest_time（到 broker）→ 可查询（10~105s）。批窗口的结构性延迟（事件落进哪个微批、watermark 何时推过它）最大能贡献 40s，占「90s SLA」的近一半——这部分是架构决定的，不是故障； 2）真正伤人的是混账：上次一次 Flink checkpoint 卡顿导致的真实延迟劣化（P99 从 25s 涨到 80s），如果 SLI 锚定在「批次可查询」，它和批窗口正常波动混在一起，告警阈值怎么定都别扭——定低了天天误报「SLA 违约」，定高了真劣化 30s 才发现； 3）低流量时段更糟：凌晨 2 点某分区 10 分钟才来一条数据，「最新事件延迟」这个点会一直顶在 600s，但管道本身完全健康。

【已尝试的排查与结果】

• 方案 A：只监控 Flink 自身指标（checkpoint duration、busy、backpressure），能发现故障但对「事件视角的新鲜度」无感，业务方不认；
• 方案 B：每条事件打 event_time + ingest_time 双时间戳，SLI 定义为「每个滚动 5 分钟窗口内，该窗口所有事件的 (可查询时刻 − ingest_time) 的 P99」，跑了两周：低流量窗口的 P99 被个别迟到事件（上游批量导出、客户端时钟偏差）打到 300s+，SLO error budget 被合法迟到事件吃光，告警失去意义；
• 方案 C：直接对「可查询时刻 − event_time」做 P99 告警，等于把批窗口结构性延迟也计进去了，阈值被迫放到 150s，业务方要求的 90s SLA 反而没落下来，且真实劣化被结构性延迟掩盖。

【期望得到的答案形态】 想请教真正在微批/流式管道上把「数据新鲜度 SLI + SLO」跑起来的团队： 1）你们的新鲜度 SLI 锚点到底选哪个（event_time 起点还是 ingest_time 起点），低流量窗口的 P99 被迟到事件打爆怎么处理的——是剔除（怎么界定合法迟到）、换 TopK、还是分位数换口径？ 2）批窗口的结构性延迟（batch 间隔 + watermark 容差）你们是怎么在 SLA 里显式建模的：是把它从端到端延迟里扣掉、单独作为「管道延迟 SLI + 批窗口延迟预算」两段分别定 SLO，还是直接接受它计入、把业务 SLA 整体放宽？有没有具体的阈值拆分示例？ 3）checkpoint 卡顿这类真实劣化，你们靠哪个指标在 1 分钟内发现（而不是等新鲜度 P99 漂移）？

【站内关联】 这个问题和我之前问的「指标 SLA + 上游依赖监控」（#479）是互补的：那边解决「数据到没到、齐不齐」，这边解决「到了但慢了多少、慢的账算在哪一段」；阈值定法上参考了社区讨论的 SLO「目标 vs 预算」拆解思路（#1633）。