取数任务连挂三天，我们是第四天才知道的

那周三凌晨两点开始取数任务连着失败，我们团队第四天上午才知道。中间隔了整整三天，那三天里的所有报表、看板、复盘材料，数字全部是错的。

凌晨失败三次，任务状态是绿的

失败的是当晚跑批的一个环节，凌晨两点、三点、四点各试一次都没成。之所以没人知道，是因为这个任务失败后不抛错，它把结果写成空表继续往下走，下游照常读，读出一片 0。

任务面板上那四行状态全是绿的，绿得让人放心。

上午的三个人

周三上午把三个人凑在一起查。方向一开始是数据源，查了半小时发现数据源没问题；再查字段结构，也没有变更；最后才想到看那条空的中间表。

这一步的关键动作是一个人对着前三天的表做了一次差分，看哪一天开始对不上。差分表摆出来之后方向就明确了：不是今天坏的，是凌晨坏的，只是今天才有人来看。

停工一周，留下一条规则

四十八小时手工对数

确认原因之后是手工补数。两个人从后台按天导数据，第三个核对，核到上周口径。这活本身不难，难在量大且不能错——错一个数字，所有引用它的材料都要跟着返工。

第三天补历史数据的时候又发现一处口径错。补的那段用了一版新算法，旧数据得按老算法重算，又半天。

整个过程花了五天。

运营拿到的是什么

运营那边拿到的是一份中断过的数据，中间有三天是手工补的，还有半天口径是错的，而他们并不知道这段区别。

这才是最麻烦的地方。数据出问题，团队内部知道哪儿错了，可以改；已经发出去的表格带着一段错数据进了会议，凭什么让所有人回头去查哪一段是补的、哪一段是老口径。这一步没人做，因为做起来要重新对一遍每一页。

一周的停工换来的只有一条规则

复盘会开了两个小时。加的东西只有一条：核心取数任务失败时推消息。

会上有人问，一周的时间就换一条规则，值不值。这个问题问对了一半。一周的时间本来就换不回什么，它真正的价值在于暴露了三个我们此前不知道的环节：任务失败不抛错、空表往下走、差分没有人定期做。

真正该加的是第三条。差分这件事应该每天自动跑，核心表与昨天对比，行数突变和关键字段全空两个信号触发。这条是那一周里唯一算得上资产的东西，我们当周就上了，第二个月真的用它抓到过一次改口径的漏。

停工一周不亏的条件只有一个：这周发现的东西要留下来，而且要变成别人不问你也会做的事。