一台智能密集架每天要回答的问题，多数不是"架子能不能打开"，而是"这一列是谁在什么时间因为什么打开的"。权限分级与操作日志审计，是我们在软件侧花时间较多的两个模块，因为它们直接决定库房能不能把责任说清楚。

权限分级的思路通常按三层来切：身份层、动作层、数据层。身份层决定能不能进门和能不能登录，动作层决定能不能开架、能不能改参数、能不能导出清单，数据层决定能看到哪些库、哪些年度、哪些密级的目录。三层交叉之后，一个查档人员可以打开指定的列，但看不到库存总数；一名库房管理员可以改温湿度阈值，但不能改用户权限。行业里有人把权限做成"管理员"和"操作员"两档，用起来会很快撞墙，因为实际岗位远不止两档。

操作日志的粒度更值得较真。一条完整的开架记录，我们倾向于留下八类字段：账号与姓名、终端标识、开架列号、动作类型、触发时间、持续时间、关联检索词、结果状态。看起来啰嗦，缺哪一项都会在事后解释时卡住。

举个具体的例子。10 月 8 日假期复工首日，一位同事发现第 7 列的层板位置和节前记录不一致。如果日志里只有"第 7 列 10 月 3 日 14 时 22 分开架"，没人能回答是巡检、维修还是借阅。如果有动作类型和关联任务号，翻一下就清楚。这里我要说明，我们服务的项目中不少单位节前都会安排一次巡检，巡检记录和借阅记录混在一条流水里，是常见的工程问题。

另一个容易被忽略的是日志写入方式。日志如果写在密集架本地控制器里，断电、换板、设备返厂维修都会带走一部分记录；如果写在库房本地服务器，服务器重装又是一次风险；写到上级平台才相对稳妥，但网络中断期间要有本地缓存和补传机制。我们踩过的坑是本地缓存只有 2000 条，有一次网络故障持续了三天，第四天接通之后只补上去一部分，中间一段成了空白。

关于留痕年限，行业里并没有统一答案。有人主张跟档案保管期限走，有人主张统一至少三年。我们的做法是在技术协议里写明保留周期和导出方式，并把导出文件做成不可编辑的归档格式，同时保留原始数据库备份。具体条款建议读者查阅官方原文核实，不要用我们的说法当作依据。

还有人问日志会不会拖慢系统。实测下来，日志写入本身对开架动作的影响很小，真正吃资源的是启用全字段检索之后的历史数据查询。折中做法是把近三个月的日志放在热存储，更早的按月归档，界面只提供按时间和列号检索。

权限与日志这两件事都不显眼，设备验收时也很难打分，但真正出事的时候，能拿出来的就是这几行记录。所以我们的建议是：技术文件里别只写"具备操作日志功能"，把字段清单和保留周期写进去，验收时才有东西可查。