——这是我的第63篇原创文章——

用户：”为什么我昨天录入的信息今天变了？你们系统有bug！“

客服：”你们自己改了吧？系统不会自动变内容的。“

用户：”我问了，没有人动过，就是你们系统有问题。“

……

客服最后来找产品经理：”能不能让开发查下系统日志啊？到底他们改的还是我们系统有问题。“

B端系统中，操作日志不可少 

上面的情况我们都遇到过吧，一般来说，没有bug的情况下，系统怎么会发生数据错乱？作为产品人的自信，肯定是不会承认的，而员工可能为了躲避追责，也不承认改过，那么，老板更愿意相信谁？

相信证据吧。口说无凭，我们需要实实在在的证据，而系统就是证据的提供者。但我们也常常发现，不是所有的修改都能在数据库中找到痕迹，没有提前埋下伏笔的话，有的问题开发都追查不到。

与其经常麻烦开发查，何不把操作日志做成一个功能开放给用户呢？老板发现有问题了，直接看日志来追责。双方都轻松。

但操作日志是个平常感知度很低，关键时刻又异常重要的功能，很多系统在前期赶功能时都不会做，但当用户量多了互相扯皮的事就多了。磨刀不误砍柴工，建议在系统功能基本完善后，用户数量多起来前，把操作日志排上日程。

 哪些地方需要操作日志？

操作日志记录的点是要一个个去开发的，所以挑重点即可，不要面面俱到。主要在这3个地方设置记录点：

重要功能

这要根据用户的业务场景来评估，哪些内容发生变更可能会影响他们的经营和内部管理，也可以从用户内部的绩效考核维度来考量。

比如说员工把商品价格修改错了，导致低价抢购遭到损失，那么商品修改的日志要记录下来；医生看诊完成后，再次修改病历，为了避免医患纠纷，病历修改的日志要记录下来。

像店铺基本信息，打印样式等一些不重要的基础设置修改，就不用记录，发现有问题改回来即可，不会造成损失，或者说损失很小，可以接受。

敏感信息

敏感信息包括**、供应商资料、统计报表、系统账号管理等。按理来说，员工不负责相关事务没有权限即可，但为了防止有权限的员工篡改和泄露信息，可以做个日志记录。

比如员工离职前，是否把**导出了；内部的资金往来情况，是否打印下来了。这些都可能导致内部资料的流失，造成损失。而系统的记录，能方便老板追查。

多人协作

B端用户最大的特点就是角色多，并且同一角色的员工人数多。这就导致：

1、不同角色之间可能有上下流关系，任一环节出错了都可能导致任务失败，必须监察好每个环节，比如审核和反审核。

2、同一角色的多个员工都有操作权限，操作混乱，容易引起纠纷，必须责任到人。比如前台都可以查看客户的预约信息， 那谁修改了预约的时间和内容呢？

这时候，操作日志责任到人的能力就发挥的很好了，不冤枉好人，不放过过错，也不要把锅甩给系统。

 有哪些类型的操作日志？

根据上面需要操作日志的地方来看，主要的日志类型和应用如下：

 这8种类型里面，查询其实用到的不是很多，除非对信息的敏感度有比较高的要求，其他的类型都是很常用的。大家在设计操作日志的时候，可以从这些维度去考虑。

如何定义操作类型显示字段？ 

明确了操作日志的类型后，接下来就是最后一步工作了，展示给用户哪些字段呢？

我们来看个很典型的操作日志案例：

 主要字段就是这几个： 

除了日志内容外，其他的字段问题都不大，日志内容到底写些什么，还是要说道一下的。

我们当然希望把每一次变动都详细地记录下来，但不是每次都能如愿的，特别是当内容很多的时候。所以，我们记录的重点是放在一次操作行为上，如果有问题，可以根据这次操作行为去辅助责任到人，排查问题。

给一些日志内容做参考，可以看到，这里面字段内容不多的话，可以把修改前后的内容都显示出来，如果涉及的内容比较多，到内容名称即可，比如说导出了xx报表。

  总结  

操作日志是一个经常被忽视，但在关键时刻不被甩锅的好功能，一定要排上日程啊。

操作日志的设计不复杂，明确好下面3点即可：

1、操作日志记录点，一般设置在重要功能、敏感信息和多人协作处。

2、可以从8类常用的操作类型角度去考虑，其他的操作类型基本不用考虑。

3、最后就是定义显示字段了，尽可能的细致，但重点还在记录行为上。

怕用到的时候忘了，先收藏起来吧~

总价值¥2438的星球福利包，现在只要¥158即可加入

最后附上星球大额优惠券