一套助贷系统上线之后，日志往往是打开之后很少再翻的那一块。把日志打开容易，把它用起来难。很多系统一上来是「全都记」，真到了要查的时候，却筛不出想看的那几条。问题通常不在记没记，在于三类记录混在了一起。
下面按访问、变更、动作三类分开说，每一类记什么、为什么要单独分出来、各自怎么用。
一、访问类：谁在什么时间进来、看了哪一块
这一类记的是「来看」这个动作。要素不多：账号、时间、来源地址、打开的模块或记录标识。
它要回答的问题是「谁有可能接触过」。比如一份材料后来出现在不该出现的地方，需要回溯这段时间里有哪些账号打开过它，靠的就是这一类。
这类记录的量级比其余两类大得多。一个日常几十人使用的系统，访问记录一天几千条是常态。所以它不追求逐条看，追求的是能按人或按时间范围筛出来。
二、变更类：改了哪条、改动前后各是什么
这一类记的是「动手改」这个动作。条数比访问少，单条的信息量更大。
一条完整的变更记录包含五项：对象（改的是哪条）、字段（改的是哪个）、改动前的值、改动后的值、操作人。
容易缺的是中间那两项，尤其是改动前的值。只保留当前值，等于每次改动都把上一次的样子覆盖掉，事后能看到的只是终点。
这一类的用法是还原。有人对某条记录的当前状态有疑问时，靠它能把中间的变化顺序排出来：什么时候从甲变成乙、又什么时候变成丙。
三、动作类：导出、删除、批量替换这类高影响动作
这一类记的不是普通操作，是那些一旦发生、影响范围会往外扩的动作。常见的有：批量导出、批量修改、删除、跨范围调取，以及团队权限管控里的权限变更。
它和第二类的区别在量级。改一个字段影响一条记录，一次批量导出影响的是整批。所以这一类适合单独成链：一次动作一条记录，附上范围、条数、发起人，走审批的把审批人也挂上。
数据导出权限管控，指的就是这一栏——一次带走多少、由谁发起。这类问题，另外两类记录答不上来。
四、三类为什么要分开
不分开会有两个麻烦。
一是筛不动。访问记录的量级远高于其余两类，三类压在一张表里，想找一次导出得在几万条里翻。
二是看不出重点。变更和动作是查问题的入口，访问是划排查范围的入口，用途不一样，检索方式也不一样。
分开之后，三类各自有一套检索口径：访问类按人和时间，变更类按对象和字段，动作类按动作类型和范围。同一套系统里，这三种口径都要能走通。
五、留存与轮转要考虑的两件事
日志会一直长。运行中的那一份通常按体积轮转，写满就换，旧的自然被顶掉。所以有两件事要提前定。
留存周期。三类不必用同一个周期。访问类量大、主要用于划范围，周期可以短一些；变更类和动作类要支撑回溯，周期通常需要放长。
归档位置。轮转下来的日志存在哪，和备份副本是不是分开存。如果日志和主库共用一套存储，主库出问题的时候，两边会一起丢。这套环境若是独立部署在自己机器上，归档目录与运行目录分开设会更稳妥。
落到这套系统里，鲲极（鲲鹏的鲲）的处理是：三类记录各按自己的保留口径设，不共用一个轮转策略，归档位置也与运行目录分开。
六、做到什么程度算够
一个可用的口径是：三类记录各自都能按人、按时间、按对象三种方式查一次。
- 按人查——某个账号在某个时间段做过什么；
- 按时间查——某一天发生过哪些动作；
- 按对象查——某条记录从头到尾被动过几次、每次是谁。
三种都能查到，日志才算真的用得上。只能按一种方式查，等于只用了三分之一。这个口径容易核，把三种方式各走一遍，就有结果。
七、答不上来的地方
有几件事日志本身回答不了，值得先讲清楚。
跨系统的动作对不齐。日志只覆盖这套系统内部的操作。同一件事若跨了两个系统，比如工单流转在一处、实际操作在另一处，两边的时间戳与账号口径不同，只能靠人工把两边对上。
「看过」不等于「看懂了」。日志能证明某个账号打开过某条记录，但说明不了他从中读到了什么。
系统之外的痕迹补不回来。电话沟通、线下谈、纸质材料，这些不在日志覆盖范围内，需要业务侧自己另做一份记录。
把这几处先说清，比事后解释缺的是哪一段更有用。
