Something is not working?——这句话我听到过无数次自己也说过无数次。它最大的杀伤力不在于问题本身难而在于提出问题的人不知道该如何描述问题接收问题的人也不知道该从哪里下手。作为一个常年和莫名其妙故障打交道的人我可以很直接地说大多数排查工作的第一步不是修东西而是先把这句含糊的话翻译成一个可以被定位、被验证、被解决的具体任务。这篇东西想聊的就是把Something is not working?变成我已经明确知道哪一环出了问题并且验证了修复方案的完整过程。不管你是做技术支持、写代码、管设备还是单纯想解决家里某个电器反复抽风的问题这套思路都适用。它不是某个特定领域的排错手册而是一套通用的排查方法论。1. 为什么Something is not working?是最难解决的问题1.1 这句话里几乎什么都不包含咱们把这句话拆开看。Something——某个对象没了。这个对象是硬件还是软件是本地设备还是远程服务是别人负责的模块还是自己手里的部分一律没说。is not working——不工作了怎么个不工作法完全没反应反应错误反应很慢间歇性抽风报错信息是什么什么都没有。?——提问的人自己也没头绪把问题直接抛了过来。一句话里三个部分全是空洞的但提问的人往往觉得自己已经把问题说清楚了。这种我以为我表达了但其实没有的信息断层是排查效率的最大杀手。我自己的经验是把这句话当作一个信号而不是一个任务。它真正想表达的是我遇到了一件和我预期不符的事但我不知道哪里不符、为什么不符你觉得该怎么办理解了这层意思你接下来的动作就不是埋头去查而是先补全信息。1.2 提问者为什么说不清楚人在遇到故障的时候大脑会自动进入一种应激模式。注意力全集中在坏了这个事实上反而忽略了坏之前发生了什么坏的现象具体是什么这些关键细节。这就像你看到家里水龙头漏水第一反应是叫人来修但被问到水是从哪里漏的、漏多大、什么时候开始的时反而支支吾吾答不上来。还有一个常见原因是提问者默认对方应该知道。说Something is not working的人心里可能默认接收方清楚他平时在用什么、项目背景是什么、哪些模块是关键路径。但事实是接收方可能连他说的something指什么都不知道。这就是为什么所有成熟的排查流程第一步永远是澄清问题而不是直接修。一个问不清楚的问题就算运气好修好了也只是碰巧修好的。下次换个场景故障换个形态你又得从头再来。2. 先建立一套排查的思维模型再动手2.1 复现一切排查的起点排查有一个黄金前提能稳定复现的问题已经解决了一半不能复现的问题解决全靠运气。原因很简单不能复现意味着你无法验证修复是否真的有效。你今天调整了一个参数看起来好了但如果不确定它是否真的解决了根因明天它可能换个时间又冒出来。所以拿到问题后的第一个动作不是猜原因而是想办法把问题复现出来。复现的过程中你会自然获得大量信息它是在什么操作之后出现的是每次都出现还是偶尔出现出现的频率有多高持续多久这些信息比Something is not working有价值一百倍。复现不了的场景也要按能复现的失效模式和不能复现的模糊描述分开记录因为二者的排查策略完全不同。前者可以做根因分析后者只能做预防性加固。2.2 二分法最朴素的收敛思路遇到一个复杂的、涉及环节很多的问题最怕的就是从头到尾一个一个看。比如一条数据从页面输入到数据库存储中间经过验证、序列化、网络传输、后端处理、SQL拼接、事务提交无数个环节。你如果从头查可能查了半天还没走到真正报错的那一环。这时候用二分法。先找到这条链路的中间点看这个位置的数据、状态是否符合预期。如果中间点正常问题在下半段如果不正常问题在上半段。然后继续在这个范围内取中点几次下来就能把范围缩到很小的区间再集中精力看这一段。这个方法在硬件排查里也极其有效。比如一条线路不通你对半分量中间点的通断判断是前段还是后段的问题。每一轮排查都能砍掉一半的怀疑范围效率非常高。2.3 假设必须验证不能靠我觉得有经验的工程师在下判断的时候反而更谨慎因为踩过的坑多了知道看起来是A的问题实际上是B的问题这种反转太常见了。排查时你可以大胆提出假设但每个假设都必须有一个验证动作。验证动作的设计原则是一次只改一个变量。如果你同时改了两三个配置而问题刚好解决了你永远无法确定是哪个改动真正起作用。这听着很简单但实际工作中很多人一着急就乱改一通结果问题消失了他都不知道自己怎么修好的。这种不知怎么修好和没修好一样危险——下次再坏你还是不会修。3. 从模糊描述到修复落地一套完整的排查流程3.1 信息收集阶段问对问题比答案更重要第一步不管对方给你的是Something is not working还是详细到带日志的报错描述你都把它当成初始描述系统地补全信息。我自己习惯固定问五个问题具体是什么东西不工作是功能、设备、代码还是服务尽量让对方给出名字或指代。不工作的具体表现是什么报错信息原文、界面截图、异常声音、指示灯状态能录屏就录屏能拍照就拍照。最后一次正常工作是什么时候这个问题最容易被忽略但极有价值。它会直接指向改变发生的时间点。在这之后发生了什么操作或变更装了什么新软件、更新了配置、换了环境、搬动了设备这些都可能导致故障。这个问题影响范围有多大只有一个人受影响还是所有人受影响一个功能坏了还是所有功能都坏了范围决定你的判断方向。问的时候注意方式不要审问式地一个接一个抛问题。对方如果说不清楚你可以引导你回忆一下今天上午用的时候还是好的下午就坏了这中间你做过什么不一样的操作吗这种问法能帮助对方回忆细节。3.2 假设优先级从概率最高、代价最低的开始试信息收集完你已经有了一个初步的怀疑区间。这时候不要直接上手改配置先列出所有可能的假设按两个维度排序发生的概率和验证的难易程度。优先验证高概率且容易验证的假设。举一个常见的例子用户说我的程序突然报数据库连不上了。可能的假设包括数据库服务挂了、连接串被改了、网络有问题、账号密码过期、防火墙规则变化。按概率和易验证程度排首先应该看数据库服务本身是否正常——一条命令就能确认而且概率不低。如果服务正常再看网络和账号。而不是一开始就去翻防火墙日志那玩意儿查起来费劲还不一定是根因。排序之后再动手这样就算你的假设被推翻也只是花了一点时间验证而已。怕就怕东一榔头西一棒子验证动作没有章法改来改去把环境搞得更乱。3.3 实施修复与回归验证没有验证等于没修找到根因之后修复动作本身要遵循最小变更原则——改最少的配置、动最少的东西来解决当前问题。改完之后做回归验证确认问题真的消失了同时确认没有引入新的问题。这里我强烈建议做一次复原测试。改完代码或配置后刻意把改动还原确认问题再次出现然后再把改动加上确认问题消失。这一套流程走下来才能确认你的改动和问题的因果关系是真实的。这看起来浪费时间但在复杂系统里非常值得因为很多修复只是碰巧绕过了故障并没有解决根因。3.4 复盘把经验变成可复用的资产修复完成不是终点记录才是。但大部分人恰恰跳过这一步导致同样的坑换个形式又来一遍。我的习惯是建立一个自己的故障笔记记三件事异常现象是什么根因是什么修复动作是什么。不用写长篇大论几行字加时间即可。积累到一定数量后你会发现大量故障有共性而你的排查速度会随着笔记的积累越来越快。4. 排查工具箱几种通用性极强的排错思路4.1 最后一次正常是什么时候——时间维度的排查前面提过这个问题这里展开说一下为什么这么好用。绝大多数故障不是凭空出现的而是某个变化触发的。你装上了一个新软件原来的功能不响应了你更新了系统版本老程序打不开了你把设备换了个位置信号变差了。最后一次正常这个时间点就是搜索因果关系的锚点。这个思维在生活场景里同样好用。家里的电视突然连不上网了回想一下上次看是什么时候这中间有人改过路由器密码吗路由器是不是重启过小米盒子是不是系统自动更新了几乎每次都能问出线索来。4.2 重启大法为什么有效状态清空的底层逻辑重启是技术圈最出名的土办法但很多人不知道它为什么有效。一个设备运行久了内部会积累各种临时状态缓存堆积、内存碎片、句柄泄漏、连接未正常关闭。这些状态会让系统慢慢偏离正常行为。重启的本质是清空所有内存态、重新加载初始配置让系统回到一个干净、确定的起点。理解这层原理之后你会发现重启不是玄学而是有用的诊断动作。如果重启之后问题消失但过段时间又回来说明系统里有什么东西在持续积累异常状态这就是你下一步排查的方向。所以我说重启不仅是一个修复手段更是一个诊断信号——它的疗效持续时间本身就在向你透露信息。4.3 换一个环境试试环境差异对比法如果一个东西在A环境不行但在B环境可以那问题大概率出在环境差异上。这是排查中最有力的排除法之一。比如同一份代码在你电脑上跑不起来但同事电脑上没问题别急着怪代码先对比两个环境系统版本、依赖版本、环境变量、端口占用、权限设置。差异点就是怀疑点。这个方法也适用于定位偶发性故障。如果问题只在特定时间、特定网络、特定账号下出现那说明触发条件和这些因素相关。你不需要知道完整的原因只需要把差异点逐个消除问题自然浮出水面。4.4 最小化试验把复杂系统简化到可解释遇到特别复杂的系统报错我习惯做一个最小化试验。把业务流程简化到最核心的一条路径砍掉所有非必要因素看看这条路径是否正常。这个过程有点像拆线团——先把最外面的缠绕理清一层一层剥到核心。举个例子页面提交报错你先别管前端校验、权限控制、消息队列这些周边逻辑直接用工具发起一个最原始的请求打给后端接口看返回什么。如果原始请求成功说明核心逻辑没问题问题在周边环节如果原始请求也失败你就拿到了更干净的报错信息排查方向立刻明确。5. 实战复盘三个Something is not working的完整处理过程5.1 场景一家里的打印机突然不工作了早上同事发消息说打印机不工作了没有任何报错指示灯也不正常。我没有直接跑到打印机旁边先问了一句昨天用的时候是好的吗中间有谁动过什么吗答案是昨天下午还挺好的昨晚好像有个同事在打印机附近搬过东西。到这里我大概有了方向很可能网线被碰松了或者电源线接触不良。到现场一看网线确实松松垮垮地搭在接口上重新插紧打印机恢复。整个过程一分钟不到。关键不是这一分钟而是前面那句引导性的提问帮我快速锁定了方向省去了逐个排查的十几分钟。这个案例的要点先问变了什么再查别的。大多数环境类故障都和变更有关。5.2 场景二网页打开特别慢网站打不开了转圈圈。这又是一个典型模糊描述。我先自己访问一下确实慢但能打开。再看网络面板发现是接口响应慢还是静态资源加载慢定位到是一个图片接口花了八秒才返回。接着追这个接口发现后端服务在等一个外部API返回而那个API最近改了地址旧地址超时重试了三次才失败。整个链路页面慢 → 接口慢 → 外部依赖慢 → 外部依赖地址变更未同步。如果直接从网站慢开始调优恐怕要白忙活半天。正确路径是逐层定位找到链条上最底层的那根稻草。这个案例的要点耐心沿着链路做二分定位而不是盯着表层现象做优化。做性能排查时尤其容易犯这个错——页面慢就开缓存、加带宽但根因可能只是某个外部接口超时。5.3 场景三家里的电视盒子每隔一段时间就断网朋友家电视盒子看视频总卡断断续续。他以为是网络不好准备换宽带。我让他观察一个细节是电视盒子一台设备断还是手机电脑也断他说只有电视盒子断。再问断开之后电视盒子能自动恢复吗他说过一会儿自己就好了。到这里基本可以判断问题大概率出在电视盒子自身的无线模块或电源管理上。智能设备为了省电空闲时会让无线网卡进入休眠模式唤醒时如果和路由器的协商出了问题就会出现看起来连着但实际断流的情况。让朋友把电视盒子的允许休眠或省电模式功能关掉问题彻底解决。这个案例的要点不要急着归咎于外部因素先确认影响边界。单设备故障和设备自身状态有关全设备故障才更可能是网络或服务端的问题。6. 排查中最容易踩的坑和这些年我的经验教训6.1 最贵的三个字我知道了排查时最怕的不是不知道而是假装知道。看到现象类似上次遇到过的某个案例就直接套用上次的方案。经验本身是好事但问题在于两个系统、两个场景之间的差异太多了表面相似背后往往暗藏不同的根因。更好的做法是保留经验给你的方向感但依然按照验证流程走一遍用最小的代价确认这个方向对不对。方向感验证才是经验正确的使用方式。只留方向、不做验证就是把经验变成了偏见。6.2 同时改多个变量是排查的大忌我见过不少同事在排查时一边改代码一边调配置一边重启服务。问题好了他归功于自己改的代码问题没好他也不知道是哪一步造成了新状况。排查的核心是控制变量——一次只改一个变量每一步都有明确的观察目标。如果确实需要改多个变量比如生产环境等不起那就采用改完后做整体回归但不把修复方案带进知识库的态度先临时恢复服务然后再在一个测试环境里一次一个变量地复现和定位把根因弄清楚。临时止血和真正治疗要分开做。6.3 不清除中间状态就会重复交学费每个排查过的问题都值得花三分钟记录一下。不用很复杂记下现象、根因、修复动作三个字段就行。积累到几百条之后你再看问题的方式会完全不一样——你会从这些记录里找到共性知道哪些环节容易出问题哪些操作是高危操作从而在将来提前规避。这个习惯的好处我以前低估了现在越来越觉得它重要。人脑的记忆是不可靠的尤其当问题已经过去半年、你被手上的新问题缠住时旧问题的解决方案根本不是你想调取就能调取的。但一份粗糙的笔记可以。笔记是第二大脑排查记录是个人知识库的地基。6.4 沟通方式决定了信息质量能不能从对方嘴里问出有价值的细节取决于你怎么提问。你当时做了什么这种开放问题对方往往回答没做什么啊。换成你打开这个页面之前是不是先登录了这种带选项的引导式提问对方的回忆就会被激活信息质量高得多。这背后其实是一个翻译的过程把技术排查的需要转化成对方能理解、能回答的人话。对方不是不配合而是不知道你脑子里需要什么信息。你问得越具体对方答得越准确。这不仅是技术问题更是沟通问题。写在最后的一些体会这些年处理过很多Something is not working式的求助我的体会有两个第一大多数莫名其妙的问题背后都有一个还没被发现的改变排查的核心是把这个改变找出来而不是在现象层面反复试错第二排查的效率不取决于你多聪明而取决于你的方法是否系统——信息收集是否完整、假设是否有序验证、变量是否受控。方法对了再复杂的故障也只是时间问题。最后分享一个我很喜欢的小技巧每次排查完问自己一句如果这个问题再发生一次我能多快解决它如果答案是不确定那就说明这次的排查过程里还有没搞清楚的东西值得回头补一补。每一次排查都可以比上一次更快前提是你愿意把每一次经历都变成可复用的经验。