标签：
故障树 调试 项目风险
昨天在avan的博客上看到了一幅硬盘读盘失败的故障树，由于我现在的工作与硬盘关系很大，今天早上又细看了一遍。这一看可不得了，引发我把最近的许多思考都联系了起来。本想回复在avan的博客上，可是越写篇幅越大，还是放到自家博客上来吧。
原图转载如下：
这幅图的意义不仅仅在于它提供的硬盘故障信息。
在硬件调试过程中，经常需要从故障现象反推回故障原理。在这样复杂的一个树根图上，从树根的底部可以一步到达树的主干；从树的主干想要到达树根底部可就难多了。从结果向原因逆向推导太难了。
与此相同的是小时候玩的纸面迷宫游戏，从入口走向出口难，不但容易走上岔路，还容易从另外的出口走出去；但是反过来从出口走向入口就容易多了，至少已经知道出口在哪里。 riple
另一个有相同现象的游戏是“扫雷”。最近LP大人很喜欢玩这个游戏，往往以能够通关为傲。我在一旁侧眼观瞧，发现确实有些门道：游戏设计者生成一幅雷区分布图很容易，这是正向设计；扫清雷场有时候就是逻辑推导不能胜任的，必须加上点猜测。一些决策分枝点很关键，也是决定输赢的转折点，在这些点上存在完全等价的多种可能。 riple
“扫雷”之所以难玩，也之所以好玩，就在于游戏设计者和游戏玩家的信息不对称。一幅地雷分布图设计出来，其周围的指示数字就唯一确定了，不会存在模棱两可的情况；但是在整个雷场灰蒙蒙一片的时候，玩家只有关于雷场局部情况的不完全信息，这些信息的价值也不完全相等，而且相互之间有一定的关联。即使玩家能够准确的评估这些信息的价值，并且建立这些信息之间的有效联系，在某些情况下仍然不能确定下一步的走向——由于缺少一个或几个关键信息，根据现有的信息会产生不唯一的决策。这时，没有别的办法，只能硬着头皮“踩”一下。 riple
与此相似，在获知cannot read data的信息时，如果不能获得区分cannot find data和data missing两种情况的一个或几个关键信息，就不能决定该向哪一条分枝走下去。 riple
我在硬件调试中经常会遇到这种情况，而且还会遇到更严重的情况：不仅不知道如何选择，甚至不知道有几个选项。这时候就必须通过证明或证伪的方法获得缺失的关键信息，从而决定该向决策分枝的哪一个支路走下去。证明，就是通过合理设置测试条件，通过有效的观察和分析，获得可靠的信息，推论出异常现象的直接原因，正向获取决策信息，从而判断应该选择哪一条支路；证伪，就是先假设一种可能分支，通过这个假设的分支进一步获取信息证明该假设是错误的，从而排除这一分支。证明和证伪的方法往往要交替使用，并且由于人的主观因素，经常会判断失误，经常要走回头路。如何获取信息，如何根据获取的信息作出正确的判断是调试成功的关键。反复实验，合理地增加和去除调试信息，反复分析实验结果，大胆假设，小心论证是成功调试的不二法门。 riple
进一步，一个产品的设计和工程项目的计划也有相似的情况。理想情况下，在项目立项之初，要把所有不确定的因素确定下来，也就是获得所有信息，这样才能保证项目目标的实现，包括产品的质量和项目的工期。获得的信息可以构成一幅导致项目失败或延期的“故障树”，在我们的文档里称之为“风险列表”。在立项评审时，只有风险定义明确并且解决措施完备的项目才能够通过评审。 riple
avan在日志里补充道：
嫦娥探月工程总指挥栾恩杰说：“分析故障产生的原因，每一个故障可能有几个原因，一层一层地画下去，就画出了‘故障树’。原来我提出的是出了问题要‘举一反三’，现在要求在设计的时候同时把可能出现的故障都找出来，回答出现这个故障怎么办。在设计的过程当中，就把可能出现的问题和我们将要采取的措施和办法做进去。”
多年来，在总结成功经验与失败教训的基础上，栾恩杰创造性地提出了“质量技术问题归零”的概念，并确立了五条判别标准：“定位准确，机理清楚，问题浮现，措施有效，举一反三。”组织制定了一整套具有开创性的航天工程管理与质量管理的新思路和新办法。
在我工作的单位，我们对于每一个项目都要进行预研、立项、概要设计、详细设计、调试、结项一系列的工作。这些天，我正在准备最近一个项目的结项工作。回顾这个项目的开发过程，虽然预研工作很充分，还预留了一定的调试时间，中间还有多个阶段提前完成，可是最后还是延期了。究其原因，是信息的缺失，包括开发者个人的知识储备，开发者个人认识、解决问题方法上的不足，以及对预期问题的缺乏准备和解决难度的低估，等等等等。总之一句话：风险失控。 riple
失控的原因就是立项时风险预期不充分，解决方法不完备，没能形成一棵健壮的“故障树”。 riple
往往在一个项目结项时，才能充分地认识到立项工作准备的不足。在立项之初，往往耐不住性子，不愿意多花时间在预期可能出现的问题（风险分析）上下功夫。 riple
缺乏耐心是一个因素，缺乏经验是另一个因素。现在看来，结项工作真的很重要，当前项目的结项，是为下一个项目的立项储备知识。像我这样缺乏项目开发经验的人，就是通过一次次结项工作，总结经验和教训才能成长起来的。总结经验，就是不断地完善“故障树”的分支，在立项前，心中有了一棵枝繁叶茂的“故障树”，才能做到胸有成竹始下笔。 riple
系统分类:
自由话题 | 用户分类:
有感而发 | 来源:
原创 | 【推荐给朋友】