4、业务需求分析：如何与业务方沟通、识别关键数据资产、定义可接受延迟
说实话，很多团队做数据新鲜度 SLA 时，第一步就栽了。
他们直接拍脑袋定个「所有表 10 分钟必须更新完」，然后被业务方追着骂。或者反过来，业务方说「我要实时」，技术团队就硬上实时管道，成本翻了三倍，最后发现人家只是随口一说。
我自己的经验是：新鲜度 SLA 的起点，永远在业务会议室，不在技术监控大屏上。这一章，我们就聊聊怎么跟业务方聊明白，怎么找出真正重要的数据，怎么把「我要快」翻译成「延迟 X 分钟以内可接受」。
4.1 为什么业务沟通是 SLA 的基石？
先讲个我踩过的坑。
几年前我负责一个电商数据平台。运营团队天天抱怨「数据太旧了」，我们加班加点把核心报表的延迟从 2 小时压到 15 分钟。结果呢？人家根本不买账。后来一聊才发现——他们说的「旧」，不是延迟问题，是数据口径对不上。
你看，如果一开始没聊透，技术团队很容易把力气用错地方。
业务沟通要解决三个核心问题：
- 对齐认知：业务方说的「实时」到底是秒级、分钟级还是小时级？
- 暴露真实需求：哪些数据是决策必须的？哪些只是「有更好」？
- 划定责任边界：延迟是技术问题还是业务输入问题？
核心原则：不要替业务方做决定，但要帮他们理解代价。每次延迟压缩，背后都是成本、复杂度和稳定性的权衡。
4.2 与业务方沟通的「三步法」
我习惯把沟通流程拆成三步。每一步都有明确产出，避免聊完就忘。
第一步：场景访谈——搞清楚数据怎么用
别一上来就问「你要多快」。先问场景。
- 这个数据用在什么决策上？（日常运营？风控？战略分析？）
- 决策频率是多久一次？（每小时看一次？每天早会看一次？）
- 如果数据晚到 10 分钟，会有什么后果？（错过促销调整？还是只是报表晚刷新？）
- 如果数据错了，你们能接受吗？（有些场景宁可延迟也要准确）
举个例子。我跟一个广告投放团队聊，他们说「需要实时数据」。追问下去才发现：他们每天上午 10 点做一次预算调整，下午 3 点再看一次效果。所谓「实时」，其实是「我希望 10 点能看到截止到 9:55 的数据」。那延迟 5 分钟完全够用。
第二步：代价可视化——让业务方看到成本
这一步很关键。业务方通常不知道「降低延迟」意味着什么。
我会画一张简单的对比表：
| 延迟目标 | 技术方案 | 月成本估算 | 稳定性风险 |
|---|---|---|---|
| T+1（隔天） | 离线批处理 | 低 | 极低 |
| 小时级（1-6h） | 微批次调度 | 中 | 低 |
| 分钟级（5-30min） | 流处理 + 微批次 | 高 | 中 |
| 秒级（< 1min） | 实时流处理 | 极高 | 高 |
把这张表摆出来，业务方通常会自己调整预期。「嗯，其实小时级也能接受，没必要花那么多钱。」
第三步：达成共识——形成书面 SLA 草案
聊完不能白聊。我会当场输出一份简单的 SLA 草案，包含：
- 数据资产清单（哪些表/指标）
- 可接受延迟（具体到分钟或小时）
- 例外条款（大促期间、数据源故障时怎么办）
- 双方确认签字
一个小技巧：SLA 草案里留一个「业务方免责条款」。比如「因上游业务系统未按时提供数据导致的延迟，不计入 SLA 违约」。这样业务方不会因为担心背锅而乱提要求。
4.3 识别关键数据资产：二八法则
不是所有数据都值得上 SLA。我见过最夸张的团队，给 2000 张表都定了 SLA，结果运维团队天天报警，业务方根本不在乎。
识别关键数据资产，我遵循「二八法则」——20% 的数据支撑了 80% 的业务决策。
筛选标准
- 决策影响度：这个数据直接影响业务决策吗？比如 GMV、DAU、库存水位。
- 使用频率：每天被多少人、多少系统调用？
- 下游依赖：有多少下游报表、模型、API 依赖它？
- 合规要求：监管或合同要求必须在某个时间内更新？
我会跟业务方一起，把数据资产按这四个维度打分。总分高的，进入 SLA 管理范围。
一个真实案例：某金融公司有 500 张表，我们筛选后只对 47 张核心表定了 SLA。结果 90% 的业务投诉都集中在这 47 张表上。剩下的表，业务方根本不在意延迟。
4.4 定义可接受延迟：从模糊到精确
「尽快」不是 SLA。「实时」也不是。可接受延迟必须是一个可测量、可验证的数字。
延迟分类法
我通常把延迟分成三类，跟业务方逐类确认：
| 延迟类型 | 定义 | 典型场景 | 示例 |
|---|---|---|---|
| 端到端延迟 | 从数据产生到业务可见的总时间 | 实时风控、交易监控 | 支付事件 → 风控模型 → 返回结果，< 100ms |
| 批处理延迟 | 从数据就绪到完成计算的时间 | 日报、周报、财务结算 | 每日凌晨 3 点前完成昨日数据汇总 |
| 近实时延迟 | 数据产生后几分钟内可见 | 运营看板、实时推荐 | 用户行为发生后 5 分钟内进入推荐模型 |
如何量化「可接受」？
我会问业务方三个问题：
- 「数据晚到多久，你会开始觉得不爽？」——这是「感知阈值」
- 「数据晚到多久，你会无法做决策？」——这是「容忍上限」
- 「数据晚到多久，你会因此遭受实际损失？」——这是「违约阈值」
SLA 的延迟目标，通常定在「感知阈值」和「容忍上限」之间。比如业务方说 5 分钟开始不爽，30 分钟无法决策，那 SLA 定 15 分钟就合理。
注意：不要把 SLA 定在「容忍上限」附近。一旦出现波动，很容易违约。留 30%-50% 的缓冲空间是明智的。
4.5 知识体系：业务需求分析流程
下面这张图总结了我做业务需求分析的核心流程。每次跟新业务方合作，我都会走一遍这个闭环。
4.6 避坑指南：我踩过的几个坑
最后分享几个真实教训，希望能帮你少走弯路。
- 「业务方说实时，你就信了」——我曾经给一个运营团队上了实时管道，成本翻倍。后来发现他们只是每天下午看一眼数据。多问一句「你什么时候用」，能省很多钱。
- 「只聊一次就定 SLA」——业务需求会变。我建议每季度 revisit 一次 SLA。大促、新产品上线前，必须重新确认。
- 「忽略非功能性需求」——业务方只关心延迟，但你要主动问「数据准确性重要还是速度重要？」「周末和节假日延迟要求一样吗？」这些细节不聊透，后面全是坑。
- 「SLA 定得太死」——我见过一个团队把延迟定在 5 分钟，结果每次网络抖动都报警。后来改成「95% 的请求在 5 分钟内完成」，压力小了很多，业务方也没意见。
我的习惯：每次跟业务方聊完，我会发一封确认邮件，把共识写清楚。邮件里加一句「如果以上理解有误，请在 3 个工作日内反馈」。这招帮我避免了很多「我没说过」的纠纷。
好了，业务需求分析这部分就聊到这儿。说白了，跟业务方沟通不是技术问题，是翻译问题——把业务语言翻译成技术指标，再把技术代价翻译回业务语言。翻译做好了，SLA 就成功了一半。