日志脱敏规则变更如何做离线回放验证?

日志脱敏规则一改，最怕的不是改错，而是改完没人知道到底改对没有。线上跑一天，看着风平浪静，实际上某条异常分支还在把整个请求体原样打进日志——这种事在不少团队都发生过。所以规则变更之后，比较稳妥的做法是先做一次离线回放，拿历史日志当“试验田”，让新规则在不出事的环境里先跑一遍。

离线回放说白了就是：把以前真实产生过的日志样本捞出来，用新规则重新处理一遍，看看哪些内容被命中、哪些被放过、哪些原本该藏的没藏住。它像给规则做一次体检，不碰线上流量，也不影响排障。

先想清楚回放要看什么

回放不是把日志跑一遍就完事，得带着问题去看。最直接的两个指标是命中量和误报量。命中量高，说明新规则确实在干活；误报量高，说明规则收得太紧，把不该抹的信息也抹了。比如一个统计字段因为名字里带 token 被整段掩码，排障的人打开日志只看到一串星号，那就属于误伤。

这里的关键判断是：收紧规则会让误报上升，放宽规则会让漏报上升。回放数据能把这个权衡摆到台面上，而不是等线上出问题再回头补。

回放样本要有代表性

样本挑得好不好，直接决定回放结果有没有参考价值。比较合理的做法是按路径覆盖来选：正常请求、业务校验失败、未捕获异常、下游调用超时，这几类各取一些。异常路径尤其不能漏，因为脱敏失效最常见的地方就是异常分支——正常请求里密码被替换成星号，出错时却把整个请求体打了出来。

样本里最好带上那些曾经出过问题的日志，它们是最能检验新规则的“老病号”。如果新规则在这些样本上仍然放过明文，那说明改动没到位。

回放结果怎么读

跑完回放，不要只看总数。命中量高不一定全是好事，得区分是命中了真正敏感的值，还是把普通业务编号也当成了敏感数据。误报的处理原则是缩小匹配范围，而不是放宽全局规则。能用字段名精确匹配的，就别用内容正则去猜；非用正则不可时，加上长度或校验位约束，误命中会少很多。

还有一点容易被忽略：回放时也要看“应当保留”的信息有没有被误伤。错误码、请求 ID、耗时、脱敏后的末几位，这些是排障的命根子。规则改完如果连这些都抹了，日志就成了一堆无用文本，团队迟早会想办法绕开规则。

回放之后别忘了补用例

离线回放能发现误报和漏报，但它是一次性的检查。真正让规则变更长期可靠的，是把回放里发现的问题固化成测试用例：新增字段补一个带标记值的用例，确认正常和异常路径都被处理；被放宽的规则补一个“应当保留”的反向用例，防止以后有人误删。

规则会随业务一直变，字段清单也会越来越长。离线回放的价值，就是让每次变更都有据可查，而不是凭感觉上线。回放跑完、用例补齐、CI 里能拦住新增的明文输出，这套流程才算真正转起来。