当交互设计回归本质，日志洞见铸就唯一入口

　　接口背锅。去年十二月份，灰度开关没推完，前端就切了新路由，PM 在钉钉群里甩了个截图：“用户说点了没反应”，测试立马补刀：“复现了，白屏三秒后跳 404”。我查日志链路，TraceID 对不上——根本没进网关。但运维同事已经拉了会议：标题写着《XX 接口超时导致首页崩溃》，连 PPT 都做好了，第三页是“QPS 曲线与 GC 暂停时间强相关”。我截图发过去，附言：“这接口压根没被调用过。”没人回。会议继续，主持人把“日志缺失”说成“监控盲区”，然后顺理成章立项上 APM。咖啡杯上印的公司 logo 歪了七度，我拿手指转了两圈。

　　我原以为这次能靠日志反向逼产品改交互逻辑——结果他们开了个需求评审会，把“点击无反馈”定义为“用户未触发成功态”，建议加个 toast：“正在努力加载中…”。我说：“你猜这个 toast 的曝光日志，和实际接口成功率偏差多少？”PM 看着我，像在看一个刚从 K8s 节点里爬出来的幽灵。他点头说好，转头让前端把埋点字段名从 `click_success` 改成 `intent_fulfilled`。监控大屏上一条无关曲线——那个标着“第三方 CDN 缓存命中率”的蓝线——忽然抖了一下，幅度不大，但持续了整整八秒。我不确定是不是电源波动，也没人管。这个我敢打包票：它和任何一次 release 都无关。

　　当交互设计回归本质，日志洞见铸就唯一入口。优胜劣汰。不是技术先进淘汰落后，是真问题自动浮上来，伪需求自己沉底。上个月测试提了个 Bug：“搜索框输入‘北京’，没出联想词”。我捞了三百七十二次调用，其中三百六十九次 request_body 是空的，剩下三次，body 里键名叫 `q` 的值全是中文引号包裹的“北京”——前端用了双引号拼接 JSON，而引号本身是中文全角。谁写的？前端小王。他倒了杯水，放在我桌上，杯子底下压着一张便签：“已修，下次发版生效。”我没碰那杯水。但/所以/可 这事其实根本不算 Bug，是输入法、框架、编码、字符集四层嵌套错位的结果，日志里全留着：method、uri、status、content-length、user_agent、x-real-ip、trace_id、upstream_time、body_truncated、response_body_size、request_headers…全在。可没人看。大家只盯着“有没有弹窗”“按钮变色没”“toast 出没出”。KPI 是按时上线，不是按时归因。

文章配图，仅供参考

　　跟 DBA 吵过一回。他说“你们日志写太多影响磁盘 IO”，我说“那你把慢查日志级别从 WARNING 提到 INFO”，他愣了三秒，然后说：“我们不打 INFO，打 INFO 我们得改 MySQL 配置，还要审批”。我问审批多久？他说“走完流程，大概…下个财年吧”。我笑了。他没笑。后来我悄悄把他们的慢查采样率从 1% 提到 5%，没告诉任何人。oncall 手机震了一下，不是告警，是测试发来的微信语音：“王哥，UAT 环境登录报错了，你看看？”我没回。因为我知道——三分钟内 PM 就会建群拉人，十五分钟内会有人提出“先回滚前端静态资源”，四十分钟会发现其实是 DBA 昨晚执行了 `OPTIMIZE TABLE`，锁表四十七分钟，而日志里 `connect_timeout` 字段早写了八遍“connection refused”。但没人去 grep。没人翻。因为“入口不是日志，是监控大盘，是告警群，是钉钉机器人转发的飞书卡片”。

　　优胜劣汰。真的。比如那个用了三年的旧搜索接口，上周终于下线了——不是因为 PRD 写了，不是因为排期到了，是因为它在日志里的调用量，连续十八天低于 0.3%，比保洁阿姨扫楼频次还低。运营同学自己提的下线申请，附件是一张 Excel，里面列了十二个下游服务，每个都标注“已确认无调用”，最后一行手写：“经核查，该接口唯一使用者为 2019 年实习生动手写的 demo 工程，代码已归档，镜像已删”。这件事我其实说不准：归档是归档了，但 demo 工程的 Git Tag 还挂在内部仓库上，tag 名叫 “search-demo-for-2019-intern-v1-final-actually-final”。名字太长，没人删得下去。

　　再说个碎的：上上周上线，我盯着 ELK 查凌晨三点的日志，前端小李在 Slack 里说“页面滚动卡顿”，我查了 `render_duration_ms`，全在正常区间。但我多看了一眼 `first_input_delay`，发现有一批设备上报值是负数，-18 毫秒、-22 毫秒、-15 毫秒……三个数，一共二十一条。我搜了浏览器 UA，全是 iOS 17.2 + Safari 17.2 组合。再查 JS 错误日志，果然，`performance.now()` 在某个 polyfill 里被重写了两次。这不是 Bug，是兼容性债。但它的“解法”不是修复，而是——把它从所有核心监控视图里摘出去，改成独立看板。理由很正当：“不属主业务路径”。谁拍的板？测试组长，她当时正啃苹果，核没吐，直接咽了。我看她咽下去，心想：这事其实早该有条规则，规定所有带负号的性能指标，自动屏蔽。但没人写这条规则。因为写规则，不如改埋点字段名快。

　　我现在每天上午十点打开 Kibana，不输查询语句，就点那个“最近一小时最常出现的 error_message”聚合面板。看五分钟后关掉。有时候上面飘着一条 “Invalid date format in query param ‘from’”，后面跟着一百三十个 trace_id。我知道这是运营在自助分析平台里手输日期，输成了 “2024-13-01”。这种事不该出现在生产日志里，但它出现了，而且活得好好的。它没崩系统，没拖垮 DB，甚至没触发任何告警——因为我们在告警策略里，把它标成了 “ignore_high_volume_low_impact”。这个标签是我加的。加完我就后悔了。但没撤。撤了，就得重新跑一轮漏报率验证，而验证脚本，还在测试环境里跑着第五轮 case。我不打算动它了。下周我准备把日志采集探针的 logrotate 配置从 daily 改成 hourly，就试三天。行就行，不行拉倒。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!