最近在研究操作日志，将需求中部分共享部分内容单独抽离出来，将整个需求的调研、实现细节进行描述，供各位小伙伴了解和共同成长。
操作日志基本成为了B端产品的标配，其背后是企业管理层面的诉求，希望借助于操作日志更好的进行监管和促成协作，确保团队行动的一致性。C端产品较少出现操作日志，主要是因为其个人的操作并不会影响他人。虽然操作日志成为标配，但在一定程度上查看团队其他人的行为动作信息依然可能存在一定的法律风险，目前国内基本上没有明确的引导或告知。
概述
分类
日志记录了代码的执行过程。根据目的不同，可分为系统日志和操作日志。
系统日志
记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。开发人员可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。由于系统日志主要是为开发人员排查问题提供依据的，因此可读性没那么高。
系统级别日志，多针对开发同学
操作日志
记录所有用户在系统中的操作过程和操作结果，如登录记录、修改记录等。
操作日志主要是为用户服务，帮助他们查看历史操作记录，因此对可读性要求较高。
操作日志，多针对系统操作人员
内容组成要素
操作日志包含什么，其实和常见的需求分析差不多，遵循“5W1H”的原则基本就可以完成操作日志的梳理。操作日志本质上是记录“谁在什么时间、什么位置，对什么东西做了什么操作，从而产生了哪些变动”。所以，操作日志应包含以下信息：
- 操作人员：谁执行了该操作，一般是操作人账号信息
- 操作时间：什么时间执行了该操作
- 操作位置：在哪个模块上执行了该操作
- 操作对象：对哪个对象执行了该操作；一般为了好归类，还会额外增加操作对象的类型分类；
- 操作类型：具体执行了哪个操作，如登录、浏览、新增、删除等
- 变动情况：在执行该操作后产生了哪些变化，主要针对于“编辑”类型的操作
- 附属信息：有的系统中为了将操作场景描述的更信息，还会携带一些额外的信息；比如设备环境信息（设备操作系统、IP）、操作页面、业务字段（大多是复杂的改动项，支持跳转至具体功能点等）等
附属信息一般根据系统的复杂程度来处理，但上面的几项基本属于常见的操作日志内容范畴。
操作日志字段
通过内内容组成要素的分析，基本上可以确定操作日志的字段信息：
基础字段
操作人ID：必填；该部分需要关注业务中对操作人的辩识模块：List，一般是固定的，建议取系统的一级或二级菜单即可操作：List对象类型：List，必填；根据业务情况进行梳理，比如操作对象对象可能是 活动、群组、用户等对象：String，必填，一般指被操作的对象，如标签名称、分群名称等，取对象之后状态的数据时间戳
附属字段：
IP：操作者的IP信息对象之前状态：string，建议保留该数据，根据实现方式的不同可能不同，若是监听数据库变化建议保留数据库前后字段的数值json对象之后状态：string，同对象之前状态的描述租户ID：根据业务形态来灵活处理
上面是一些建议的字段，可以根据系统的情况进行灵活调整；不过依然需要对一些技术细节进行讨论或给予关注：
操作日志的存储：操作日志的数据存储是平台级别、租户级别还是什么级别，基于库、表还是逻辑隔离等，这些都需要产品同学和架构师来讨论确定，其影响最终字段的取值和后续展示。
操作人ID：根据具体业务的特点来设计，其本质上需要保证操作人的ID是唯一的是可完成最终“昵称”或“操作人账号”映射的。在一些多租户系统中，各个租户下的账号信息是隔离的，这个时候就要结合租户ID来完成操作人ID的隔离。
操作动作：在一个软件系统中，通常存在增删改查四类操作。对于日志系统而已，这四类操作的处理难度不同。查询操作往往不需要记录日志，增加和删除操作涉及一个对象状态，编辑操作涉及对象编辑前和编辑后的两个状态。
对象状态：编辑操作是整个日志模块中最难处理的，有时候变更的内容很复杂，也不太适用于页面呈现，这个时候一般建议保存前后的改动json信息（主要取决于技术实现方案）。同理，新增操作可以理解为null到新对象的编辑，删除操作可以理解为旧对象到null的编辑，查询操作可以理解为旧对象到旧对象的编辑。
对象：对象的取值需要结合业务，比如创建一个活动后这个对象的取值就是“活动标题”，这个时候难以强制性要求其取值是“对象之前状态”还是“对象之后状态”。“对象之前状态”在编辑后可能“活动标题”发生了变化，“对象之后状态”在删除后可能“活动标题”也出现了变更（按照上面对象状态中的抽象）。
约定日志Meta信息
第一步：梳理功能列表
为了保证操作日志的完整性，不会遗漏场景，一般建议按照系统的功能列表进行梳理。建议将粒度细化到系统的最小的功能列表。
该步骤既保证了不会遗留场景，同时也梳理了上方操作日志内容组成中的“操作位置”。
第二步：梳理操作列表
按照最终用户的操作路径，梳理用户的操作动作。
是不是所有行为都应该记录，一是取决于该动作是否很重要很敏感会影响到其他人的使用，二是取决于技术实现（对于通过监听数据库变更方式实现的情况下，有一些操作是无法产生日志的）
第三步：完成字段取值约定
根据上面的字段和业务情况来说明部分字段的取值逻辑
第四步：提升可读性
在第三步中大多存储的是各种ID等技术语言的信息，需要在最终产品实现中展示可读性比较好的业务信息。
比如将操作人ID映射为操作人昵称等。
下面给一个现有系统中实现的Meta信息列表截图：
可读性中的文案可通过固定文案或拼接文案方式来组成；图中将拼接文案方式也进行了说明。
操作日志的周边说明
存储方式和时长
由于操作日志可能较大，故在存储选型上请给予关注，建议与架构师或技术同学进行深入的沟通交流；常见存储在MySQL当然是可行的，但是如果数据量较大的时候可能要考虑采取一些其他的技术选型。
同时，在需求上也可做一些折中方案，比如要求操作日志保存时长有一个范围等。
操作日志的数据权限
上文背景中有过简短描述，操作日志有一些管理类的需求背景，所以一般需要在操作日志的设置中增加对数据权限的控制逻辑。
一般B端会要求部分账号可以查看其他账号的操作日志，该过程可能是角色和权限体系来处理，也可能是单独的控制逻辑方式来实现。