有一段时间，我们的仓库数据看起来很健康：每个商品都有库位，每个库位都存在于系统中。数字彼此一致，也没有任何环节报错。
那些库位是占位的。
"仅仅一致"的数字有什么问题
占位库位很容易生成，也很容易被信任。它们符合字段结构，能通过校验，还能生成图表。问题只有在需要有人真的去把货拿起来时才会暴露，或者当两个不同的人用两种方式描述同一个货架、而系统坚持认为它们是两个不同位置时才会暴露。
这就是陷阱所在：占位数据看起来并不像缺失数据，它看起来就是数据。
用真实库位替换占位集合
我们按照仓库实际运作的方式重建了仓库主数据，然后把它作为权威库位集合加载进系统。
- 经验证的库位
- 1,306
- 建模的仓库
- 苏州、深圳
- 方法
- 先有物理位置，再有系统记录
- 占位库位
- 直接废弃，而不是修补
- 未知映射
- 在确认真实库位之前保持未知
数量不是重点。重点是这 1,306 个库位中的每一个，都对应着一个真人可以走过去的位置；并且两个仓库遵循同一套规则建模，而不是各自延续本地的习惯。
这次变更暴露了什么
用真实数据替换占位数据，会把所有悄悄依赖过假数据的地方暴露出来：
- 只有占位库位、没有真实归属的商品，需要一个明确的决定，而不是一个默认值。
- 两个仓库中含义不同的历史编码，需要被解析清楚，而不是被合并。
- 任何假定"每个商品总在某处"的流程，都必须接受"我们还没有确认"是一个合法状态。
最后这一点对系统的改动最大，它也是这个日志下一篇的主题。
为什么我们要公开这件事
仓库主数据是电商运营里最不显眼的部分，也是几乎所有其他环节都依赖的少数部分之一。把它写成一篇构建记录，是在声明我们现在对自己的标准：库位是物理事实，一个凭空生成库位的系统，比一个承认自己不知道的系统更糟。
一个没有人能走过去的库位记录，不是库存数据，而是装饰。