异常数据排查 SOP：五步走完再定性，90 分钟不许拖

业务方甩来一句「这个数不对」，最常见的处理是：分析师打开表看一眼，说「我再查一下」，然后消失半天，回来给一个「可能是上游有点问题」。这种回答等于没回答，业务方下次还是不知道该信哪个数。

我们把排查写成五步，每步有产出物，90 分钟走不完就标「未定性」。规矩定下来之后，同样的问题第二次出现时，平均四十分钟能定性。

五步：一步一个产出物

上面是五步排查顺序，下面是查完之后的三种收口方式

第三步最费时间也最关键。有一回某个 ASIN 销量突然掉了三成，绕了四十分钟以为是跑批问题，最后回到源表一看，那批订单状态是「已发货未签收」，而报表按「已签收」统计。少一行源表核对，方向就全错。

第四步查变更是我加进去的。以前没这步，业务方一着急就默认是我们系统坏了，第一反应是找技术。三步排查做完，八成问题在变更清单里能对上。

三类收口：查完之后往哪走

第二类最容易处理错。业务变了不是数据错误。有一个月广告预算被砍一半，销售额跟着掉，值班分析师把报表调回上个月的数，说是修好了。那个月老板做决策用的全是假数，第二个月发现真实跌幅比报表还大。数据团队唯一该做的是把差异说清楚。

谁做、什么时候做、留什么记录

发现人写一句圈定描述发给数据值班，从接手起 90 分钟计时。每一步的产出物贴在同一张单子上，不另开文档。90 分钟走不完的，单子状态改成「未定性」，写明卡在哪一步、缺什么信息，由数据负责人决定升级还是挂起。

排查单留三样：圈定描述、每步产出物截图、定性结论和后续动作。定性为「报表侧问题」的另留一份改前改后对比。定性为「上游断供」的，把断供起止时间同步给所有用这张表的部门。

未定性也要说

业务方最恨的不是「查了四小时没查出来」，是没有下文。停在第三步和没人管，区别只在有没有人认领这件事。

什么时候必须停

四种情况直接停：数据源本身在平台侧发生大规模异常，等平台说明，不做内部排查；过去两小时刚改过口径或字段，变更未生效期内的数不对是正常现象，先等一个刷新周期；是大促期间，日波动幅度大到失去参考价值，不定性；同一个问题单已经出现过三次，说明不是数据问题而是口径问题，停下排查，把口径争议提到口径评审会。