程序员问题定位之（2）——问题定位的误区

问题定位是一个逻辑推理的过程，是一个否定之否定的逆向思维的推理过程。问题定位不是经验的正向演化。

上来就是框架，就是架构

弱水三千，与你何干，你只取一瓢饮。

框架是用来辅助定位的，正所谓：横看成岭侧成峰，远近高低各不同，框架的作用在于鸟瞰全局，掌握复杂模块的相互影响，避免定位过程中的信息遗漏。

如果定位过程不能做到在架构上逐步缩小问题范围，那么这个架构图在定位过程中的作用又是什么呢？

依赖经验进行正向演化，将问题定位纳入自己演化的轨迹中

世界上没有两个完全相同的问题，如果存在，那么这个团队就可以解散了。

文章前面也提到：根本原因、路径和现象并不是一一对应的，每一个线上问题都有它的唯一性：表现相同的问题，原因和路径大相径庭；相同的根本原因，最终的传播路径和表现也不尽相同。

依赖经验的正向演化比较具体的表现就是定位过程中出现如下词汇：

没有任何推理过程的必然结论

这个词依赖于人的眼界和高度，没有见过的东西都会被这个 排除。连接超时还有可能是本身及其网卡存在IO等待呢。

连接拒绝，无非是因为...

连接超时，必然是因为下游服务耗时过长导致...

根据经验，出现这种情况是因为...

定位过程过分纠结新老版本对比

两个分别正常的子模块，合并之后构成的系统不一定是正常的。否则，就没有必要做集成测试和系统测试了。所以做一下代码diff就可以，没必要过分纠结对比，尤其是在复杂问题的定位中。

之前是好的，但是上线后就异常了

老版本是正常的，新版本异常了

错把假设当结论

前端传递了A字段，但是服务端没有获取到A字段，可能是服务端代码有异常或框架有漏洞。

前端传递的A=12345，但是服务端获取到的确实A=0，可能是框架有漏洞，不能处理整数。

前端已经将POST数据A=B了，但是后端$_POST['A']未获取到值，可能是框架有漏洞。

编译方案升级之后，出现了日志丢失的情况，是不是编译方案有问题？

有一些类似的问题在解决的时候困扰了我很长时间。在请教别人类似问题的时候，也问过如下的问题：

为什么php在某些情况下无法获取某个POST字段？

如何解决升级编译方案到C后，出现代码丢失的情况？

回想起来，这里最大的问题就是错把假设当结论了。如上提到的一些看起来是结论的内容，其实更多的是自己在定位过程中的假设，而这个假设又没有用足够的证据去进行证明，最终导致问题定位的效率特别差。

大胆假设，小心求证。但是在问题定位过程中，往往是： 。最终导致一个错误的结论，甚至归结为框架问题，不了了之。