深夜，告警系统又一次闪烁：后端接口请求异常增长。
对工程师小猫来说，这种提示并不陌生。小猫公司对接的业务分布在多个国家，虽然负责的是内部系统，也常有不同时区的用户在使用，而部分地区的网络状况并不理想。偶尔的波动，属于常态。
但这次不同。
异常集中在 2-3 个用户身上——他们在短时间内，触发了数十次同一个接口的请求失败，而且全部源自审核页面的列表查询功能。
“timeout 15000ms” ，每个错误都指向同样的超时原因。
奇怪的是，小猫无法复现这个错误。这只是一个普通的列表查询页面，也未发现会造成死循环逻辑的代码。没有需求迭代，没有用户反馈，没有明显异常。这个幽灵般的故障该被忽略，还是该被深究？
小猫选择了后者。而这个决定，意外地揭开了一个关于技术、产品与用户之间断层的故事。
01 可能是后端服务异常？
“接口超时”是典型的服务响应缓慢症状。小猫的第一反应是联系后端同事。
“奇怪，我没查到相应的失败日志。”后端同事反馈，“服务也没有激增的异常流量。”
数据似乎支持这一说法：虽然失败概率随请求量增加，但接口整体流量与往常相差不大，甚至低于历史峰值。
小猫困惑了。如果后端无异常，问题出在哪里？他转向了用户日志，开始在前端寻找线索。
02 新封装方法的隐藏属性
小猫想起，团队这几天有对整个项目进行了微前端架构升级。
微前端通过共享宿主资源来减小包体积，优化性能。作为改造的一部分，请求方法也进行了替换。
其他页面都完成了改造，只有这个页面出现异常，因此小猫一开始并不认为两者有强关联。
但一个简单的对照实验揭示了关键线索：当页面回退到改造前的代码，问题消失了。
原因是什么？是拦截器的日志上报逻辑有问题，还是请求库自身的重试机制？
小猫在列表数据获取方法前加上了更细致的打点日志，发现实际的请求数量确实有这么多。
对比新老请求方法的不同后，它发现新的请求方法默认设置了15秒超时，这与报错是匹配的，而旧的没有这个限制。
03 浏览器规则，看不见的排队队列
这让他想起了现代浏览器的网络工作原理：出于性能考虑，浏览器会对同一域名下的并发请求数设限（通常是 6-8 个）。关于 HTTP协议与浏览器并发模型 的更多细节，可以参考相关技术讨论。
当页面短时间内发起大量请求时，超出限制的请求会被放入等待队列，就像排队买票。如果前面有人“买票”特别慢（网络延迟高或查询复杂），后面的人就要等很久。
而 15 秒的超时设置，就像给每个排队者一个计时器。如果队伍移动太慢，即使还没排到窗口，一些人也会因“超时”而离开——他们的请求在浏览器层面就被取消，从未到达服务器。
至此，技术拼图完整了：海外用户的较高网络延迟相当于“买票更慢”；频繁的请求形成了“长队”；15 秒超时则导致“排队者中途离开”。因此，后端日志里也查不到对应记录。
解决方案很简单：移除或延长超时限制。但小猫依然困惑：为什么这几人会发出这么多请求？是因为安装了恶意脚本吗？由于出现问题的用户比例很低，他几乎要就此打住。
就在这时，小糕提出了一个深刻的问题：“这几个用户如此频繁地请求，真的只是意外吗？有没有可能，这和他们的日常工作方式有关？”
04 跳出代码，看见用户的真实世界
这个问题改变了一切。
原本，由于报错集中在特定的某个地区和特定的组织，这个问题被戴上了“技术滤镜”，大家都从纯技术的角度去思考背后的原因。
小猫对错误信息进行了更细致的观察，发现了一个规律：这些错误往往在一段时间内，由同一个用户连续触发，接着换另一个人继续，仿佛有一种轮班机制。
小猫产生了新的灵感：他们的工作模式，是不是集中时间段进行审核任务处理？由于系统没有自动获取新审核任务的能力，所以用户才会不断手动刷新页面，以获取待处理任务？
小猫联系了该团队管理者，谨慎地提出了这个推测。
对方的回答证实了一切：“是的，我们是轮班制。作为中台组织，需要处理多个地区的审核任务。这样的分班机制确实更方便我们管理。”
原来，这本质上是产品设计无法满足用户诉求引发的技术问题。
在其他部门，审核员收到审核通知后会直接处理，任务量分散，常规查询能满足需求。但中台模式下，没有自动派发和主动信息同步机制，用户只能不断手动刷新页面，导致请求激增。
小猫突然意识到，如果技术人员不了解用户的真实工作方式，很难从技术表象中看到产品本质。解决方案不应只是调整超时时间，而应是优化产品设计——引入长连接和主动任务派发机制，像电商客服系统那样，提升用户体验和工作效率。
05 小糕的总结
这个故事最珍贵的，不是解决了超时问题，而是发现了问题背后的问题。
- 数据异常是问题的信号，而非问题本身。如果系统表现出异常、让人无法合理解释的异常，背后一定有着更深层次的原因。
- 解决问题需要多维思考。技术的数据和问题诞生源于用户的操作，因此技术问题背后的根源可能是产品设计、用户体验或工作流程的问题。跳出技术看问题，往往能找到更根本的解决方案。
- 了解你的用户。他们如何使用系统？他们的工作流程是什么？他们的痛点在哪里？这些问题的答案，往往是解决技术问题的关键。
- 小告警可能揭示大问题。一个看似简单的超时错误，最终暴露了产品设计与实际工作模式的脱节，这种脱节影响的不仅是系统性能，更是团队效率和用户体验。
在你的工作中，是否也遇到过这样的“幽灵故障”？一个看似技术的问题，最后却发现是产品、流程或用户故事的冰山一角？欢迎在 云栈社区 分享你的经历或思考。
（本文为更具有教育意义，部分内容有所改编，如有雷同，纯属巧合）
发表于 17 小时前
|
查看: 2|
回复: 0
