“这个看板要实时。”
运营负责人说完这句话，把笔往桌上一放。会议室里安静了两秒。产品经理点点头，像是需求已经说清楚了；数据开发低头看电脑，开始估 Kafka、Flink、存储和人力；坐在角落里的分析师翻开旧报表，发现大家甚至还没有确认“成交”到底按支付还是发货算。
我见过不少实时项目，就是从这五个字开始长大的。它们先长出一套流式链路，再长出一套指标服务，最后长成一张每月都要有人解释成本的账单。至于业务在数据刷新后的两分钟里究竟会做什么，反而没人再问。
这事有点像在餐馆催菜。顾客说“快一点”，厨师不能据此购买一条自动化流水线。他得先问：你是赶火车，还是只是饿了？一道凉菜晚五分钟和一锅汤晚五分钟，不是同一种晚。
看板也是如此。实时不是一个技术频率，而是一个业务动作还能来得及发生的时间窗口。
如果这句话不先说清楚，团队很容易把所有“想早点看见”都翻译成“必须秒级更新”。这通常很贵，也未必有用。
先别谈架构，先问数据晚到以后损失什么
需求评审最容易出现的一幕，是业务讲完“要实时”，技术马上打开架构图。大家开始讨论消息队列吞吐、状态存储、维表关联和机器规格。讨论很专业，问题却还停留在门口。
Google 的 SRE 方法里有一个很朴素的提醒：先理解用户在意什么，再选指标；数据处理链路通常关注吞吐和端到端延迟，同时不能忘记正确性。Datadog 的 SLO 清单也把数据管道拆成两件事：结果是不是对的，以及新数据多久能出现。
这两条放到看板评审里，就是一句大白话：
业务需要的不是“链路很快”，而是“在还来得及行动时，看到足够可信的数据”。
这里先把三个容易混用的词分开：
- SLI 是实际怎么量，例如“从支付事件发生到页面可用的分钟数”或“已进入实时口径的订单占比”；
- SLO 是这些指标要达到什么目标，例如“大促时段内，95% 的有效订单在 5 分钟内可见”；
- SLA 是服务双方围绕这些目标形成的协议，还要写清衡量窗口、责任和未达标后果。
本文标题沿用团队常说的“数据 SLA”，但下文的三档不是给刷新频率换个名字。它们指业务使用方与数据提供方共同确认的内部数据服务协议：里面可以有一个或多个 SLO，也必须说明谁承诺、怎样量，以及目标没达到时谁做什么。未达标后果未必是商业合同里的赔偿，也可以是页面降级、暂停依赖动作、升级事故或重新评审服务范围；如果只有一个目标数字而没有这些约定，它就仍是 SLO，不是完整的 SLA。
所以我通常不先问“你要几秒”。我先问：“如果这条数据晚十分钟，你会错过什么动作？”
答案如果是“客服无法在投诉扩散前拦截”“大促库存已经卖穿”“支付成功率异常却没人止损”，那确实接近秒级或分钟级问题。
答案如果是“领导希望早点看”“日报早上九点会用”“下午复盘时想看到上午趋势”，那多半不需要一条 24 小时全速奔跑的实时链路。
还有一种答案更诚实：“暂时也不会做什么，就是想先看看。”这不丢人。探索需求可以有，只是它不该穿着生产级 SLA 的外套进预算会。
第一个问题：数据出现以后，谁要改变什么动作
“谁”和“动作”必须同时出现。
只有“运营会看”，不够。要继续问：运营看见以后，是暂停投放、调整优惠券、联系仓库，还是在群里发一句“大家关注一下”？这些动作的时限、风险和自动化程度完全不同。
可以把一次实时需求写成这样：
| 看到什么 | 谁处理 | 准备做什么 | 最晚何时有用 |
|---|---|---|---|
| 支付成功率连续下降 | 值班运营 | 暂停异常渠道并通知支付团队 | 3 分钟内 |
| 单仓可售库存跌破阈值 | 区域运营 | 停止继续分配流量 | 10 分钟内 |
| 当日 GMV 低于目标 | 经营负责人 | 调整下午投放节奏 | 1 小时内 |
| 昨日渠道 ROI 偏低 | 投放团队 | 修改次日预算 | 次日上午前 |
表里的时间只是示例，不是行业标准。真正重要的是：每一个时间后面，都有一个动作。
如果动作要等人开会、审批、再通知，系统提前 30 秒把数字送达，并不会让组织突然拥有 30 秒反应能力。数据跑得像兔子，流程还在门口系鞋带，这是企业里很常见的景象。
反过来，如果动作已经自动化，例如欺诈规则触发后立即阻断，那么秒级信号才有明确价值。此时看板甚至不是主要载体，告警和自动控制才是。
所以第一问不是在限制业务，而是在给实时找一个正当用途：数据必须进入动作，速度才有意义。
第二个问题：从哪一个时刻，到哪一个时刻，算“延迟”
很多团队说看板五分钟更新一次，实际测的是调度间隔。源系统 10:00 发生一笔订单，10:07 才进消息队列，10:10 完成聚合，10:12 被指标服务缓存，10:15 页面自动刷新。页面上写着“每 5 分钟更新”，业务看到的却是 15 分钟前的世界。
“五分钟”没有错，只是它测错了路段。
数据看板真正该关心的，是从业务事件发生，到结果可用于判断的端到端延迟。至少要把这条路拆开：
- 事件进入源系统的时间：订单、支付、库存变化何时真实发生；
- 采集可见时间：变化何时被 CDC、日志或接口捕获；
- 处理完成时间：清洗、关联、聚合何时得到可用结果；
- 服务可见时间：缓存、语义层或接口何时提供新值；
- 页面可见时间：用户何时真正看到并能操作。
