当
When "no healthy upstream" isn't about the upstream you think
最近我排查了一个间歇性故障，浏览器报错'no healthy upstream'，但监控显示 CPU 正常、Pod 未崩溃，服务甚至能自愈。起初我们以为是 CPU 节流导致，但数据并不支持。深入日志后，我发现真正元凶是数据层调用缺少超时限制，配合重试机制，导致 Worker 池被阻塞。这种'Head-of-line blocking'让健康检查超时，负载均衡器将实例剔除，最终引发级联故障。修复方案并非增加资源，而是为下游调用设置明确超时，并限制重试预算，防止内部重试超过外部负载均衡器的 Deadline。
边缘症状是危险的调优对象：资源饱和和依赖阻塞可能产生相同的症状，却需要完全不同的治疗方案。
- JohnMakin
遇到可用性事故时的本能反应是增加冗余：提高 CPU 限制、扩大工作池、增加副本。这对真正的容量问题确实有帮助。但在这里，这只会给重试循环提供更多可占用的工作线程。
在生产事故中，我有时很难向同事传达这一点。"我们的服务超时了，延迟很高，把所有资源都加上去！"是条件反射式的反应，但有时，甚至经常，如果性能下降的根本原因是数据库锁死之类的，增加工作线程并赋予它们更多火力，反而会让情况变得更糟。这种情况发生的频率比你想象的要高得多。
- ppedra
哇，这话说得太对了……
> 我的残疾不是生物学的悲剧，而是基础设施的失败。
人各有异：高矮、强弱、双腿、单腿、近视或失明。因此，指出我们的基础设施偏向某类人群而忽视其他类型（这是一个错误），是非常合乎逻辑的。
> "结账"按钮的标签是"Button_Graphic_v2_Final"
这点说得非常好。
- jtc331
连伪装 LLM 生成内容的力气都懒得花。
读起来让人难受。