相等的两个数

今年夏天，我在搭一套数据采集：每天把几个平台上的数据自动取回来，存进一个只读的库，给上面的分析用。

起点是一条 RPA 流程：机器人点开页面，等它加载，再把表格导出来。它慢，容易坏，只能在配置好的那台机器上跑，出了错也很难看出是哪一步。我把它改写成 Python，取数不再打开浏览器，而是直接发页面背后的请求。浏览器只在登录和第一次摸清接口时用到，这两件事都不在每天运行的路径上。

真正花时间的不是写请求，而是核对。

有一段时间，只要采回来的数和平台页面上的对得上，我就放心了。后来才知道这样不对：两个字段可以在某一天恰好相等，口径却完全不同。现在的规则是：数据只能说明“今天这两个数相等”，说明不了口径。口径要到两个地方去找：一是请求里写明的指标、维度和分组参数，二是平台原始响应的字段结构。结论只能建立在这两处上，不能从数值相等倒推回去。

后来又补了两种核对。一种是拿平台自己导出的报表逐列对比，由此查出三处“不报错的错”：程序照常运行，数字看起来也合理，可就是错的。另一种是拿着截图回到页面上一条条复核，查出了两个真实的问题：限流时返回的空结果，被当成了“当天没有数据”；一类数据被归进了错误的入口。

然后是登录。平台会把频繁登录当成异常，确实因此触发过一次风控。现在每天先检查登录状态还在不在，失效了才重新登录。

最后是交付。一个平台一条线，一条线一个目录；这个目录要能打包发给别人，对方解压就能在自己的机器上跑。判断标准只有一句：目录里没有任何文件，依赖目录外面的东西。为了守住这一句，我写了一组专门检查目录结构的测试，又加了一道发包前的自检：真的解压到别处，真的新建一个空的虚拟环境，真的在里面完整跑一遍。在自己的开发机上跑通，证明不了在别人那里也能跑。

这些事都很琐碎。可是用这些数字的人，要拿它们做环比、做异动监测；底层一个口径错了，上面的每一张图表都跟着错，而且哪里都不会报错。