“幸福的家庭都是类似的，可怜的家庭却各有各的可怜”，托尔斯泰的名言。在 BUG 定位这件事件上，其实也有相似的景象：”菜鸟们的缓和无措都是类似的，老鸟们的办法却各有各的不同”。
年年过大促，年年定位现网故障。果不其然，往年 9.9 大促再次踩坑。看到组内的老手们排查问题的不知所措，也就有了这篇文档。本文的目标不在于穷举所有排查问题的伎俩，而在于帮忙老手们避雷。
走马观花
当遇到无奈轻易复现，并且短少有用的日志辅助缺点排查的时候，老手们的个别会抉择去看代码。然而，最要害的点来了，他们并不是在真正看代码，他们只是印证本人”脑海中记忆的代码”跟代码库里的是统一的。最常见的一个后果，就是失去一个“代码是这样的呀、没有问题呀”的论断。看代码过程是轻薄的，是跳跃的。
然而，计算机执行的并不是你脑海中的代码，而是实实在在的代码。计算机是谨严的、会精打细算的，从调用入口开始，一行不漏的逐行执行结束，而后返回后果。任何轻微的差别都有可能执行的是门路齐全不同，而 BUG 就是因为走了跟预期不一样的执行门路。
看代码须要一行一行的看，一层层调用的开展。无论是本人编写的代码，还是开源仓库的代码，还是服务框架的代码，任何一行代码都不应该被跳过。
好高鹜远，而不是走马观花。
鄙视数据
大型简单的零碎产生了繁多的数据。不同的团队成员看到数据（事实）之后，会退出本人对数据的判断（观点），呈现出二次加工之后的数据。最终可能失去是一份夹杂了观点和事实的数据。
当你听到蹄子声音时，你能够说听到了马蹄声，但实际上也可能是斑马蹄的声音，尽管概率很低。
同时，就会呈现以下类型的数据误用：
- 不对数据数据进行汇总、剖析，基于全面的数据进行假如
- 基于不牢靠的数据，导致谬误的假如
基于谬误的、全面的数据，进行假如，最终大概率是徒劳苦功高。
靠谱的应用数据的形式，该当是团队成员把相干的数据汇聚，依据业务架构造成“马赛克考察墙”，基于“马赛克考察墙”确定方向，再进行假如。
鄙视逻辑
很多很多人一上来就开始猜答案，基于他们认定的答案来发问，这是特地坏的一个习惯，因为这样找问题简直就只能凭运气了。
“分治”（Divide & Conquer）是一种十分通用的解决方案。在一个多层零碎中，整套零碎须要多层组件独特合作实现。最好的方法通常是从零碎的一端开始，一一查看每一个组件，直到零碎最底层。这样的策略十分实用于数据处理流水线。在大型零碎中，一一查看可能太慢了，能够采纳对分法（bisection）将零碎分为两局部，确认问题所在再反复进行。逐项排除、层层递进，能力零碎的剥离出假相。
还有一个常见的逻辑误区“相关性 = 因果性”。然而，相关性并不代表因果性。比方:
统计表明，游泳死亡人数越高，冰糕卖得越多，也就是游泳死亡人数和冰糕售出量之间呈正相关性，咱们能够由此得出结论说吃冰糕就会减少游泳死亡危险吗？显然不能够！这两个事件显然都仅仅是夏天到了气温升高了所导致的，吃不吃冰糕跟游泳死亡危险基本没有任何因果关系。
同理，跟 BUG 相干的异样数据，不代表数据的操作导致了 BUG。为了论证因果关系，须要更加紧密的实证来阐明。依照相干实践复现所有 BUG 体现的个性，且只体现这些特色。