您是否曾经遇到过这样的技术资源(程序员或工程师)，他们坦率地承认自己不擅长排除故障?我怀疑不是。然而，与沃比根湖的孩子们不同的是，我们并不都在平均水平之上，高估自己的能力是人类的一种自然倾向。
事前的尽职调查可以将未来的问题最小化。我们相信，丰富的设计和测试减少了对故障排除的需要，但生命、系统和机器都不是总是可预测的。我不确定我们中有多少人会教授故障排除的最佳实践。
故障排除中的一个基本规则是划分问题 - 如果可能。我还会提交系统性也是基石。我看到非常聪明，非常聪明的工程师绕过一个务实的方法来通过直接到问题区域来试图快速解决问题来进行故障排除。我还看到那些个人挖掘更深层次的洞，他们需要通过回溯来消除自己。
系统越复杂(包括大小，这本身就会带来复杂性)，在进行故障排除时就必须更加努力。首先开发一个文档化的测试记录。确定您想要测试什么以及您希望能够从该测试中学到什么。测试的预期结果是什么?如果你有一个团队，就下一步达成一致。描述测试，记录预期的结果，也记录实际的结果(列和行可以很好地做到这一点)。
观察实际结果并进行评估。您不必总是得到预期的结果，但重要的是评估您看到的测试结果。即使你让问题变得更糟而不是更好，你至少知道你在问题的神经中枢附近。我曾经有一个非常聪明的同事，他在故障排除方面是我见过的最好的。我们当时正在启动一个联合循环电站，记得他说:“我不在乎我认为我刚刚看到了什么。物理定律还是一样的!”这里的教训是，花点时间来确定你认为你看到的是否真的有意义。你能否通过其他途径证明或反驳这个观察结果，或者在不危险的情况下复制这个结果?
寻找明显的问题，如输入错误或重复的地址稍后会在程序中被重写，或者可能是代码中的操作顺序问题。它是否与时间有关——使用时间关系来推进逻辑而不是事件关系的结果?
文档跟踪似乎是一种形式，它引入了不必要的延迟，但没有记录的更改被遗忘和留下，可能会增加诊断的时间，甚至几天。如果安装了物理或软件跳线，一定要记录相应的文件，以便确保可以删除它们。此外，让团队使用这样一个正式的文档(如果有团队的话)将团队以一种协同的方式聚集在一起，而不是让多个贡献者作为一个松散的英雄集合，这实际上会使问题复杂化。
另一个重要规则是一次只实施一个变化。当您已经有所行为的东西时，您不想在测试之前引入多个变量，因为那么您不会真正知道如何解释结果。在通过系统方法采取下一步之前，请务必了解改变的影响。
当故障排除,移动与紧迫性,但不要急！
雷·贝勒斯是学士控制公司的认证会员控制系统集成商协会（CSIA）。有关学士控件的更多信息，请访问其配置文件工业自动化交换。
