发表于
2007-12-7 9:56:37
昨天在avan的博客上看到了一幅硬盘读盘失败的故障树，由于我现在的工作与硬盘关系很大，今天早上又细看了一遍。这一看可不得了，引发我把最近的许多思考都联系了起来。本想回复在avan的博客上，可是越写篇幅越大，还是放到自家博客上来吧。
原图转载如下：
这幅图的意义不仅仅在于它提供的硬盘故障信息。
在硬件调试过程中，经常需要从故障现象反推回故障原理。在这样复杂的一个树根图上，从树根的底部可以一步到达树的主干；从树的主干想要到达树根底部可就难多了。从结果向原因逆向推导太难了。
与此相同的是小时候玩的纸面迷宫游戏，从入口走向出口难，不但容易走上岔路，还容易从另外的出口走出去；但是反过来从出口走向入口就容易多了，至少已经知道出口在哪里。 riple
另一个有相同现象的游戏是“扫雷”。最近LP大人很喜欢玩这个游戏，往往以能够通关为傲。我在一旁侧眼观瞧，发现确实有些门道：游戏设计者生成一幅雷区分布图很容易，这是正向设计；扫清雷场有时候就是逻辑推导不能胜任的，必须加上点猜测。一些决策分枝点很关键，也是决定输赢的转折点，在这些点上存在完全等价的多种可能。 riple
“扫雷”之所以难玩，也之所以好玩，就在于游戏设计者和游戏玩家的信息不对称。一幅地雷分布图设计出来，其周围的指示数字就唯一确定了，不会存在模棱两可的情况；但是在整个雷场灰蒙蒙一片的时候，玩家只有关于雷场局部情况的不完全信息，这些信息的价值也不完全相等，而且相互之间有一定的关联。即使玩家能够准确的评估这些信息的价值，并且建立这些信息之间的有效联系，在某些情况下仍然不能确定下一步的走向——由于缺少一个或几个关键信息，根据现有的信息会产生不唯一的决策。这时，没有别的办法，只能硬着头皮“踩”一下。 riple
与此相似，在获知cannot read data的信息时，如果不能获得区分cannot find data和data missing两种情况的一个或几个关键信息，就不能决定该向哪一条分枝走下去。 riple
我在硬件调试中经常会遇到这种情况，而且还会遇到更严重的情况：不仅不知道如何选择，甚至不知道有几个选项。这时候就必须通过证明或证伪的方法获得缺失的关键信息，从而决定该向决策分枝的哪一个支路走下去。证明，就是通过合理设置测试条件，通过有效的观察和分析，获得可靠的信息，推论出异常现象的直接原因，正向获取决策信息，从而判断应该选择哪一条支路；证伪，就是先假设一种可能分支，通过这个假设的分支进一步获取信息证明该假设是错误的，从而排除这一分支。证明和证伪的方法往往要交替使用，并且由于人的主观因素，经常会判断失误，经常要走回头路。如何获取信息，如何根据获取的信息作出正确的判断是调试成功的关键。反复实验，合理地增加和去除调试信息，反复分析实验结果，大胆假设，小心论证是成功调试的不二法门。 riple
进一步，一个产品的设计和工程项目的计划也有相似的情况。理想情况下，在项目立项之初，要把所有不确定的因素确定下来，也就是获得所有信息，这样才能保证项目目标的实现，包括产品的质量和项目的工期。获得的信息可以构成一幅导致项目失败或延期的“故障树”，在我们的文档里称之为“风险列表”。在立项评审时，只有风险定义明确并且解决措施完备的项目才能够通过评审。 riple </