周一早上九点，经营看板上 GMV 比上周同期低了三成，老板在群里 @ 了三个人。这道场景题我几乎每次都出，因为它比任何指标设计题都更能看出一个人有没有真的值过班。
约一半的候选人会直接开始分析业务：是不是大促结束了、竞品在补贴、某个渠道掉量、支付通道出了问题。这些假设本身都合理，问题是顺序错了。在没有确认数据本身没坏之前，任何一个业务解释都可能让你花一整天去论证一个不存在的现象。
本系列第 3/10 篇 · 上一篇：一道埋点题，能问出三年经验 · 下一篇：A/B 实验题里最常见的四种错
把链路横着切三层
我的第一反应永远是问：这是业务变了，还是数据变了。数据从产生到被看见，粗分成采集、计算、展示三层，逐层排除。
采集层看有没有东西没进来。前一天晚上发过客户端版本吗，SDK 升级过吗，上报网关或域名改过吗，灰度把一部分流量切到新链路了吗，客户端缓存的事件是不是积压后集中补报到另一个小时去了。这类问题的特征是断点和发版时间高度吻合，且往往只影响某个端或某个版本。
计算层看有没有东西算丢了。上游分区是否按时产出，调度有没有延迟或重跑，维表关联键是不是变了类型导致 join 大面积丢行，去重逻辑有没有被改，金额单位（分 / 元）、币种、时区是否统一，退款与取消订单的口径有没有调整。这一层最阴险，因为任务状态全是成功，日志里没有一行异常，只是结果少了一块——本系列第 1 篇说的「没有报错的退化」，在这里同样成立。
展示层看有没有东西被挡住了。看板筛选器默认值被人改过、缓存没刷新、权限调整后当前角色只能看到部分门店、同比对齐错位（今年这周和去年那周的节假日不在同一位置）、以及最容易被忽略的：这张卡片读的是不是昨天临时切过去的备用表。
三层排完，再加一个判断题：订单行数跌没跌。金额跌了但行数没跌，先怀疑单价、币种、退款口径或某个大额订单；行数和金额同步跌，才更可能是流量或采集链路的问题。这一刀能把候选假设砍掉一半，比拉十几张图表有用。
对账要有第二个信源
同一个数仓内部怎么翻都是自证。我要求找一个独立信源交叉验证：订单库的服务端记录、支付网关的对账文件、客户端的关键事件条数，甚至是财务手里的日报。两者从同一天开始偏离，偏离点在哪一侧，责任基本就定了。
第二个动作是看曲线的形状。按小时把 GMV 铺开：整点断崖式归零，多半是分区没产出或任务没跑；从某个时刻起整体降一档但曲线形状还在，像是口径或过滤条件变了；缓慢下滑且各渠道同步，才更像真实业务变化。第 1 篇里提到的时间轴在这里同样管用——把发版、调度变更、权限变更都画上去。
第三个动作是按维度拆：是所有渠道、所有端、所有地区一起跌，还是只有某一个切片跌。全部齐跌优先怀疑公共链路，单一切片优先怀疑该切片自己的采集或业务。
沟通上我有一条硬规矩：群里第一句只说「正在核对，X 点前给结论」，不给未经验证的解释。数据产品经理最消耗信任的行为，是半小时内给出一个听起来很合理的业务原因，两小时后自己推翻它。宁可先承认还没定位，也别让一个错误结论被写进周报再传播出去。
补完数，事情才做了一半
定位到根因之后的追问，才是这题真正的分水岭。
补数不是把源表重跑一遍就完了。下游的汇总表、宽表、看板缓存、对外推送的日报、甚至已经发出去的邮件截图，都要跟着回刷或说明。历史曲线要不要重画，重画后上周汇报里的那个数字怎么解释，谁来写这段说明——这些不写进处理清单，下一次事故还会原样发生。
然后是把这次的排查动作固化成监控，而不是写进复盘文档就结束。我通常加四类检查：核心表行数与前 N 日波动阈值、主键唯一性与空值率、上游分区就绪才允许下游启动、以及关键指标与独立信源的日级对账。监控的告警门槛宁可松一点也别太紧，天天误报的告警等于没有告警。
还有一件事常被漏掉：口径变更要留痕。如果这次跌是因为有人改了关联逻辑，那么除了修数据，还得在指标变更日志上补一行，明确从哪天起可比、哪天起不可比。否则三个月后有人拉出这段曲线，会再排查一遍完全相同的问题。
面试里我给分的标准很朴素：能说出「先查链路再看业务」是及格；能给出三层切分和对账信源是合格；能主动谈到补数后的下游回刷、历史解释和监控固化，基本可以确定他处理过真实事故。反过来，一上来就报五条业务假设、并且每条都无法被一条数据证伪的，我会在心里减不少分。
所以这道题我的第一句话始终是：先别解释，把订单库的行数拉出来对一遍。
评论