业务系统里的操作留痕，平时看不出价值，遇到审计、纠纷或者数据异常时就成了唯一的依据。留痕做得全不全，那时候才发现差别。
这里说的留痕跟前面的日志有重叠，但重点不同，留痕面向的是审计和追溯场景。
一、哪些操作要留痕
数据的增删改是核心，都要记。特别是删除和修改，比新增更需要留痕，因为新增的数据从结果上能看出来，删除和修改则看不出发生过什么。
状态变更要记。单据从待审变成已审、从正常变成作废，这类状态变化的每一次都要有记录，包括谁改的、什么时间、什么原因。
权限和配置的变更也要记。谁给谁加了权限、谁改了系统的某项配置。这类操作不产生业务数据，但影响范围大。
查询和导出这类只读操作，一般不全部记录，但涉及敏感数据的查询和批量导出建议记录。这类记录能发现异常的访问行为。
二、每条记录要包含什么
人、时间、动作、对象、结果，这五项是基础。人要有账号和姓名，时间精确到秒，动作要具体到业务动作而不是技术动作，对象要能定位到具体哪条数据。
修改类的操作要记改动前后的值。只记改成什么，事后无法还原。存储时可以限制字段长度，只保留前若干字符，兼顾体积和可用性。
还要记来源。操作是从哪个终端、哪个网络地址发起的。出现异常操作时，来源信息有助于判断。
如果操作是在某个流程的上下文中发生的，记下流程标识。比如这条修改是在哪次审批过程中做的，关联起来查更方便。
三、怎么应对审计
审计人员通常会问几个问题。某项数据在某个时间点是什么状态，是谁改的，为什么改，改之前的依据是什么。留痕功能要能回答这几个问题。
查询界面要按业务场景设计。按单据查、按人查、按时间段查、按操作类型查，这几种是最常用的。查询条件要能组合，结果能导出。
记录要能倒推。给定当前的数据，能往回看到它的变化过程。这需要每次变化都留一份，而不是只留最后状态。
保存期限要按规定来。不同行业对操作记录的保存时间要求不同，做系统之前先查清楚适用哪一条，据此设置保留策略和存储方案。存得太短不合规，存得太长占空间，都要有依据。
四、留痕本身的权限
记录生成之后不能被随意删除。系统里要分开看日志和删日志这两种权限，普通管理员只能看，不能删。
删除日志这个操作本身也要被记录，而且这条记录不能再被删除。否则只要先删记录再删日志，就什么都不剩了。
日志的存储建议跟业务数据分开。放在同一个库里，业务数据出问题时日志可能一起受损。分开存放还能防止通过业务系统的手段修改日志。
最后一点，日志的查询要有界面。如果只有技术人员能通过数据库查看，业务部门遇到需要核实的情况就得排队等，实际使用率很低。查询界面做出来，这项功能才算真正用得上。