数据跨系统搬运
🏦 场景与客户
一家零售企业，前端商城、订单中台、财务系统、CRM 各管一段。问题是系统之间没有接口——老系统供应商不开放，新系统又不想为几条数据专门开发对接。于是员工每天手工搬运：从商城后台导出订单，整理格式，再导入财务；客户信息在 CRM 更新后，靠人复制到中台。搬错一次，后面一整天都在找差异。
客户要的是让数据在系统之间自己走，而且走丢了要能立刻知道。
📅 实施节奏
- 第 1–2 周：梳理搬运清单——从哪个系统到哪个系统、哪些字段、多长频率、出错了谁负责
- 第 3–4 周：挑一条最简单的链路做试点，跑通再铺开
- 第 5–6 周：加监控与对账，把「搬了多少条、失败几条」变成每日可见
- 第 7 周起：逐条替换人工搬运，每替换一条停掉一个人工动作
🗝️ 方案要点
- 能推接口就不要用界面操作：接口稳定、可测试；界面自动化是兜底手段，不是首选，它对页面改版极其敏感
- 每条链路必须对账：搬运条数与失败条数每日比对，数字对不上就告警。没有对账的自动化等于埋雷
- 幂等设计：同一条数据重复执行不会产生重复记录，这是重试机制能用的前提
- 失败可重试，也可人工补录：自动重试若干次仍失败就落进待处理清单，给人一个补录入口
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 搬运方式 | 优先接口，其次数据库直连，最后界面操作 | 越靠前越稳定；但接口要对方配合，直连有耦合风险，界面操作最脆弱 |
| 触发方式 | 定时批量 | 实现简单、对源系统友好；数据有延迟，做不到实时同步 |
| 失败处理 | 自动重试若干次后转人工 | 省心且不会无限重试；需要防止重试风暴，得加退避与上限 |
| 数据校验 | 关键字段全量比对，明细抽样 | 成本与覆盖率平衡；抽样存在漏网可能，关键链路不适用 |
🚧 实施难点与排查
- 源系统界面改版：按钮位置一变，界面自动化脚本就失效，而且往往静默失败。加执行结果校验，脚本跑完没拿到预期数据就告警
- 并发冲突：两边同时修改同一条记录，后写的覆盖先写的。引入更新时间戳比对，冲突的进人工处理
- 编码与时区：中文乱码、日期跨零点错位。统一使用同一编码与时区，接入前做一轮数据体检
- 失败没人发现：早期搬运失败到月底对账才暴露。改为每日对账并推送结果，当天问题当天处理
💵 成本与收益
- 成本：链路建设与监控约 2 人 × 6 周；界面操作类链路后续需持续维护
- 收益：每天手工搬运的工时释放，数据从产生到可用的间隔大幅缩短
- 隐性收益：对账机制建立后，跨系统数据差异从「月底才发现」变成「当天就知道」
🛡️ 风险与保障
- 错误数据扩散：搬运出错可能影响下游决策。设校验规则与回滚机制，异常批次可撤销
- 权限最小化：搬运账号只授予必要的读写范围，凭据集中管理
- 操作留痕：每次搬运记录时间、条数、结果，便于事后追溯
- 依赖治理：把临时性的界面操作标记为技术债，制定逐步换成接口的计划
♾️ 可复用与演进
- 监控与对账框架可复用到所有数据链路，新链路接入即自带告警
- 后续把界面操作类链路逐条换成接口，长期降低维护成本
- 再进一步做数据血缘梳理，看清一条数据从产生到消费经过了哪些系统
