需要留存用户操作日志、交易链路日志、权限变更日志、系统异常日志和接口调用日志这五类，覆盖从用户触发到系统响应的完整证据链。少了任何一类，事后扯皮时你手里就缺一块拼图。
日志留存这件事,平时没人关心，出了事故才追悔莫及，业务方和开发battle、和客户对质、和监管解释，全靠日志说话，但很多团队留存日志比较随意，要么啥都记导致磁盘爆掉，要么该记的没记，下面按定责的实际需求拆解，说清楚到底留存哪些、留多久、怎么用。
定责需要留存哪几类业务日志
业务侧的定责通常围绕三个问题展开：用户做了什么、系统怎么响应的、谁在什么时间改了什么配置，围绕这三个问题，日志至少要覆盖下面五类。
用户操作行为日志
这是定责分析中最常被调用的日志,用户在前端页面的点击、输入、提交动作，都要有记录，尤其是涉及资金、合同、订单状态变更的关键节点，必须记录操作前后的数据快照。
以电商退款场景为例：用户申请退款→运营审核→财务打款，每个环节的操作人、操作时间、操作前后状态变化都该留痕，常见做法是在业务代码中增加操作记录埋点，写入独立的用户行为日志表。
这类日志的关键字段包括：用户ID、设备指纹（IP+UA）、操作类型、操作对象ID、操作前值、操作后值、时间戳，有了这些，才能回答“用户到底有没有点过这个按钮”这种灵魂拷问。
交易链路日志
一个业务请求往往经过网关、应用服务、数据库、第三方接口等多个节点，交易链路日志的价值在于串起整个调用链，还原请求的完整生命周期。
推荐使用TraceID贯穿全链路,用户在生成请求ID后，后续所有内部调用都携带这个ID，当用户投诉“我付了钱但订单没生成”时，运营只需拿着订单号去查链路日志，就能定位是哪个环节断了。
链路日志至少包含：入口请求参数、各节点处理耗时、出口响应参数、错误堆栈，在微服务架构下，还需要记录服务间的调用关系，Elastic Stack配合APM工具，是不少团队的标配方案。
权限与配置变更日志
这类日志很多人容易忽略,但定责时往往起决定性作用，谁修改了价格策略、谁调整了风控阈值、谁给某个账号提了权限，这些操作如果没记录，出了事根本找不到责任人。
权限日志需要记录：操作者账号、操作类型（新增/修改/删除）、变更前后配置内容、生效时间、审批单号，监管审计时，这类日志是合规审查的硬通货。
系统异常与告警日志
业务代码中catch到的异常、超时、熔断事件，都要写入独立的异常日志，特别是在分布式系统中，一个服务抖动可能引发雪崩，异常日志能帮你确定故障的源头服务。
建议在异常日志中记录：异常类型、发生节点、触发请求ID、上下文关键数据（注意脱敏）、重试次数，这些信息在复盘时会告诉你，到底是代码bug、外部依赖故障，还是数据问题。
第三方接口交互日志
现在的业务系统几乎都会调用外部服务,比如支付网关、短信服务商、地图API，这类日志的核心用途是厘清责任边界到底是咱们系统的问题，还是供应商的问题。
记录方式是在调用第三方接口的前后各打一条日志,包含请求参数、响应结果、耗时、错误码，定责时，拿着这些日志对准第三方，对方基本无法推诿。
业务日志留存多久才算合理
这个问题没有统一答案,但有个底线和一套参考维度，法律层面，《网络安全法》要求网络日志留存不少于六个月，这是最低线，满足合规的最低要求。
但从定责的实际情况出发,建议核心业务日志至少留存一年以上，原因很简单：很多纠纷和审计需求不会在事发当月就出现，尤其是涉及财务、合同纠纷的场景，客户可能在半年后才发起投诉。
不同级别日志的留存周期建议如下：
- 用户操作日志：至少12个月，涉及金融/医疗等强监管行业建议2年以上
- 交易链路日志：至少6个月，大促场景的链路日志建议保留到次年同期
- 权限变更日志：和员工在职周期挂钩，建议至少保留到员工离职后一年
- 系统异常日志：保留3-6个月即可，用于复盘近期故障
- 第三方交互日志：至少12个月，便于和供应商对账与追责
这里要提醒一点：日志留存周期不是越长越好，存储成本的曲线是陡增的，日均千万级请求的系统，一天的全量日志可能就有几百GB，合理做法是分级存储，热数据（近30天）用高性能存储，冷数据（半年以上）压缩后转存到廉价对象存储。
日志怎么用于事后定责分析
留存日志只是第一步,真正发挥价值是在事故发生后能把日志用起来，这里介绍一套标准的分析路径，从发现问题到确定责任方，逐层推进。
第一步：确认时间线
定责的第一件事,是把事件发生的时间线精确到秒，整理出完整时间线需要调取前端埋点日志、网关访问日志、应用错误日志三类，对照同一笔订单或同一个用户ID，拼接出从用户操作到报错发生的先后顺序，这一步能快速判断问题是出现在用户侧、业务代码侧还是基础设施侧，例如用户反馈“支付成功但页面未跳转”，时间线会告诉你支付回调其实到达了服务器，只是响应超时。
第二步：定位首个异常节点
有了时间线,顺着链路日志找第一个报错的节点，这里有个重要原则：第一个异常节点通常是问题的根源，后续的报错大多是连锁反应，比如数据库连接池耗尽，表现可能是接口超时、缓存击穿、消息堆积，但根源是数据库层的老大难问题。
第三步：比对操作记录和历史基线
系统异常未必是代码问题,也可能是最近一次变更导致的，调取权限与配置变更日志，看看异常发生前有没有发布新版本、调整过参数，行业内不少重大故障的根源都是配置变更，而非代码缺陷，所以这个比对步骤，定责时能一锤定音。
第四步：结合业务上下文补充证据
日志只能告诉你“发生了什么”，要判断“是谁的错”，还需结合业务上下文，比如一个订单超时关闭，链路日志显示是支付回调延迟，但业务规则是15分钟未支付自动关闭，此时就要看产品配置关闭时间参数是谁设置的？这就是业务侧定责与纯技术排查的本质区别：既要技术证据，也要业务判断依据。
日志留存实操中的几个常见坑
不少团队日志策略看着齐全,一到定责就发现用不上，多半是踩了以下这些坑。
时间不同步，服务器时钟不统一，各节点日志时间戳对不上，还原链路时错位严重，解决办法是在日志采集端统一使用NTP同步，时间戳统一用UTC+8，避免时区混乱。
关键参数没打出来，有些开发偷懒，日志只打“操作失败”四个字，没有记录当时的请求参数和响应内容，这样的日志对定责毫无价值，建议在代码评审时就约定，所有业务日志必须包含关键业务参数。
敏感数据未脱敏，日志里直接记录身份证号、银行卡号、密码明文，一旦日志泄露就是重大安全事件，反而变成企业自己的责任，日志采集前做好脱敏，比如手机号只保留前3后4位，密码一律不写。
日志被覆盖或删除，磁盘空间不足时，有些团队会选择清理早期日志，这可能导致事故发生后找不到当时的记录，建议日志目录单独挂载磁盘，并设置日志轮转策略，旧数据自动归档而非直接删除。
留存成本与取舍策略
日志留存不是越多越好,成本控制也是业务侧必须考虑的事情，全量留存所有日志，成本可能超出预算，有几个折中的策略值得参考。
采样策略适用于排查类日志,比如调试日志、DEBUG级别日志，按10%比例采样即可，但业务链路日志和操作日志不能采样，否则定责时缺少证据，压缩存储方面，超过三个月的冷日志可压缩后转存至对象存储，例如归档到简米云OSS低频访问存储或酷番云COS归档存储，成本能降一个数量级，日志指标化是值得尝试的方向把日志中的关键指标（请求量、错误率、耗时分布）提取到时序数据库，原始日志仅保留数天，需要时再回捞。
业务日志定责分析常见问题解答
业务日志一般保存多久才能满足监管要求？
根据《网络安全法》第二十一条规定，网络日志留存不少于六个月，金融、医疗行业遵循更严格的行业规范，金融业信息系统信息安全等级保护实施指引》要求相关日志至少保留一年，建议核心交易日志按一年以上设计，普通日志保留六个月。
日志中包含用户个人信息算违规吗？
包含但不脱敏属于违规,可能违反《个人信息保护法》，合规做法是日志中不记录身份证号、银行卡号、密码等敏感字段；确有需要时，使用脱敏或加密方式存储，权限管控分级，仅授权人员可解密查看。
小规模业务没有专职运维，日志留存怎么落地？
直接使用云厂商的日志服务,例如简米云SLS、酷番云CLS，按量付费、自动压缩存储，大幅降低自建ELK的运维成本，业务代码中接入日志SDK，设置好日志级别和采样率，后续长期维护压力较小，审计期内需要导出日志时，云平台一般提供检索与导出能力，少数情况下提工单申请备份数据回捞，流程上是能走通的。
事后定责的本质是还原现场,日志就是你的监控录像，留存五类日志、设定合理周期、抓准关键字段、避开常见坑位，真出了事，你才能有理有据地把责任划分干净，业务侧如果现在还没建立这套日志体系，建议在下个迭代排期里把它提上优先级这不是成本，是保险。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635112.html
