库能导入、任务能跑，只是全球号码数据库系统的上线日。真正决定三个月后还能不能用的，是规则改了有没有版本、新国家是加元数据还是再克隆一套库、错导入能不能撤。架构上为什么不要按国家拆库，见 全球号码数据库系统为什么不要按国家拆成多套库。
本文写上线之后每周实际会发生的事。
改规则只升版本，禁止在原地换一种键
地区元数据会更新：号长判断、trunk prefix、某个号段的归属。如果直接覆盖旧键：
- 半年前的任务无法解释
- 同一 raw 新旧键并存，去重率看起来下降
- 探针号对不上，没人敢再改规则
正确做法：新任务用 rule_vN，旧结果保留当时版本。需要统一口径时提供重算，而不是后台偷偷 parse 出另一种 key。格式规则本身见 全球号码去重系统开发，表字段见 号码数据库系统怎么设计。
新开一个国家：加元数据，不要新开一套系统
出海团队每进一个市场，最差的维护方式是再部署一套“越南库”。全球号码数据库系统上应只增加：
- 国家码、号长、前导 0 规则
- 该地区的探针号（通过 / 重复 / 异常各几个）
- 运营培训：任务默认地区怎么选
权限继续按角色和批次切，不要按国家物理拆库。拆开之后的合并成本，会高于现在多维护一份元数据。
每周对账：探针号比去重率更值钱
看“本周去重率 23%”几乎无法判断系统健康——渠道包质量波动很大。更稳的是固定探针：
- 成交客户号：必须打成历史重复
- 从未入库的干净号：必须通过
- 故意写错地区或破坏成科学计数法的号：必须异常
- 同一号的
+/00/ 本地写法：必须落到同一键
探针失败，先停大导入，再查是默认地区、规则版本还是某批脏数据。验收样本的思路见 号码数据去重软件怎么验收。
错批撤回是日常能力，不是事故通道
上线后一定会发生：
- 默认地区选成 CN，实际是泰国包
- 测试文件进了生产
- 同一哈希文件被连点两次
没有 batch_id 的库只能按时间删，容易误伤同一小时进来的其它包。维护手册里应写清：谁有权撤回、撤回后实体的 last_seen 怎么回滚、已经发出去的通过号怎么通知下游停用。
备份、导出和“库越来越大”分开处理
全球号码数据库系统会持续膨胀，这是正常的。维护时分开三件事：
- 备份：运维通道，不对业务账号开放整库下载
- 任务导出：当次通过 / 重复 / 异常，给运营
- 观察号 / 测试号：单独状态，默认不参与历史重复拦截
把空号检测结果、CRM 姓名合并硬塞进号码实体，unique 会乱。去重和清洗的边界见 号码去重和号码清洗的区别。
磁盘和查询变慢时，先看是不是对 raw 现场规范化、是不是导入堵住了查询，再谈分片。性能分层见 号码快速去重软件为什么慢 和 底层架构。
常见问题
规则升级后，要不要立刻重算全库？
先用探针和新任务验证新版本，再选批次重算。全库立刻重算会在窗口期内让结果口径混乱，也更难回滚。
历史重复率突然下降，是系统坏了吗？
常见原因是新包地区选错、规则版本不一致、或渠道改了号的写法而规范化没覆盖。先跑探针，再看该批次异常率。
维护期想对照任务和导出字段？
在线 Demo 看状态和结果列。按自己的全球底库做规则托管和扩地区，联系 Telegram @imchat。