先说结论：WCS 的数据留存就三句话。第一，原始秒级数据留 30～90 天，分钟级聚合留 1 年，日报和关键事件永久保存。第二，存的地方分三级：工控机本地只放热数据，边缘服务器做聚合和一年期存放，云端只做冷归档。第三，报警记录和操作审计单独拎出来，按法规和客户合同要求的年限留，跟设备日志不是一个留存策略。下面讲为什么这么定，以及上线前怎么一步一步落地。
WCS 数据留存为什么这么分：先问谁会来查这份数据
查 WCS 数据的只有三类人。第一类是事故追溯：设备撞了、货损了、停线了，要还原"当时到底发生了什么"，这种要原始秒级数据，聚合数据还原不了现场。第二类是 OEE 和效率分析：算设备综合效率、分析停机原因分布，这种要聚合数据，没人会对着秒级点位算月度 OEE，那是自虐。第三类是审计和合规：要的是"谁在什么时候确认了这条报警""谁改了哪个参数"，操作记录，一条都不能少。
留存策略就是按这三类人的需求倒推出来的。想清楚谁查、查什么精度、查多久之前的数据，矩阵自己就画出来了。反过来，凡是跟你说"全存下来，以后总有用"的，基本都是没做过运维的人——数据没人查，等于没存。
反常识的判断先扔出来：最该永久保存的不是设备日志，是配置变更记录和报警确认记录。设备日志回答"发生了什么"，配置变更回答"为什么会发生"。我做过的事故复盘，九成最终都落在"谁改了哪个参数"上。这个坑我见过三次：数据全在，就是找不到当初是谁把光电传感器的延时从 200ms 改成了 800ms，复盘会开成甩锅大会。
再算一笔账，公式给你，自己套自己仓的数：
日增量 ≈ 点位数 × 86400（每天的秒数）× 单条字节数
举例测算：2000 个点位、1 秒采样、每条 50 字节，一天约 8.6GB，90 天约 780GB。这就是为什么原始数据不能永久留：不是存不起，是没人查，留着就是给 SSD 上坟。780GB 的热数据躺在工控机本地盘里，查询慢、备份难，迟早有一天把它写满——下面翻车点第一个就是这个。
WCS 数据留存分步做法：上线前把这五件事做了
-
盘点数据类型。WCS 的数据就五类，一类一行，建表，别漏：PLC 点位日志、报警记录、任务轨迹、操作审计、配置/程序变更。盘点的时候把每类的数据源也写上（哪个 PLC、哪个服务写的），以后查问题先看表，不抓瞎。
-
画数据留存矩阵。照着下面这个格式画，数字按自己仓的实际情况填：
| 数据类型 | 原始精度 | 原始留存 | 聚合方式 | 聚合留存 | 存哪 | | PLC 点位日志 | 秒级 | 30～90 天 | 分钟级均值/极值 | 1 年 | 本地→边缘服务器 | | 报警记录 | 事件级 | 按法规/合同年限 | 日报 | 永久 | 边缘服务器→云端 | | 任务轨迹 | 单任务 | 90 天 | 日汇总 | 1 年 | 边缘服务器 | | 操作审计 | 事件级 | 永久（只追加不删） | — | — | 边缘服务器→云端 | | 配置/程序变更 | 版本级 | 永久 | — | — | 边缘服务器→云端 |
注意两点：报警记录的原始留存不写固定天数，写"按法规/合同年限"，因为不同行业、不同客户合同要求不一样，写死了以后改合同就被动；操作审计和配置变更永久保存但数据量极小，放心存，这就是前面说的"最该永久保存的东西"。
- 定存储分级。工控机本地 SSD 只放 7～30 天热数据，保证断网也能查；边缘服务器放聚合数据和一年期；云端只做冷归档。记住一条：热数据别放云上，云厂商的流出和查询费用会教你做人。拿不准就先按公式算一笔日增量，再对比边缘服务器的一次性投入，账算完再决定，别凭感觉。
这里多说一句冷归档的隐性成本：取回。云端冷归档便宜，但取回要等几小时到一天，紧急事故追溯的时候等不起。所以"永久保存"不等于"随时在线"。定策略时，先跟审计方和客户确认取回时效要求：能接受 T+1 取回的进冷归档，等不起的放边缘服务器。这个取舍上线前就要定，事后迁移归档数据的工程量，比你想象的大得多。
-
清理和归档自动化。定时任务加磁盘水位告警：用到 80% 就告警，90% 自动归档最老的数据。水位告警要发到有人看的地方——钉钉群、值班手机都行，别发到没人看的公共邮箱。归档任务每次跑完要写日志，归档了多少、删了多少，对得上账。
-
交接文档。给运维三份东西，缺一不可：留存矩阵（相关方签字版，签字意味着"这个策略是大家认过的"）；清理/归档任务清单（含跑批时间、负责人、失败时的处理步骤）；一次归档恢复演练记录（证明归档的数据真能读回来，演练没做过，归档就是写给自己看的）。
常见翻车点：这四个我都见过
第一个，上线时根本没定留存策略。2024 年 10 月，华东某电商大仓，双十一前两周，WCS 工控机本地盘被日志写满，系统卡死。救法：停机 4 小时，紧急导出归档，加定时清理，补水位告警。这个坑我见过三次，一次比一次贵——第一次是测试环境，第二次是淡季，第三次差点赶上大促。这个教训就一句话：留存策略是上线 checklist 里的一项，不是运维"以后再说"的事。
第二个，聚合口径写死，原始数据删了。某仓按 90 天删了秒级数据，半年后管理层想换 OEE 口径，发现原料已经没了，只能从当时聚合好的数据里反推，反推出来全是错的。教训：删原始数据之前，先确认聚合口径冻结；拿不准就把原始留存放宽到 180 天，存储成本多一倍，买的是后悔药，这药不贵。（这药值多少钱？问问你们上次为了凑 OEE 口径加班到半夜的分析师。）
第三个，报警记录和操作日志混在一起。某 3PL 的报警记录只留 30 天，4 个月后客户索赔货损，要当时的报警记录和任务轨迹——拿不出来，最终按客户主张赔了一笔冤枉钱。报警记录的留存年限，一定要在签客户合同之前定好，写进合同附件，事后补救的成本是事前规划的十倍。
第四个，清理任务没人看。水位告警发到三年前离职员工的邮箱，磁盘满了才发现，归档任务报错三个月没人理。交接清单里必须写清楚：告警接收人是谁，离职时谁接，接的人要在清单上签字。很土，但是管用。
上线前夜 checklist，最后再加三行：数据留存矩阵相关方签字确认；清理任务手动跑一遍，看日志确认归档和删除都正常；做一次归档恢复演练，随机抽一份三个月前的归档读回来。这三行做完，你才敢说数据这事闭环了。没做的，现在就去补。
作者：林晓｜WMS 实施顾问
