1. 从一个凌晨两点的故障说起我发现问题只有两类做技术或者带项目的人迟早会碰到那种让人头皮发麻的瞬间一个系统莫名其妙地挂了你翻了三小时日志问了五个人试了十种办法还是不知道问题到底出在哪。我第一次被只有两种情况这个词击中就是在这种时刻。那天凌晨两点某个线上服务开始间歇性返回错误。我和另外两个同事轮流排查把能看的地方全看了一遍网络、磁盘、数据库连接池、GC日志……整个脑子被十几种可能性塞满反而连第一步往哪儿走都确定不了。后来是一个年长一点的同事问了我一句你别管那么多先告诉我这个问题只有两种情况是哪两种我当场愣住了。所谓只有两种情况听起来像一句废话但真被问住的时候才发现我压根没有认真想过这个问题能把可能性收敛到什么程度。憋了半天我最后吐出一句要么是代码逻辑在特定条件下出错要么是环境在特定时间点发生了变化。就这两种没了。顺着这个思路往下走事情突然变得异常简单。我们把两种情况的验证动作分别列出来第一种拉出那段请求的入参和堆栈看能不能在测试环境复现第二种对照线上环境的配置变更记录和监控曲线看是否有异动。结果只用了大概二十分钟问题就定位了。代码逻辑其实没错环境也没经过什么大改动——真相是数据库连接池的参数在某个版本打包时被悄悄调低了属于环境变化这一类里的一个子分支。但关键在于从我分出那两种情况开始排查就从一个发散的无底洞变成了一条有终点的走廊。从那以后只有两种情况成了我处理问题时的默认开场白。这篇文章想分享的就是这套看起来朴素得近乎废话的思维方式——它怎么救命、怎么用、什么时候会失效以及我踩过的那些把两种当成偷懒借口的坑。如果你也经常被好像哪里都有问题困住或者想帮团队把排查问题的效率提上去这篇应该对你有用。2. 只有两种情况为什么能救命二分类的底层逻辑先别急着觉得这招太简单。很多真正有用的方法拆到底层都是简单到让人不好意思用的东西。但只有两种情况这件事背后是有认知科学和工程方法撑着的弄明白它为什么有效你才舍得在关键时刻用它。2.1 人的工作记忆装不下太多可能性心理学里有个经典的结论人的工作记忆同时只能维持四五个信息块。你在排查一个故障时脑子里同时转着网络问题磁盘满了吗是不是有人改了配置会不会是第三方依赖抽风代码最近上线了什么……这五六七八个念头一挤你的判断力其实已经瘫痪了。这就像你手里攥着一大把钥匙去开一扇门每把都看一眼、试一下转一圈回来可能连哪把试过都忘了。但如果你先把钥匙分成两类铜的和铝合金的门锁是铝合金的那至少能扔掉一半。二分类最大的作用不是找到答案而是把搜索空间砍半。只有两种情况本质上是一个二分检索策略。你不需要知道二十种可能里哪一种是真相你只需要找到一个划分方式让所有可能均匀地分成两边然后设计一个动作一次性排除掉其中一边。每做一次搜索空间就少一半最多五六轮问题范围就小到肉眼可见了。2.2 二分类迫使你去定义边界而边界就是答案藏身的地方我见过很多排查场景大家不是不努力是努力得很散。你说查日志他去翻监控你说看代码他又去问客户。表面上是分工实际上是谁都没有想清楚这个问题到底属于哪一边。强行把问题分成两种情况逼着你必须回答一个之前一直回避的问题这两类的分界线在哪。比如代码问题和环境问题分界线是什么是把同样的代码放到另一个干净环境里跑能不能复现。能复现往代码那边走不能复现往环境那边走。这个分界线一旦被说出来排查动作就自动浮出水面了。我后来跟团队分享时总说一句话如果你连两种情况的边界都说不清楚那你其实还没有理解这个问题你只是收集了一堆现象。2.3 和穷举式排查的对比差别不在勤奋在收敛速度很多人排查问题时习惯开一张大清单把能想到的原因全列出来然后逐个验证。这种做法没有错但它有个致命的隐含假设你有足够的时间、精力和工具去挨个验证。现实往往是验证手段本身就带成本有些检查要重启服务有些要等一个低峰期窗口做一轮下来几小时没了。二分类是另一种玩法。它不追求一次列全只追求每次砍半。两者的对比如下维度穷举式排查二分类排查第一步动作列二十条可能原因找出能把可能原因分成两堆的一条分界线核心成本全量验证逐项排除设计一个高信息量的验证动作中间产物一张越划越长的清单一棵不断长深但每层只有两叉的决策树对大脑的要求记忆力判断力卡壳时的表现反复重看同一批日志回到分界线重新审视划分是否成立当然现实里两种方法经常混着用穷举清单可以作为二分类的素材来源。但如果你被一个问题困住超过一小时我的建议是把清单收起来先回答只有哪两种情况。3. 这套框架在三类场景里的真实用法光讲原理没意思真正让只有两种情况立住脚的是它能直接搬到各种场景里。我用它处理得最多的是技术排查、需求评审和项目进度失控这三类事。每一类我都配一个真实经历过脱敏处理过的的案例讲清楚分法、验证动作、以及最后怎么收场的。3.1 技术排查是代码问题还是环境问题技术排查是这套思路的天然主场。任何一个线上故障在信息不足的时候最稳的二分法就是代码 vs 环境。代码这一边包括业务逻辑写错、异常没捕获、并发处理有缺陷之类环境那一边包括配置不对、依赖版本漂移、资源不够、网络策略变化之类。分界线很好定把出问题的代码原封不动放到一个独立的干净环境里跑一遍。这里有个很容易被忽略的操作细节独立环境要独立得足够彻底最好连依赖的版本都固定成和线上一致否则你复现不出来会误判成代码没问题。我印象很深的一次某个服务在每天早上九点到十点密集报错客户反馈很激烈。团队里新同事的第一反应是查业务日志翻了一上午发现业务逻辑确实没什么异常于是怀疑是数据库慢查询。我把他拉回来问了那句只有两种情况。他想了想说要么是代码在某个时间窗口里走了某条特殊分支要么是那个时间窗口里的某类外部依赖出现了问题。然后我们做了个验证设计把九点到十点的请求抽样出来按接口路径分组看失败率同时看这个时段外部认证服务的耗时曲线。结果半小时就出来了——是某一个第三方接口在该时段超时率飙升而代码里对超时的重试逻辑写得过于激进把雪球滚大了。这个案例里两分之后其实又继续二分了一次环境问题内部还要再分第三方依赖的问题 vs 自建组件的问题。这就是二分类的妙处它不是只分一次而是可以像决策树一样一直往下分每层只有一个判断大脑完全跟得上。3.2 需求评审是真需求还是伪需求只有两种情况不只对故障有用对要不要做某件事同样适用。我在评审需求时常用的一招是一个需求只有两种情况要么它解决了一个真实存在的痛点要么它只是看起来不错。怎么判断我自己的标准是两个验证动作。第一个动作问谁在用。这个功能上线后每天真正会用到它的人是谁如果回答是所有用户那基本等于没说如果是某类用户、某种场景这才有了验证的抓手。第二个动作问如果不做会怎样。注意不是做了有什么好处而是不做会损失什么。你会发现很多需求在第二个问题面前直接塌掉——不做也不会怎么样那就是伪需求至少不是当下必须做的需求。有一次某合作方提了个很花哨的报表功能说数据分析团队非常需要。我们把真伪需求这个二分法摆到桌面上后对方说真需求是真需求但要解决的是每周手动导数据太麻烦。于是我们没有做那个花哨的报表系统而是先做了一键导出加定时推送一个小功能一周上线痛点直接消掉了一半。这个案例想说明的是二分法不是让你拒绝需求而是帮你在失控之前把想要的东西和需要的东西分开。分开了优先级自然就清楚了。3.3 进度失控是能力问题还是承诺问题项目延期是每个带团队的人都会遇到的坎。以前我遇到延期第一反应是排期不合理然后把所有责任归到估算头上。后来我用二分法重新定义了一次延期思路完全打开了。一个任务延期只有两种情况执行者不具备完成它的能力或者执行者在承诺时就没有给出真实的完成时间。注意这两种情况的应对方式完全相反。能力问题要去补资源、换人、拆任务、给培训指望靠加加班解决是没有用的承诺问题要去解决沟通机制让估算不再变成一场讨价还价而是基于事实的推演。有一次项目里某位新同学连续两个迭代都延期每次都说是没想到这个细节这么麻烦。表面看是典型的估算不准但我用二分法一拆如果是能力问题他应该说不清楚技术难点在哪里如果是承诺问题他的问题清单应该能看出他在回复排期时犹豫过。我找他聊的时候没有直接问你能不能做而是让他现场讲述实现思路。聊了二十分钟发现他对核心模块的技术方案理解得其实很到位卡住他的是一些跨部门的数据权限沟通。于是结论就清楚了不是能力问题是他在承诺排期时没有把外部依赖的时间算进去。后来我们改了做法凡是涉及跨部门依赖的任务排期必须包含等对方响应的缓冲并在周会上同步依赖状态。此后再也没出现过这类延期。这就是二分法的价值——同样是延期两个字背后的药方完全不同分错了类怎么努力都是隔靴搔痒。4. 把复杂问题拆成两种情况的三个准则你可能已经发现了只有两种情况这个说法不新鲜新鲜的是怎么拆。拆得好问题迎刃而解拆得烂跟没拆一样甚至会误导你走弯路。我总结了三个准则基本可以覆盖大多数场景。4.1 互斥两种情况的边界必须清晰互斥的意思是一个具体的事实不能同时被归到两边。如果边界模糊验证动作就没法设计。反面案例是心态问题 vs 能力问题。你说一个员工总是拖延到底是态度不好还是没那个本事这两个东西可以同时成立也可以互相转化根本没法用一个测试动作把它们分开。这种二分就是伪二分。正面案例是前面说的能复现 vs 不能复现。一次报错要么能在受控环境里稳定复现要么不能不存在中间状态。这个边界清清楚楚验证动作也清清楚楚。所以拆的时候可以自问一句我能不能设计一个动作让结果的输出明确指向其中一边如果不能说明这条分界线画错了换一条。4.2 穷尽两种情况的并集必须覆盖所有可能很多人把二分法用砸是因为漏掉了第三种可能。比如排查性能问题有人习惯分成代码慢 vs 数据库慢但如果瓶颈在网络的传输链路上呢这就被漏掉了。穷尽不是要求你一开始就能列全所有可能性而是要求你划分的那条线像一张大网没有任何可能漏到网外。合理的做法是当你想出的两个分类有其他漏网之鱼时不是再加第三个分类那就不是二分了而是换一条线来切。比如代码慢 vs 数据库慢可以换成用户侧感知慢 vs 服务端处理慢因为任何一条链路要么发生在服务端处理范围之外网络、客户端渲染要么发生在服务端处理范围之内。这样划分穷尽性就够用了。记住一个原则如果有人说还有第三种情况通常不是情况多了而是你的那条分界线本身选得不够好。4.3 可证伪每种情况都要有一个明确的验证动作这是整个框架里最实用的一条每当你分完两类必须紧接着写出每个分类对应的验证动作写不出来说明你还没有真的理解这个问题。我自己的习惯是列一张两行的表情况验证动作判定标准代码问题在干净环境复现并抓取堆栈稳定复现堆栈指向业务代码环境问题对照变更记录、监控曲线、配置差异找到与故障时间点吻合的变更这张表填完排查就不再是大家一起看看而是变成流水线式的执行。谁去复现、谁去查变更分工自然就出来了。这也是为什么我说只有两种情况是一个团队工具而不只是个人思维——它让协作有了共同的坐标系。5. 这套思路的边界什么时候它真的会失效任何方法论都有边界只有两种情况也不例外。我自己就上过当差点把好工具用成坏借口。下面三种情形是我实际遇到过、也踩过坑的写出来帮你绕开。5.1 变量是连续的时候二分会失灵二分法适合离散状态的问题要么是、要么不是。但有些问题的变量是连续的比如性能优化。你说一个接口慢分代码问题 vs 环境问题然后呢代码问题里可能有一百个可以优化的点环境问题里也可能牵扯一连串参数调整。这种情况下二分只能帮你定位大方向不能帮你找到最优解。我碰过最典型的一次某个服务的响应时间从 200ms 涨到 800ms我们用二分法锁定了是代码问题但接下来的优化工作仍然是一大摊子事——数据库查询、对象序列化、线程池参数、缓存命中率哪个对性能的贡献都不小。这时候需要的是 profiling 数据用数字去排优先级而不是继续二选一。所以我会提醒自己二分法负责定性连续变量的环境里还要引入定量的梯度。先用二分把大方向收窄再用测量工具在收窄后的空间里做精细搜索。5.2 非此即彼的诱惑把两种变成偷懒的挡箭牌二分法最危险的用法是拿它当回避思考的借口。有些人拆出两种情况后只挑一边动手查查不通就赖在另一边甚至两边都不查直接说反正不是这个就是那个先猜一个吧。这完全背离了二分法的初衷。别忘了每一步验证动作才是核心。只有两种情况但两个都不验证等于没有分。我自己踩过的坑是有一次分出了代码问题 vs 部署问题我凭直觉认定是代码问题花了一整晚反复看代码结果第二天早上发现只是某个配置文件的缩进写错了属于部署那边的问题。那次之后我立了个规矩分完类先做成本最低的那个验证动作而不是先做自己偏好确信的那个。5.3 真正多头并发的故障场景别迷信一次二分到底有些故障是多个原因共同作用的结果比如磁盘 IO 高、业务量上涨、某段代码又正好有性能瓶颈三件事叠在一起才出事。这种情况下硬要分成两种情况往往会把多因叠加问题简化成单一原因问题导致你找到了一个原因就收工真正的隐患还埋在下面。我的应对方式是允许分叉。第一层二分之后两边都可能继续往下分叉于是这棵树会自然地长出多叉。关键是每一层、每一步仍然只做一个二选一的判断。二分的精髓从来不是这世界上只有两种原因而是每一步我只面对两个选项。头顶上有十个原因并不可怕可怕的是你在一个时间点同时要处理十个原因。打个比方排查问题像走迷宫你不需要一眼看到终点你只需要在每个转角做出一个二选一左还是右。多因叠加的故障也不例外只是转角更多而已。6. 最后的一点个人体会和一个小工具说回最开始的那个凌晨。后来我把只有两种情况变成了团队里一条不成文的规矩碰到任何棘手问题动手之前先在白板上写下两个分类和对应的验证动作。写不出来就继续想想出来再动手。就这么简单的一条规矩把我们开问题会的时长缩短了大概三分之一。我个人的体会是只有两种情况真正改变的不是排查速度而是你在失控感面前的心理状态。人一旦觉得问题无穷无尽第一反应是焦虑第二反应是乱试而一旦知道只有两种情况就算暂时还没验证出是哪一种心里也是踏实的——因为终点的轮廓已经能看到。最后分享一个我一直在用的小工具一张 A4 纸中间画一条竖线左边写情况 A右边写情况 B。每行对应一个验证动作做完就在那行后面打个勾。这张纸不用保留它的价值在写下来的瞬间就实现了——它逼着你的大脑从感觉哪里都有问题切换到我先排除哪一边。相信我下次你再遇到让人头大的问题花五分钟把这张纸画出来你会回来感谢这个方法。另外顺便多说一句这个思路不只适用于工作和故障。生活里那些让你纠结的选择其实也常常可以拆成两种情况。她到底是对我有意思还是只是礼貌这份工作到底是成长缓慢还是我自己心态出了问题——把模糊的焦虑翻译成具体的二选一往往答案就在验证动作里浮现出来了。
1. 从一个凌晨两点的故障说起我发现问题只有两类做技术或者带项目的人迟早会碰到那种让人头皮发麻的瞬间一个系统莫名其妙地挂了你翻了三小时日志问了五个人试了十种办法还是不知道问题到底出在哪。我第一次被只有两种情况这个词击中就是在这种时刻。那天凌晨两点某个线上服务开始间歇性返回错误。我和另外两个同事轮流排查把能看的地方全看了一遍网络、磁盘、数据库连接池、GC日志……整个脑子被十几种可能性塞满反而连第一步往哪儿走都确定不了。后来是一个年长一点的同事问了我一句你别管那么多先告诉我这个问题只有两种情况是哪两种我当场愣住了。所谓只有两种情况听起来像一句废话但真被问住的时候才发现我压根没有认真想过这个问题能把可能性收敛到什么程度。憋了半天我最后吐出一句要么是代码逻辑在特定条件下出错要么是环境在特定时间点发生了变化。就这两种没了。顺着这个思路往下走事情突然变得异常简单。我们把两种情况的验证动作分别列出来第一种拉出那段请求的入参和堆栈看能不能在测试环境复现第二种对照线上环境的配置变更记录和监控曲线看是否有异动。结果只用了大概二十分钟问题就定位了。代码逻辑其实没错环境也没经过什么大改动——真相是数据库连接池的参数在某个版本打包时被悄悄调低了属于环境变化这一类里的一个子分支。但关键在于从我分出那两种情况开始排查就从一个发散的无底洞变成了一条有终点的走廊。从那以后只有两种情况成了我处理问题时的默认开场白。这篇文章想分享的就是这套看起来朴素得近乎废话的思维方式——它怎么救命、怎么用、什么时候会失效以及我踩过的那些把两种当成偷懒借口的坑。如果你也经常被好像哪里都有问题困住或者想帮团队把排查问题的效率提上去这篇应该对你有用。2. 只有两种情况为什么能救命二分类的底层逻辑先别急着觉得这招太简单。很多真正有用的方法拆到底层都是简单到让人不好意思用的东西。但只有两种情况这件事背后是有认知科学和工程方法撑着的弄明白它为什么有效你才舍得在关键时刻用它。2.1 人的工作记忆装不下太多可能性心理学里有个经典的结论人的工作记忆同时只能维持四五个信息块。你在排查一个故障时脑子里同时转着网络问题磁盘满了吗是不是有人改了配置会不会是第三方依赖抽风代码最近上线了什么……这五六七八个念头一挤你的判断力其实已经瘫痪了。这就像你手里攥着一大把钥匙去开一扇门每把都看一眼、试一下转一圈回来可能连哪把试过都忘了。但如果你先把钥匙分成两类铜的和铝合金的门锁是铝合金的那至少能扔掉一半。二分类最大的作用不是找到答案而是把搜索空间砍半。只有两种情况本质上是一个二分检索策略。你不需要知道二十种可能里哪一种是真相你只需要找到一个划分方式让所有可能均匀地分成两边然后设计一个动作一次性排除掉其中一边。每做一次搜索空间就少一半最多五六轮问题范围就小到肉眼可见了。2.2 二分类迫使你去定义边界而边界就是答案藏身的地方我见过很多排查场景大家不是不努力是努力得很散。你说查日志他去翻监控你说看代码他又去问客户。表面上是分工实际上是谁都没有想清楚这个问题到底属于哪一边。强行把问题分成两种情况逼着你必须回答一个之前一直回避的问题这两类的分界线在哪。比如代码问题和环境问题分界线是什么是把同样的代码放到另一个干净环境里跑能不能复现。能复现往代码那边走不能复现往环境那边走。这个分界线一旦被说出来排查动作就自动浮出水面了。我后来跟团队分享时总说一句话如果你连两种情况的边界都说不清楚那你其实还没有理解这个问题你只是收集了一堆现象。2.3 和穷举式排查的对比差别不在勤奋在收敛速度很多人排查问题时习惯开一张大清单把能想到的原因全列出来然后逐个验证。这种做法没有错但它有个致命的隐含假设你有足够的时间、精力和工具去挨个验证。现实往往是验证手段本身就带成本有些检查要重启服务有些要等一个低峰期窗口做一轮下来几小时没了。二分类是另一种玩法。它不追求一次列全只追求每次砍半。两者的对比如下维度穷举式排查二分类排查第一步动作列二十条可能原因找出能把可能原因分成两堆的一条分界线核心成本全量验证逐项排除设计一个高信息量的验证动作中间产物一张越划越长的清单一棵不断长深但每层只有两叉的决策树对大脑的要求记忆力判断力卡壳时的表现反复重看同一批日志回到分界线重新审视划分是否成立当然现实里两种方法经常混着用穷举清单可以作为二分类的素材来源。但如果你被一个问题困住超过一小时我的建议是把清单收起来先回答只有哪两种情况。3. 这套框架在三类场景里的真实用法光讲原理没意思真正让只有两种情况立住脚的是它能直接搬到各种场景里。我用它处理得最多的是技术排查、需求评审和项目进度失控这三类事。每一类我都配一个真实经历过脱敏处理过的的案例讲清楚分法、验证动作、以及最后怎么收场的。3.1 技术排查是代码问题还是环境问题技术排查是这套思路的天然主场。任何一个线上故障在信息不足的时候最稳的二分法就是代码 vs 环境。代码这一边包括业务逻辑写错、异常没捕获、并发处理有缺陷之类环境那一边包括配置不对、依赖版本漂移、资源不够、网络策略变化之类。分界线很好定把出问题的代码原封不动放到一个独立的干净环境里跑一遍。这里有个很容易被忽略的操作细节独立环境要独立得足够彻底最好连依赖的版本都固定成和线上一致否则你复现不出来会误判成代码没问题。我印象很深的一次某个服务在每天早上九点到十点密集报错客户反馈很激烈。团队里新同事的第一反应是查业务日志翻了一上午发现业务逻辑确实没什么异常于是怀疑是数据库慢查询。我把他拉回来问了那句只有两种情况。他想了想说要么是代码在某个时间窗口里走了某条特殊分支要么是那个时间窗口里的某类外部依赖出现了问题。然后我们做了个验证设计把九点到十点的请求抽样出来按接口路径分组看失败率同时看这个时段外部认证服务的耗时曲线。结果半小时就出来了——是某一个第三方接口在该时段超时率飙升而代码里对超时的重试逻辑写得过于激进把雪球滚大了。这个案例里两分之后其实又继续二分了一次环境问题内部还要再分第三方依赖的问题 vs 自建组件的问题。这就是二分类的妙处它不是只分一次而是可以像决策树一样一直往下分每层只有一个判断大脑完全跟得上。3.2 需求评审是真需求还是伪需求只有两种情况不只对故障有用对要不要做某件事同样适用。我在评审需求时常用的一招是一个需求只有两种情况要么它解决了一个真实存在的痛点要么它只是看起来不错。怎么判断我自己的标准是两个验证动作。第一个动作问谁在用。这个功能上线后每天真正会用到它的人是谁如果回答是所有用户那基本等于没说如果是某类用户、某种场景这才有了验证的抓手。第二个动作问如果不做会怎样。注意不是做了有什么好处而是不做会损失什么。你会发现很多需求在第二个问题面前直接塌掉——不做也不会怎么样那就是伪需求至少不是当下必须做的需求。有一次某合作方提了个很花哨的报表功能说数据分析团队非常需要。我们把真伪需求这个二分法摆到桌面上后对方说真需求是真需求但要解决的是每周手动导数据太麻烦。于是我们没有做那个花哨的报表系统而是先做了一键导出加定时推送一个小功能一周上线痛点直接消掉了一半。这个案例想说明的是二分法不是让你拒绝需求而是帮你在失控之前把想要的东西和需要的东西分开。分开了优先级自然就清楚了。3.3 进度失控是能力问题还是承诺问题项目延期是每个带团队的人都会遇到的坎。以前我遇到延期第一反应是排期不合理然后把所有责任归到估算头上。后来我用二分法重新定义了一次延期思路完全打开了。一个任务延期只有两种情况执行者不具备完成它的能力或者执行者在承诺时就没有给出真实的完成时间。注意这两种情况的应对方式完全相反。能力问题要去补资源、换人、拆任务、给培训指望靠加加班解决是没有用的承诺问题要去解决沟通机制让估算不再变成一场讨价还价而是基于事实的推演。有一次项目里某位新同学连续两个迭代都延期每次都说是没想到这个细节这么麻烦。表面看是典型的估算不准但我用二分法一拆如果是能力问题他应该说不清楚技术难点在哪里如果是承诺问题他的问题清单应该能看出他在回复排期时犹豫过。我找他聊的时候没有直接问你能不能做而是让他现场讲述实现思路。聊了二十分钟发现他对核心模块的技术方案理解得其实很到位卡住他的是一些跨部门的数据权限沟通。于是结论就清楚了不是能力问题是他在承诺排期时没有把外部依赖的时间算进去。后来我们改了做法凡是涉及跨部门依赖的任务排期必须包含等对方响应的缓冲并在周会上同步依赖状态。此后再也没出现过这类延期。这就是二分法的价值——同样是延期两个字背后的药方完全不同分错了类怎么努力都是隔靴搔痒。4. 把复杂问题拆成两种情况的三个准则你可能已经发现了只有两种情况这个说法不新鲜新鲜的是怎么拆。拆得好问题迎刃而解拆得烂跟没拆一样甚至会误导你走弯路。我总结了三个准则基本可以覆盖大多数场景。4.1 互斥两种情况的边界必须清晰互斥的意思是一个具体的事实不能同时被归到两边。如果边界模糊验证动作就没法设计。反面案例是心态问题 vs 能力问题。你说一个员工总是拖延到底是态度不好还是没那个本事这两个东西可以同时成立也可以互相转化根本没法用一个测试动作把它们分开。这种二分就是伪二分。正面案例是前面说的能复现 vs 不能复现。一次报错要么能在受控环境里稳定复现要么不能不存在中间状态。这个边界清清楚楚验证动作也清清楚楚。所以拆的时候可以自问一句我能不能设计一个动作让结果的输出明确指向其中一边如果不能说明这条分界线画错了换一条。4.2 穷尽两种情况的并集必须覆盖所有可能很多人把二分法用砸是因为漏掉了第三种可能。比如排查性能问题有人习惯分成代码慢 vs 数据库慢但如果瓶颈在网络的传输链路上呢这就被漏掉了。穷尽不是要求你一开始就能列全所有可能性而是要求你划分的那条线像一张大网没有任何可能漏到网外。合理的做法是当你想出的两个分类有其他漏网之鱼时不是再加第三个分类那就不是二分了而是换一条线来切。比如代码慢 vs 数据库慢可以换成用户侧感知慢 vs 服务端处理慢因为任何一条链路要么发生在服务端处理范围之外网络、客户端渲染要么发生在服务端处理范围之内。这样划分穷尽性就够用了。记住一个原则如果有人说还有第三种情况通常不是情况多了而是你的那条分界线本身选得不够好。4.3 可证伪每种情况都要有一个明确的验证动作这是整个框架里最实用的一条每当你分完两类必须紧接着写出每个分类对应的验证动作写不出来说明你还没有真的理解这个问题。我自己的习惯是列一张两行的表情况验证动作判定标准代码问题在干净环境复现并抓取堆栈稳定复现堆栈指向业务代码环境问题对照变更记录、监控曲线、配置差异找到与故障时间点吻合的变更这张表填完排查就不再是大家一起看看而是变成流水线式的执行。谁去复现、谁去查变更分工自然就出来了。这也是为什么我说只有两种情况是一个团队工具而不只是个人思维——它让协作有了共同的坐标系。5. 这套思路的边界什么时候它真的会失效任何方法论都有边界只有两种情况也不例外。我自己就上过当差点把好工具用成坏借口。下面三种情形是我实际遇到过、也踩过坑的写出来帮你绕开。5.1 变量是连续的时候二分会失灵二分法适合离散状态的问题要么是、要么不是。但有些问题的变量是连续的比如性能优化。你说一个接口慢分代码问题 vs 环境问题然后呢代码问题里可能有一百个可以优化的点环境问题里也可能牵扯一连串参数调整。这种情况下二分只能帮你定位大方向不能帮你找到最优解。我碰过最典型的一次某个服务的响应时间从 200ms 涨到 800ms我们用二分法锁定了是代码问题但接下来的优化工作仍然是一大摊子事——数据库查询、对象序列化、线程池参数、缓存命中率哪个对性能的贡献都不小。这时候需要的是 profiling 数据用数字去排优先级而不是继续二选一。所以我会提醒自己二分法负责定性连续变量的环境里还要引入定量的梯度。先用二分把大方向收窄再用测量工具在收窄后的空间里做精细搜索。5.2 非此即彼的诱惑把两种变成偷懒的挡箭牌二分法最危险的用法是拿它当回避思考的借口。有些人拆出两种情况后只挑一边动手查查不通就赖在另一边甚至两边都不查直接说反正不是这个就是那个先猜一个吧。这完全背离了二分法的初衷。别忘了每一步验证动作才是核心。只有两种情况但两个都不验证等于没有分。我自己踩过的坑是有一次分出了代码问题 vs 部署问题我凭直觉认定是代码问题花了一整晚反复看代码结果第二天早上发现只是某个配置文件的缩进写错了属于部署那边的问题。那次之后我立了个规矩分完类先做成本最低的那个验证动作而不是先做自己偏好确信的那个。5.3 真正多头并发的故障场景别迷信一次二分到底有些故障是多个原因共同作用的结果比如磁盘 IO 高、业务量上涨、某段代码又正好有性能瓶颈三件事叠在一起才出事。这种情况下硬要分成两种情况往往会把多因叠加问题简化成单一原因问题导致你找到了一个原因就收工真正的隐患还埋在下面。我的应对方式是允许分叉。第一层二分之后两边都可能继续往下分叉于是这棵树会自然地长出多叉。关键是每一层、每一步仍然只做一个二选一的判断。二分的精髓从来不是这世界上只有两种原因而是每一步我只面对两个选项。头顶上有十个原因并不可怕可怕的是你在一个时间点同时要处理十个原因。打个比方排查问题像走迷宫你不需要一眼看到终点你只需要在每个转角做出一个二选一左还是右。多因叠加的故障也不例外只是转角更多而已。6. 最后的一点个人体会和一个小工具说回最开始的那个凌晨。后来我把只有两种情况变成了团队里一条不成文的规矩碰到任何棘手问题动手之前先在白板上写下两个分类和对应的验证动作。写不出来就继续想想出来再动手。就这么简单的一条规矩把我们开问题会的时长缩短了大概三分之一。我个人的体会是只有两种情况真正改变的不是排查速度而是你在失控感面前的心理状态。人一旦觉得问题无穷无尽第一反应是焦虑第二反应是乱试而一旦知道只有两种情况就算暂时还没验证出是哪一种心里也是踏实的——因为终点的轮廓已经能看到。最后分享一个我一直在用的小工具一张 A4 纸中间画一条竖线左边写情况 A右边写情况 B。每行对应一个验证动作做完就在那行后面打个勾。这张纸不用保留它的价值在写下来的瞬间就实现了——它逼着你的大脑从感觉哪里都有问题切换到我先排除哪一边。相信我下次你再遇到让人头大的问题花五分钟把这张纸画出来你会回来感谢这个方法。另外顺便多说一句这个思路不只适用于工作和故障。生活里那些让你纠结的选择其实也常常可以拆成两种情况。她到底是对我有意思还是只是礼貌这份工作到底是成长缓慢还是我自己心态出了问题——把模糊的焦虑翻译成具体的二选一往往答案就在验证动作里浮现出来了。
