【开发第一性原理】04 · 找不到问题点？把范围砍一半试试
《开发第一性原理》系列第 4/12 篇 · 上一篇：03 - 为什么一个数据只能有一个源头 · 下一篇：05 · 为什么”友好化”反而害了排障
系列说明：这个系列写我在开发里反复验证过的基本规律。不追新概念，只讲那些早晚会再次应验的东西。
TL;DR：找不到问题点？把范围砍一半试试。
程序出了问题，链路一长就不知道错在哪。这篇聊二分定位：在流程中间抓一条数据，判断问题在前半还是后半，几刀就缩到具体位置。中间点怎么选，有三个要求——能看、必经、看得懂。加上第一篇的”先查什么”，排障的两半就齐了。
一、一上午的排查，十分钟收场
前段时间排查一个接口问题。
数据从 SAP 传到一个外部系统，链路是这样的：自开发程序先从业务单据取数，写进中间表；后台作业把中间表转成 XML，发到对方服务器；对方解析入库之后，回传处理结果。
有一天，对方反馈：库里某个字段是空的。
哪一环出的问题？取数程序、中间表、XML 生成、传输、对方解析，都有可能。我当时的办法是从头查：先看取数程序，再看中间表，再看 XML，一段一段往下顺。
前三段查完，一上午过去了，还没找到。
后来我换了个办法：不在头上查，在中间抓一把。把那天发到对方的 XML 打开，看了一眼——字段就是空的。
那问题就在前三段，后面两段不用看了。再查中间表，值是有的。范围一下就缩到最后一段：XML 生成。进去一看，字段名和结构对不上，赋值赋丢了。
从换办法到定位，不到十分钟。
我以前觉得，这种链路问题只能一段一段顺序看，看到哪段错就是哪段。那次之后我改了看法：不用顺着看，在中间任何一个能看数据的地方抓一把，就能判断问题在这一环之前还是之后。判断一次，范围少一半。
这就是这篇要讲的东西：不知道问题点在哪，先把它可能的范围砍一半。
二、为什么砍一半这么有效
这就是二分查找。上学时学过：有序数组里找一个值，从头扫是 O(n)，每次看中间、砍一半是 O(log n)。1000 个元素，顺序扫最坏 1000 次，二分最多 10 次。
你可能觉得，环节少的时候，顺序看也挺快，何必费劲选中间点？五段六段的链路确实无所谓，但链路一长，O(n) 和 O(log n) 的差距就出来了。而且”抓中间”是个可以养成的习惯，比每次临时想辙可靠。
排障天然适合二分。因为流程大多是串行的——上一环的输出是下一环的输入。在中间抓一把，数据是好是坏一看便知，一次砍掉一半。砍几次，范围就缩到一眼能看见的那几行。
当然，关键不在”二分”这两个字，在中间点选得好不好。三个要求：
- 能看：这个点上能看到数据的真实状态——断点能看变量，接口能看报文，中间表能查记录
- 必经：流程一定从这里过，不会绕路
- 看得懂：这个点上的数据，扫一眼就能判断对错，不依赖太多上下文
选错点，二分就退化成顺序查。常见的错法：选了个旁路，流程根本不经过；选了个只出不进的终点，只能确认”到这里还是好的”，砍不掉前面的范围；选了个上下文很重的地方，数据不对，也说不清是这里错了还是上游错了。
你可能想问：要是错的就是中间这一环呢？也一样——它上游是好的，到这里变坏了，问题照样被圈死在这一环里。
三、猜数字游戏
这个道理最直白的版本，是猜数字。
心里想一个 1 到 100 的数，我来猜。最笨的办法从 1 猜到 100，平均五十次。聪明的办法是先问”比 50 大吗”——不管答案是是还是不是，一半的可能都没了。再问”比 75 大吗”，又砍一半。七次以内必中。
排障一模一样。每抓一个中间点，就是问了一次”比 50 大吗”。区别只在于，猜数字砍的是数字区间，排障砍的是流程区间。
四、我现在怎么做
落到日常，就两条路。
单程序调试：在流程中点设断点，看关键变量的实际值，判断问题在前半还是后半；在有问题的那半里再找中点。重复几次，缩到几行。最后记得第一篇的提醒——二分找到的那几行，往往就是个低级错误，回头查基础。
跨系统排查：选一个必经、能看数据的环节——中间表、接口报文、日志。抓一条数据判断好坏：好的，问题在后半段；坏的，问题在前半段。在剩下的那段里再选点，重复，直到定位到一个程序、一个方法。
先查什么和在哪查，是两件事。第一篇的奥卡姆剃刀，告诉你按出现频率排优先级，先花最小的成本查最可能的原因；这篇的二分，告诉你范围不明时怎么把它缩小。基础没查到，再用二分。两个合起来，才是完整的排障路径。
五、写在最后
找不到问题点，别从头查。在中间抓一把，把范围砍一半，再砍一半。
关键还是那个中间点：能看、必经、看得懂。
到这里，排障方法论的四篇就齐了：先按出现频率查基础（01），把复杂问题切开（02），一个数据只认一个源头（03），再用二分缩小范围（04）。
下一篇换个方向，聊失败处理：为什么”友好化”的错误消息，反而害了排障。