前几天出差，周末的时候我在酒店看书，总能听到屋里传来一阵阵的、轻微的电锯声，严重干扰了我的看书过程。
于是，我打电话给酒店前台，说：“我现在住的房间里总能听到一阵电锯声，是酒店在装修吗？”
前台回道：“没有啊，先生。今天没有装修，倒是有两个师傅过来修电梯。”
我说：“他们修电梯我是知道的，而且我也去他们的维修现场看了，根本没有声音。他们也没有带任何电锯类的工具。”
前台道：“好的，先生，我们马上上楼为您排查。”
后来真的过来一个服务人员敲门。
我打开门后，她笑道：“先生，我们核查了一遍，可能是到了周末，酒店要统一消毒，您听到的声音有可能是消毒水碰到底板或门上的声音。请问现在还有声音吗？”
我仔细听了一下，果然没有声音了，于是道：“现在没有了，感谢。”
服务员就回去了，我顺势关上门打算继续看书。
不料往书桌前一坐，那个可恶的声音又出现了，真是搞得我哭笑不得。
此时，我不得不自己排故了！
1）问题描述：在屋里看书，传来电锯一般的声响。
2）原因排查：为什么服务员来了之后，噪声中断了一段时间？这期间发生了什么事情，是和服务员来之前不一样的？哦，只有一样，那就是门开了，我是打开门和她说话的。
3）故障复现：关上门后，噪声再次出现。
4）机理分析：为什么关上门就有噪声，不关门就没有？我突然意识到今天风刮的很大，直对着门的那扇窗口是打开的，风从窗户灌进来，吹到门缝里，形成了声响，很像电锯声。如果机理正确，那么我关上窗口，噪声一定可以消除。
5）解决措施及验证：关闭窗户，噪音彻底消除，我终于可以安心看书了。
我讲这么一个故事，主要是想阐述我在工程实际中是如何排故的，大体分为七步。
这一步非常关键，因为从发现问题的CS（客服人员）到解决问题的技术人员之间，关于故障信息的描述可能已经变化了N次，或许早已经面目全非。
因此，我一般都要求CS在发现问题后，如果有条件，要尽可能地录像。
如果不具备条件，也应该把看到的故障尽可能详细地描述出来，而且要用写下来，以防遗忘。
如果现场有两位以上的CS发现了故障，那么他们对问题的描述一定要清晰一致，不能自相矛盾。
这么多年的排故经验告诉我，得到一个会描述问题的CS，非常不容易。
我发布的文章也不算少了，时常会有一些朋友问我问题，他们的问题描述效果，差别真的很大。
有的朋友不仅提供了模型，还录像、拍照，而且把自己尝试过的排故项都罗列了出来，最终询问这究竟是怎么回事。
有的朋友语言表达能力很强，描述的很详细，人家提供过来的问题描述，字数可达500多字。
对于这样的问题，我非常乐于参与讨论，因为我可以根据他们精彩的描述，形成自己对问题的理解，进而做到有的放矢。
然而，有的朋友描述得就很简单，只有一句话，比如：
“请问，我的网格为什么划不过去？”（恕我无能为力）
“请问，我的软件怎么老报错？”（我也不知道啊）
“请问，我应该用什么类型的网格？”（您分析的是静力学、动力学还是热学？）
......
关于这件事情，我后来想明白了。
我以前在学校，如果遇到问题，总会直接问教研室的师兄：“师兄，我的网格划不过去了，不知道怎么回事。”
这个时候，师兄就会和我一起来到我的座位上，对着模型逐一排错。
那些只问一句话的朋友可能也是这样的惯性思维，不同的是，师兄可以非常方便地直接过来当面处理，而我却无法抵达您的身旁。
你可能发现，我在排查酒店噪声时，问题描述也是一句话，这不是打脸吗？
但你要知道，我既是问题发现者，又是问题排查和解决者，又不需要写报告，所以就随意一些。
其实就是把可能引起这个问题的原因全部罗列出来。
关键就在于“全部”二字，你必须有系统思维和全局思维，不能仅仅依托自己的猜测，就进行下一步。
这是什么意思呢？
不知道大家知不知道，飞机在起飞之前，地勤人员和飞行员都会有一个清单，上面逐一写了要检查的项目，不管有没有问题，距离上一次检查的时间有多短，都要过一遍的。
一个排故老手也应该有这么一个清单，列出涉及到你设计的东西的所有可能因素，如光学、结构、工艺、电气、控制、软件、电路、算法、操作失误等等。
这里举一个反例。
有一次我在做实验的时候，突然发现使用的电路板模拟信号消失了。
按照上述思维，我就应该对照着我的清单逐一排查，即便明显不是清单上的某个原因，也要像例行公事一样过一下。但是我没有，而是想当然地认为硬件电路有问题。
于是，我和同事以及供应商讨论到半夜，也没得出什么结果，最终的决定是返厂维修，因为我非常肯定地认为电路坏了，需要他们换器件。
结果第二天正要寄快递的时候，供应商反馈说，这个板子中间升了一次软件，但版本搞错了，模拟量无法正常输出。
我一听又喜又悔。
喜的是，可以节省很多时间来继续实验。
悔的是，凭什么我就认为一定是硬件的问题？经验主义害死人啊，如果能够例行公事地过一遍故障清单，昨晚就不用那么折腾了。
这里需要说明的是，即便你每次都能做到把故障树中的所有原因都分析一下，跟你配合的人也未必愿意。
比如上述这个例子，如果我说：“有可能是软件问题，你们问问。”
跟我对接的人很可能会说：“不可能是软件问题，别浪费时间了。”
我可能会追问：“你先别觉得不可能，问问呗。”
他可能又会说：“真的没用，别折腾了！”
这时，我一般会发怒了，道：“你连问都没问，怎么知道不是？”
这种合作人员有很多的，需要我们妥善处理关系。
当故障树列的比较全面时，接下来就需要采用控制变量法逐一排查各个因素了。
运气好的话，你可能很快就会定位出原因所在。
运气不好的话，也就是多折腾会儿。
控制变量法是排除杂项的利器。
关键是，当我们找到问题的原因时，如何解决呢？
那就要用到对比法了。
所谓对比法，就是设法找到“从来没有发生过故障、但是却和发生故障的对象A很相似的”对象B，看看对象B的什么地方和对象A不一样，然后把对象A也往这个方向更改。
对比法和控制变量法在很多时候是互为依托的。
我们可能用控制变量法找到了故障原因，用对比法找到了解决方案，但这还不够。
你必须从机理上分析故障的底层逻辑。
一旦这个逻辑被你捕捉到，你就可以将之推广到很多别的项目上。
现象千奇百怪，解决措施也并不唯一，但底层机理一般是具有唯一性的。
换句话说，当这个机理作用时，故障一定会发生。
这还不够！
当这个机理不作用（采用了解决措施）时，故障一定不会发生。
我之前一直在思考：“到底是先有理论，还是先有实践？”
后来我发现，是先有实践。
只有不断地实践，才能抽象出理论，进而指导更多的实践。
没有实践，没有现象，纯靠想象推出理论，这是不可想象的，像牛顿、爱因斯坦这样的天才，也无法做到。
如果你掌握了故障原因，正确地分析了故障机理，那么故障复现就是必然的。
有的时候，故障机理是我们之前从来没有遇到过的，或者压根儿就想不到的，这就会造成一种尴尬的局面，那就是故障树里的所有原因都排查了一遍，但是都不对路。
因此，故障复现不仅是验证机理分析是否正确的准则，更是发掘之前未掌握的机理的捷径。
说过了，理论都是通过实践、通过现象，抽象出来的。
一旦故障复现，得出新的机理，那么（通过对比法）找到解决措施，都是顺带手的事情。
当然，发掘未知机理，是需要一点想象力的。
你可以提出任何看似愚蠢的原因，但你不能不提，因为不提就意味着思维僵化，意味着自我限制。
这一步很简单，但却是说服客户的最直接的环节。
当客户看到加上更改措施后的产品非常顺畅地运行时，他们自然不会太关心你是怎么排查的。
这一项并不属于排故的标准流程，但它应该穿插在上述的各个环节之中。
第一，对排故本身而言，你需要与前辈们沟通。
有很多问题，前辈们已经知道大概率是什么原因了，你就可以把他们的成果直接拿来应用。
不行了，再用全局思维逐一过故障树。
如果你不发问，闷头苦干，很可能只是把前辈们走过的路重复走一遍，没什么意义。
第二，从办事儿的角度来说，你需要正确地、阶段性地向你的领导汇报。
如果你认为你有能力，思路也对，解决办法也有效，事情就可以办好，那你就错了。
你必须让领导明确地知道你的意图，搞清楚整件事情的来龙去脉，不然你很可能还是会被批评。因为你的汇报不具有连续性，讲的故事不够好，会被认为是在瞎搞。
实际上，领导那么忙，他们也不会过于关注细节，要的是你有个汇报和沟通的态度。
不然，有朝一日他们被更大的领导问起来，却发现自己对这个事情一无所知，那就尴尬了。
因此，善于汇报（注意，不是时时汇报），打通整件事情涉及到的人事关系，非常重要。
