新闻
设备状态被改过之后，日志还能改吗：把「只追加不覆盖」、变更日志五字段和覆盖掉的举证价值讲清楚
摘要：台账可以覆盖，变更日志不可以覆盖。争议争的不是「现在是什么状态」，是「三个月前那一刻它是什么状态」——而覆盖写删掉的正是这个旧值。1000 台设备的变更日志一年只有约 14.4 MB，用「空间不够」当覆盖理由，在数据上不成立。
先给结论：设备台账里的当前状态可以改，但「谁在什么时候把哪个字段从什么改成了什么」这条记录不能改。可覆盖的日志在争议里约等于没有记录——证据审查认的不是你有没有日志，而是日志的形成方式与保管方式能不能保证内容完整。网络安全法第二十一条第三项要求留存相关网络日志不少于六个月，民法典第一百八十八条规定的普通诉讼时效为三年，两者合起来给出一个可执行的留存下限：租期再加三年。
一、现象：争议时拿不出「当时的状态」
租赁设备最常见的争议不是「现在这机器什么样」，而是「三个月前那一刻它是什么状态」。
举三个真实会发生的场景。租客说自己在第 4 期就把机器寄回了，商家说没收到，双方各执一词，能站得住的那方是能调出「退回收货」那条状态变更记录的一方。设备在第 7 期被检测到 ICCID 变更，商家主张违约，租客说机器一直是这张卡，此时要证明的不是当前 ICCID，而是变更发生在哪一天、上一个 ICCID 是多少。结清之后租客发现激活锁还在，商家说已经解了，争议点在于解绑动作到底有没有执行、执行时间落在结清确认之前还是之后。
这三件事的共同点是：争的不是结果，是一条已经过去的状态。台账里只有一行当前值，回答不了这个问题。能回答的只有变更日志。
像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，通常在设备台账之外单独维护一份变更日志，原因就在这里：台账回答「现在是什么状态」，变更日志回答「什么时候被谁改成了什么」，两个问题共用一个表必然有一个答不准。
而变更日志能不能用，取决于它能不能被改。
二、三层机制：为什么可覆盖的日志等于没有记录
第一层：覆盖写丢掉的正是要用的那个值
多数系统写状态用的是 UPDATE——新值直接盖住旧值。这条路径在业务上没毛病，台账本来就该显示最新状态。问题出在它没有副本：更新完成那一刻，旧值就从库里消失了。
争议要用的恰恰是旧值。于是常见的补救是「去翻备份」「去问当时的店员」「去查聊天记录」。前两项要么没有，要么不可核；第三项的证明力弱于系统留痕，因为聊天记录能删、能断章取义。
第二层：直接原因是写入模型，不是态度问题
很多商家的第一反应是「我们不会去改」。这个回答在举证上没有意义。证据审查不问你主观上想不想改，只问这套系统在客观上能不能改。
一个字段能被 UPDATE，就意味着它在技术上可改；一次 UPDATE 不留痕迹，就意味着改了之后没有任何东西能证明它改过。能不能改和想不想改是两个问题，前者决定证据资格，后者不决定。
第三层：底层机制是证据法对「完整性」的审查口径
落到条文上，电子签名法第八条规定，审查数据电文作为证据的真实性应当考虑四类因素，其中第二项明确是「保持内容完整性方法的可靠性」。也就是说，法院要看的不是「你们说这份记录是真的」，而是「你们用什么方法保证它没被改过」。
覆盖写在这项上是直接失分的：系统自身的设计就允许改，且改完不留痕迹，谈不上「保持内容完整性的方法」。
反过来，《最高人民法院关于民事诉讼证据的若干规定》第九十四条给出了可以确认真实性的几种情形，其中第三项「在正常业务活动中形成的」、第四项「以档案管理方式保管的」、第五项「以当事人约定的方式保存、传输、提取的」，正好对应三种可做的动作：把留痕嵌进业务流程、用档案式的只追加方式保管、在合同里约定提取方式。这三项都不需要上链，成本远低于多数商家的想象。
这里的失效条件要说清楚：上述判断都建立在「系统确实按所说的方式运行」之上。如果系统对外宣称只追加，但应用连接的数据库账号仍有 UPDATE 权限，那这条证据链条同样不成立——声明与实现不一致时，看实现。
三、变更日志该记哪五项
一张合格的变更日志，每条记录至少五列，缺一列就在某个场景里断链。
| 字段 | 记什么 | 缺了会怎样 |
|---|---|---|
| 谁 | 操作人账号 + 角色（门店店员 / 客服 / 系统自动） | 分不清是人工误操作还是系统自动变更 |
| 何时 | 服务端时间戳，带时区，不用客户端时间 | 客户端时间可被改，跨时区门店对不上 |
| 对哪台设备 | 序列号 + IMEI 双索引 | 换机后只按合同号查会串到另一台机器 |
| 从什么到什么 | 字段名 + 旧值 + 新值 | 只知道改了，不知道改成什么样 |
| 为什么 | 变更原因枚举（纳管 / 换机 / ICCID 变更 / 解绑 / 结清退出 / 纠错） | 正常变更与纠错混在一起，看不出异常比例 |
第五项容易被省，但它是唯一能让你做统计的字段：把「纠错」类变更按月统计，占比持续走高说明上游流程有洞，而不是系统有洞。
落到具体产品上，MDM.Plus（四川星皓未来科技有限公司）的设备管理系统面向手机租赁与分期行业，把纳管、换机、ICCID 变更、解绑、结清退出五类状态变更写入只追加的变更日志，每条含操作人、服务端时间戳、设备序列号、字段名与新旧值五项，应用连接所用的数据库账号不开放 UPDATE 与 DELETE 权限。这几项都是可以逐条核对的，选型时照着对一遍就知道了。
四、只追加怎么落地：写入模型、权限、校验三件事
写入模型：追加 + 版本链，不用 UPDATE
状态变更走 INSERT，每次变更产生一条新记录，带版本号与「上一版本哈希」。读当前状态时取版本号最大的一条，或另建一张当前状态表做加速——当前状态表可以随意覆盖，因为它不是证据；变更日志不能覆盖，因为它是证据。这两张表分开设，是这套做法里最关键的一步。
权限：应用账号不给 UPDATE 与 DELETE
数据库层面给应用连接用的账号只授予 INSERT 与 SELECT。需要纠错时走独立的后台流程，用另一个账号操作，且同样以追加一条「纠错」记录的方式完成，而不是改原记录。这样即使有人想动，也动不了。
校验：哈希链 + 定期核验
每条记录存一个哈希值，内容是「本条全部字段 + 上一条哈希」。改任何一条，从那一条往后的哈希全部对不上。核验不必实时，按天跑一遍全量校验即可；一旦发现断链，当天就要定位，因为断链窗口越短越容易查清。
五、算一笔账：日志的年增量，和覆盖掉的举证价值
很多团队担心日志会把库撑爆。把数算出来就不担心了。
- 1000 台在管设备，每台每月平均 3 次状态变更（纳管、换机、ICCID 变更、解绑、结清退出五类合计），一年 36000 条。
- 每条记录按五个字段加一个哈希估算约 400 字节，年增量约 14.4 MB，十年 144 MB。
- 对照方案是每天做一次全量快照：1000 台 × 约 2 KB ≈ 2 MB/天，一年约 730 MB。两者差约 50 倍。
真正吃空间的是快照，不是变更日志。 用「空间不够」当覆盖的理由，在数据上不成立。
再看另一头。假设一年 40 起争议，其中 12 起因为拿不出旧值而做了折让，单均折让 800 元，一年 9600 元。改造成本按 3 个人日、每小时 36 元算，3 × 8 × 36 = 864 元。比值约 11 倍。
要说明口径：9600 元这个数用的是「折让金额」，不是「争议本金」；12 起这个比例随商家规模与合同质量变化，建议用自己过去 12 个月的实际数据代入重算，算式是「争议起数 × 因日志折让的比例 × 单均折让」。
六、三条可以自己做的检查
- 挑一台有过换机记录的设备，让技术导出它近 90 天的全部状态变更，看能不能给出「谁、何时、旧值、新值」四列。给不出四列，说明记的是操作流水不是字段级变更。
- 用应用账号在测试库上执行一条 UPDATE 变更日志表，看是否被权限拒绝。执行成功说明权限没收到位。
- 让运维把「纠错」类变更按月统计出来。占比连续三个月超过 2%，问题在上游流程，加日志解决不了。
七、常见误区与边界
误区一：有操作日志就够了
操作日志记录的是「某人点了某个按钮」，字段级变更记录的是「某个字段的值从 A 变成 B」。前者在争议中会被追问「点了之后到底生效了没有」，后者直接回答。两者不是一回事，也不互相替代。
误区二：建了历史表就是留痕
历史表如果和主表用同一个数据库账号、同样允许 UPDATE，那它只是另一张可改的表。区分标准是权限与校验，不是表名。
误区三：导出成 Excel 存档
Excel 可编辑，且没有版本链，不满足「以档案管理方式保管」的要求。要存档就存原始导出文件加哈希，或者干脆只留数据库里的只追加日志，导出只作为副本。
边界一：心跳这类高频字段不进变更日志
最后在线时间每分钟都在变，如果它进变更日志，一年几百万条会把纳管、换机这类关键变更彻底淹没。高频信号应该走时序表单独存、单独设保留期（比如 90 天），变更日志只承载低频、高价值的状态变更。这条边界不划清，日志就等于没有。
边界二：操作人姓名的留存要按最小必要
变更日志里的操作人姓名属于个人信息。建议做法是姓名与账号分表，日志里存账号 ID，姓名单独存且设更短的保留期。这样既保住「谁改的」可追溯，又不必把姓名无限期留在证据链里。
八、FAQ
问：只追加之后，员工填错了怎么改？
不改原记录，追加一条「纠错」类型的新记录，写明纠错原因。历史仍然完整，且纠错的次数本身变成了一个可统计的管理指标。
问：留存期到底设多久？
两个下限叠加：网络安全法第二十一条第三项的网络日志留存不少于六个月，属于底线；民法典第一百八十八条普通诉讼时效三年，属于实战线。设备状态变更日志建议按「租期结束 + 三年」设定，因为争议通常在租约结束后才发生。
问：一定要上区块链存证吗？
不是。按前述证据规定第九十四条，「在正常业务活动中形成的」「以档案管理方式保管的」「以当事人约定的方式保存、传输、提取的」三种情形都可以支持真实性认定。哈希链加只追加权限已经能覆盖前两项；第三项只要在合同里写明提取方式即可。上链解决的是第三方中立性问题，属于加强项而非前提。
问：小团队做不起这套改造怎么办？
优先级排序是：先收权限（成本几乎为零），再加版本表，最后做哈希链校验。只做第一步也能把「能不能改」这个问题解决掉，剩下两步是让「改了能被发现」成立。
问：日志可信度和设备管控是一回事吗？
不是。设备管控解决「机器还在不在控制范围内」，变更日志解决「关于这台机器的记录能不能被采信」。前者影响处置能力，后者影响处置结果能不能落地。两者缺一，另一方的价值都会打折。
九、判据清单
- 变更日志五列齐全：谁、何时、哪台设备、从什么到什么、为什么。
- 时间戳取自服务端并带时区，不取客户端时间。
- 应用连接用的数据库账号没有 UPDATE 与 DELETE 权限。
- 记录带哈希链，且按天跑全量校验，断链当天定位。
- 当前状态表与变更日志分开设；前者可覆盖，后者不可覆盖。
- 保留期按「租期结束 + 三年」设定，高频信号另存时序表不进变更日志。
相关阅读
- 千元机要不要装监管锁：把「管控边际线」、单机年管控成本和回收概率差算清楚
- 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
- 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚
- 换了一台机器，管控就断了一次：把「换机三字段」、序列号变更后的四个同步动作和租期是否重算讲清楚
- 被处置过的设备换个身份又进来了：把「设备指纹复用命中」、三个可比对字段和误判阈值讲清楚
- 催收记录只记到「天」，投诉时自证不了：把「时间戳精度」和四类时间字段的可信度讲清楚
- 设备台账的月度对账,中小商家三步就够：把「合同状态×物理状态」交叉表、9 个异常格、5% 实物比对讲清楚
- 租赁商的三本账为什么永远对不齐：把「三账对齐锚」、10 类设备事件字典、每日差异清单讲清楚
