PD(problem detection 经验谈--摘自走入小型IBM世界）

PD,Problems Determination

故障判断 PD是工程师经常用到的名词，意思为故障判断，当问题发生时，通过一些方法研究故障的根本原因(root cause)，另一个与之具有同样含义的名词是Troubleshooting。当系统比较简单，问题很明显的时候，不需要什么技巧，而当我们面对一个小型机系统时，组件众多，关系复杂，就必须专门的PD技巧才能快速定位故障。完成的故障判断过程如下:

1）明确故障现象最重要又是最难实现的一步，我们往往以为问题现象都很清楚了，实际上却不是这样。简单的一句话“某台机器无法访问”，与真正明确这个故障现象相距何止千里！你说这句话如同医生说“我病了”一样正确但无用。这里面有很多经验和技巧，无法用简单的语言说明，通过一个例子你或许可以理解期间技巧。

 

没经验的小J：“我连不上服务器！”

资深的老S：“从一台PC机（地址是****)，通过telnet协议访问服务器（地址是xxxx)无法连通，telnet之后就停止在等待状态只到超时，与我同网段的其他机器可以正常连通；这台PC机访问其他服务器也正常，而且昨天也可以访问此服务器，并且在这段时间没有人对系统的软件、硬件、网络等做非例行操作........"

 

 

从以上的说明故障现象的方式你就会发现，老S已经把问题描述得非常清楚，甚至感觉把可能的故障原因都进行了判断，并由故障现象说明中已经否决了一些可能的原因。对问题描述确实需要长期的经验积累，尽管有经验积可谈，PD的能力仍然不是“教”得会的，需要自己“学”明白。前辈留下来的名言是："故障诊断与性能优化“都是一门艺术，而不是技术。

 

另一条重要的经验是实话实说，不要隐瞒，特别是对自己已经不记得的事情，不要"猜想"自己当初是如何操作的，而要实话实说，告诉专家：我忘记了！这可以大大缩短问题解决的时间，防止造成别人的困惑，毕竟你需要最终解决问题，而不是把专家难住。

 

 经常遇到一些年轻的工程师操作动作快，命令不熟练，有时由于自己的错误造成了一些后果，然后自己再试图用自己的方式去修正错误，而怕由于被别人知道丢了工作或受到批评，当然，这种自我保护的心里无可厚非，但是如果从解决问题和避免损失的角度，首先不要再重要系统上去执行自己不熟练（不确知结果，而仅仅是试探性的）命令；其次，要检查系统环境是否正常，有时前一个人做了错误动作，但并没有生效，等你进行操作，重新启动了计算机，结果生效，你却只能一脸茫然的说："不是我干的！不关我的事，我什么都没有做！"。所以包含在进行重要工作之前先重启动计算机，以确认都完好是非常重要的经验：再次，操作不要过快，应看看结果是否正确再执行下一步操作，还要多注意你操作前后，系统是否有硬件、软件故障信息；最后，一旦发生了问题，要及早找技术专家解决，而不是自己去有病乱吃药，甚至掩盖"犯罪现场". 如果你怕被领导批评，可以找技术专家，而不是自己的领导，让它们帮你去判断结构，推荐解决方案。

 

 2)了解系统架构和操作过程细节 你当然可以在不了解系统架构和操作细节的情况下对系统进行故障分析，这种分析叫做“黑箱分析”，是更复杂的分析手段，通常用于探索未知领域（例如产品开发），却不适合在工程领域进行故障诊断。因为工程领域的技术、产品都是已经经过验证的，一定是什么地方与原来正确的环境不一样，才会出现错误，理论上如果能将系统完全（所有的组件，甚至包括UPS/电缆等）更换为另一套系统，访问用户的操作恢复为昨天的情况（当然不太可能），则系统一定会正常。所以了解系统架构和过程细节既是可能的，又是必要的，你可以依次检查那一部分“被更改”或与原来"不一样"。 这个时候你不能相信任何人的话，对每个人说的话，都要对照你的拓扑图进行考察，可能他并没有骗你，但系统发生了许多他不知道的事情 ---网线被插到交换机的另一个端口、系统夜晚进行了软件升级等，这些都可能会导致同样的故障现象。反之，同一故障原因在不同的时间，又可能表现出截然不同的状况。 另一方面，有了架构图，就可以知道哪些地方出问题会对系统造成影响，导致什么结果。如果问题很复杂，经过一段时间分析后仍没有头绪，则不要先假设什么地方没问题，而是要假设所有的地方都有问题，然后一步步确认此组件没有问题。例如如果服务器无法通过telnet登录，那么可以查看其他的rlogin，ftp等类似的服务是否正常，这样去验证服务器、网络、服务程序自身是否正常。

 

3）定位问题（再现）和测试

不要急于动手更改任何硬件、软件，先要看和想。如果问题复杂，你的操作会“破坏犯罪现场”，对今后定位故障制造难度。有很多时候，故障是偶发的（持续发生的故障一般都比较容易判断、定位），你的操作会产生“故障循环"，你不知道由于操作使问题解决（或导致新的故障现象)，还是这个时候一些偶发性故障没有发生。（例如接触不良） 只有做好了充分准备之后，才动手设计一些方案去验证故障和试探修复。每次只进行一个（或者一类，但千万不能多）变更。然后等故障再现，如果问题依旧，记得要恢复原状之后再进行下一次实验验证。如果你没能恢复原状，那么结果往往是问题莫名其妙地产生，莫名奇妙解决（其实你并没有解决它），过了一段时间，你可能已经淡忘此事后，故障又毫无征兆地冒出来。最后一定要记得验证确实是这个问题，因为很多故障都是由接触不良引起的，你可能更换其他部件的时候恰好碰到了故障点（你并不知道），结果好像更换了这个设备，故障被解决了，可是不久之后，故障又出现。定位、判断故障的方法有很多种，常用的技巧如下:

 极小配置法：就是将设备拆成可工作的最小配置，由于工程系统一定是由于什么东西不对才引起问题的，因此如果拆除的组件中恰好包含了故障组件，则系统就可以正常运转，之后我们再把被拆除的组件一个一个还原归位，最后一个导致问题的组件可能就是故障点。

好部件替换法：如果猜想问题的来源是某个组件，那么可以用同类型部件替换掉这个组件，如果问题解决，那么被替换的就可能是故障点。

坏部件替换法：如同好部件替换法一样，可以将怀疑有故障的部件安装到好设备上（或回复回原来系统）查看故障是否再现（要注意如果是电器故障，不建议这样测试，有可能导致损坏好设备）。前面已经说过，有时你的操作会以你预料不到的方式影响故障点，而且有可能临时掩盖故障现象，如果不进行坏部件替换，就不能确定问题所在。

槽位更换法：在AIX中有很强的故障定位能力，通常可以定位到故障点，但是有一些故障属于两个设备之间的配合问题，例如插板和插槽之间的虚连接，这就很难确定到底是哪个设备出现问题，还是两者都出现问题。因此可以根据故障提示，更换故障相关两个设备的相互位置，等待故障再现，比对故障现象和故障点。如故障点是否移位，如果移位，再看移位的位置与两个设备中的哪个设备相关。

 

 

 4)越离奇的故障,原因越简单

这是被作者本人和其他工程师千百次诊断结果验证的真理，没有那么复杂的原因，可能只是一根线接触不良，运行一段时间后温度过高，没有接SCSI电缆终结器，甚至是光盘坏了！