埋点不许阻断业务
日志写入必须异步并设缓冲，写入失败时降级为本地暂存与告警，而不是让请求报错。为什么放在第一条：埋点故障导致主流程不可用，是日志改造最常见的生产事故，其回滚成本远高于日志本身的价值。
脱敏规则版本化
脱敏规则要版本化，回滚时切回上一版，同时标记已写入日志所用的规则版本，否则事后无法判断某段日志是否已脱敏。怎么做：规则变更与日志写入都记录版本号，查询时按版本解释字段含义，避免误读。
容量熔断与限流
为日志存储设置容量水位告警与写入限流，接近阈值时优先保护审计必需事件，丢弃调试日志。怎么做：按事件级别分层，明确哪些事件在任何情况下都不能丢，把规则写进配置而不是靠人临场判断。
误外泄不删日志
若日志被配成公开可访问或误发给外部，正确处置是立即收权、评估暴露范围、按流程上报，而不是删除掩盖。边界：是否构成数据安全事件、如何上报由客户方安全与法务判断，我方提供访问记录。
回滚也要演练
脱敏规则、采集配置与容量策略的回滚，只有演练过才知道能不能用。做法：每季度挑一次低峰窗口，把某条规则切回上一版，观察日志是否仍能正常写入、字段是否按旧规则脱敏、告警是否触发，并记录切换耗时与卡点；演练结果写进运维记录，作为回滚预案是否有效的证据，而不是只停留在文档里。
适用与不适用
适合谁
- 已上线运行的 AI 应用与部门及其实施团队
- 日志管道出现过故障的系统与部门及其实施团队
- 承担值班与应急处置的团队与部门及其实施团队
不适合谁
- 尚未上线、日志仍在设计阶段的项目
典型场景
某证券机构的投研问答助手在调整日志字段后，主流程开始偶发超时。排查发现新埋点同步写入且未设超时，队列积压拖慢了检索。值班人按预案切回上一版埋点配置，恢复异步缓冲，清理积压队列，再把新增字段改为异步补齐。
可执行步骤
- 变更前备份埋点配置与采集管道参数，记录版本号、变更人与时间。
- 出现主流程异常时先切回上一版埋点配置，恢复异步写入与缓冲队列。
- 清理积压队列，确认日志恢复写入且主流程时延回到基线水平，完成后归档。
- 若涉及脱敏规则变更，回滚规则并标注已写入日志所用的规则版本。
常见坑
- 埋点同步写入且未设超时，日志服务一抖动就把主流程拖垮，故障面比不记日志更大，事后难以补救。
- 回滚脱敏规则却不标记版本，历史日志无法判断是否已脱敏，只能整体重跑或弃用，容易被长期掩盖。
- 日志误对外暴露后第一反应是删除，证据消失，事件性质与影响范围都无法评估，责任与影响都说不清。
自检与验收清单
- 埋点是否异步写入，并设置超时与失败降级，并有记录
- 变更前是否备份埋点配置并记录版本号与变更人
- 存储容量水位与写入限流是否已配置告警，可现场抽查
- 回滚脚本是否包含积压队列清理与验证步骤，可逐项核对
- 误外泄的处置流程是否已获客户方书面确认并留档
常见问题
日志出问题能不能直接停掉？
临时停采集可以，但要先确认停的是哪一类事件。审计必需事件停掉会形成证据缺口，且很难补；建议按级别降级，先停调试日志与低价值事件，保留提问、检索、导出与授权变更。
回滚会不会丢日志？
可能丢一小段，但比主流程中断的代价低。补救方式是在回滚后记录缺口时间段，并用网关或上游系统的记录做交叉印证；缺口本身也要写进事件记录，事后解释时才有依据。
脱敏规则改错了怎么办？
切回上一版规则，并确认新写入的日志是否已按错误规则处理。若错误规则导致本该脱敏的字段明文写入，需按数据安全事件流程评估与处置，这一步由客户方安全负责人判断，不由实施方消化。