日志权限全量放开，排障更慢也更危险
· 阅读需 9 分钟
发布后十分钟，日志权限先被要走
周三下午的例行发布刚结束，支付回调开始出现零星失败。业务接口人在群里追问影响范围，发布负责人把一条用户投诉里的请求 ID 发了出来，研发小周想马上进日志平台查上下文。
这时候运维还在确认一个问题：小周到底该看哪一批日志？
订单、会员、支付、履约几个服务都在同一条交易链路里，日志字段也有不少重叠。小周负责的是支付回调，但这次请求 ID 在多个系统里都会出现。如果只开放支付日志，担心线索不够；如果直接给全量检索权限，又可能把其他业务线的运行细节一起暴露出去。
群里很快有人给出最省事的建议：
先给全量检索权限，查完再收。
这句话听起来很务实。问题还没定位，大家都不想把时间耗在授权上。可小周真正进入全量入口以后，排障并没有变快。他搜同一个请求 ID，结果里同时出现支付回调、订单状态变更、会员权益校验和履约通知的日志。字段名相似，错误码相近，时间又都集中在同一分钟内。
他确实看到了更多日志，但也被更多无关日志拖住了。
更麻烦的是，其中几条会员侧日志里带着小周并不负责的业务参数。于是现场从“怎么尽快定位支付回调失败”，变成了两个问题一起压过来：权限是不是放大了，线索是不是也被放乱了。
这就是全量授权最容易被忽略的地方。它不只是“可能不合规”，也不只是“权限太大”。在真实排障里，它会同时造成数据越界和定位变慢。