早上九点，票种页上的价格已经变了，问谁谁都说没点过。后台翻出来的只有一串打开过的页面，几点几分谁进来过看得见，改了什么、从多少改成多少，一个字没有。这时候讨论谁的责任没意义，先要回答的是操作日志指不指得到人。票务系统里这类追问一年总会有几次，答案不该靠回忆拼出来。

日志记到页面，还是记到那一格

记录粗细差一层，结论就差一截。页面级的操作日志只证明有人来过，字段级的日志才说得清那一格从旧值变成新值。改动追溯要成立，原值、新值、操作人三样缺一不可，少一样就只能算“有人动过”。售票系统里最怕的不是没有日志，是日志写了一堆访问记录，看着挺满，真出事一条都用不上。

票务系统认工号，不认账号

账号可以共用，工号不会。一条变更只挂账号，两个人轮流值班时，问到最后往往是一句“这个号我们组都在用”。所以一条变更须带操作人工号，这不是形式，是把责任落点钉在具体的人身上。责任落点清楚了，复盘时不用把整个班组叫来对时间。工号一缺，改动追溯也跟着断在半路。共用的管理员账号该收就收，别让它成为所有人的挡箭牌。

批量导入最容易把日志冲乱。一次导几百条，逐条展开会写出几千行，翻起来比没有还慢；可要是不记，出了问题又说不清是哪一批带进来的。稳妥的做法是记批次号与条目数，附上导入文件名和操作人工号，一条批次记录顶住一整批。少了这层记录，改动追溯做到一半就会断，责任落点也跟着模糊。售票系统里一次导入几百条不稀奇，批次号要写在最前面。

一百八十天之后，谁来接这段空白

票务系统的日志留多久，是个容易被跳过的设定。价格、库存、权限三类变更须留字段级日志，日志保留不少于一百八十天。半年听着长，跨季度对账、节前排查都用得上；超过期限的部分该清就清，但清之前要有人确认没有未结的争议。导出权限也要收着，导给谁、导了哪一段，同样记一笔。这条线由运维管，系统管理员每月抽查一次。

验的办法是倒着走：挑一次已知的改动，拿时间和栏目名去操作日志里检索，看原值、新值、操作人三样能不能一次还原。缺一样，就说明记录还不够细；一月缺满三次，运维要把这批栏目列成关键配置清单，逐项补开字段级日志，历史那段另注一句不可追。清单列出来还得有人认领，不然补开的事会一直挂在那儿。售票系统里这类清单最好跟着栏目走，换人也不至于断。

差别要到事后才看得出来。一种只记谁在什么时候打开过页面，存储省，跑得也轻，代价是出了事只能看到有人来过、看不到改了什么，改动追溯做到一半就断。一种记到字段、带原值和新值，每条多占几十字节，三分钟能还原全过程。存储和还原本来就要各让一步，选哪头，看的是事后要不要认账。这套票务系统的操作日志，价值不在多，在能不能对上人。

有一类变更不逐条展开，就是批量导入引起的大批改动。这一批由运维在日志里记批次号与条目数，不再一格一格写，复核人签系统管理员，签完才算封存。批次的边界要写清，别把两次导入并成一条，日后回查时分不出先后。责任落点落在批次上，也落在签字的人身上。