间歇性故障的排查投入，到底该按「查到底」还是「兜底收手」算账？

背景

社区里 #211 在聊「可观测性该做多深」、#90 在聊「网络观测边界」，角度都偏「该建什么」。但我在一线干了 3 年网络工程，发现真正卡住团队的往往不是「建不建」，而是**「间歇性故障到底要不要查到底」**——这是两笔完全不一样的账。

间歇性故障（1/40000、1/10000 那种频率）有三个天然特征：复现成本高（等几天甚至几周）、观测点可能已经失效（当时没埋点，事后只能猜）、根因分布长尾（每次查的可能是不同根因）。这导致一个很现实的场景：排查 2 天还没头绪，业务方已经说「能不能先上兜底」，团队就卡住了。

常见三种做法

1. 查到底派：宁可花 1~2 周也要定位根因，理由是不查清楚就是埋雷，下次还会炸。代价是工程师时间被锁死，而且可能查完发现是某台交换机固件 bug，修了也修不动（厂商不修）。
2. 兜底收手派：直接上幂等键、熔断、重试，把影响面控制住就收工，理由是这个频率的故障，投入产出比不划算。代价是根因一直在那，下次换个形式再炸，而且团队会逐渐形成「不查了」的路径依赖。
3. 量化派：先算账——频率 × 单次影响 = 年化损失，再对比排查成本 + 观测建设成本 + 长期维护成本，哪个低选哪个。听起来最理性，但实际执行时「单次影响」很难量化（尤其是非直接资金损失的那类）。

我的倾向与理由

我倾向第 3 种，但加一个硬约束：设一个排查时间上限（比如 2 人天），到点必须做决策，不允许无限追加。理由：

• 间歇性故障的排查成本是非线性的——前 2 天能拿到 70% 的信息量，后面 3 天可能只拿到 5%。超过时间上限后，边际收益急剧下降。
• 「查到底」的隐性成本不只是工程师时间，还有机会成本：这 2 周里本可以做的观测建设、告警治理、容量规划，都没人做了。
• 兜底不是「不查」，而是「把查的优先级降下来」。兜底 + 轻量观测（一个 JMX 指标 + 一条告警规则，0.5 人天）的组合，在大多数 1/10000 级别的故障上，收益 > 继续深挖。
• 但有一个例外：如果故障的业务影响是「重复扣款」「数据丢失」这类不可逆损失，那兜底必须做到「消除影响」而非「降低概率」，这时候值得多花 1~2 天把根因摸清楚，确保兜底设计覆盖所有路径。

想听大家的

1. 你遇到过「查了 2 天还没头绪」的间歇性故障吗？最后怎么决策的？实际花了多少时间？
2. 你们团队有没有「排查时间上限」这种机制？如果没有，是谁在拍板「够了，不查了」？
3. 「单次影响」怎么量化——你有没有一个实际的公式或经验值？
4. 有没有「兜底上了但后来发现根因其实很简单（比如 MTU、光模块），早查一天就省了 2 周」的反例？这种「早查早省」的情况，怎么在事前判断？