2026-09-27

水务数据停更两天：从 119 到 128 个项目档案

环保水务数据采集踩坑记录

结论先说： 我的水务系统停更了两天，查下来是三个小问题叠在一起：云端任务晚跑了，服务器没等到；交易平台的加密连接握手失败；水务局列表的页码算错了一位。修完之后，项目档案从 119 个变成 128 个。停更只是表面，真正的问题是：这个系统一直没有把数据采全，而我不知道。

发现：日期不对

9 月 27 日是周日，上午复查网站，看到水务系统写着「数据截至 9 月 23 日，发布于 9 月 25 日 12:08」。系统设计是工作日每天更新，就算扣掉周末，周五那一版也该有了。

我正好在网站「关于我」里写了一句「持续更新的系统」。数据要是停了，这句话就是假的，所以先查数据。

我的系统分两段：采集和整理在云端按计划运行，生成一份新快照；网站服务器定时去拉最新快照。

云端计划每天 08:05 和 16:05 运行，但 9 月 25 日那天，任务实际在 12:07 和 21:24 才开始，定时平台被推迟了好几个小时。服务器只在工作日 8 点到 19 点半之间拉取，晚上 21 点多生成的那一版就这样错过了，线上一直停在中午那一版。

修法很简单：服务器改成工作日全天每小时拉一次。多拉几次成本很低，漏拉的代价是页面过期。

排查时发现，健康检查其实早就在报失败，只是写进了服务器日志。没有任何通知，我不去看就永远不会知道。

所以这次顺手接了邮件告警：采集、同步、健康检查任何一项失败都发邮件，同一个故障只发一封，恢复时再发一封。还踩了一个小坑：国内服务器连 Gmail 的发信服务器直接超时，最后改用国内邮箱发件，发到 Gmail 收件，测试通过。

既然在查，我让 AI 把最近的采集日志也过了一遍，结果发现了更要紧的东西：

北京市公共资源交易平台，多个页面连接失败。 报错是加密连接握手失败（TLS BAD_ECPOINT）。原因是服务器上较新的 OpenSSL 默认优先用一种椭圆曲线，这个网站不支持，握手就断了。修法是只对这一个网站指定它支持的曲线（prime256v1），证书校验照常保留。关掉证书校验也能「通」，但那是给自己埋雷。
水务局项目列表第 2 页返回 404。 水务局的翻页从 0 开始数，第 2 页的地址是 index_1.html；交易平台从 1 开始数，第 2 页是 index_2.html。采集脚本按同一套规则拼地址，水务局那边就一直差一位。现在按网站分别处理。

修完重跑，扫描 62 条，新发现 28 条线索，确认 11 个事件、涉及 10 个项目。项目档案从 119 个变成 128 个，数据日期更新到 9 月 26 日。

交易平台是这个系统最主要的数据源。换句话说，首页上那句「119 个可核验的项目档案」，一直是在漏采的状态下统计出来的。