故障诊断是一种系统性的问题解决方法。其目标在于确定某些部件未按预期工作的原因以及如何解决问题。
故障诊断过程的第一步是对问题进行完整描述。如果没有问题描述，无论是您或 IBM® 都无法得知从哪里开始查找问题的原因。此步骤包括您自问一些基本问题，例如：
- 问题的症状是什么？
- 问题发生在什么位置？
- 问题发生在什么时候？
- 问题在哪些条件下发生？
- 是否能够再现问题？
这些提问的答案通常会产生有用的问题描述，这会是循序渐进解决问题的最佳方法。
问题的症状是什么？
开始描述此问题时，最明显的问题是“这是什么问题？”这似乎是一个简单明了的提问；但是，您可以将其分为若干更有侧重点的提问，分解后的提问可以产生问题的描述性图像。这些提问可以包括：
- 谁（或者哪个对象）报告了此问题？
- 错误代码和消息是什么？
- 系统发生故障的情况如何？例如，系统是否循环、暂挂、锁定、性能降级或产生错误的结果？
- 问题的业务影响是什么？
问题发生在什么位置？
确定问题源自何处并非总是很简单，但却是解决问题时其中一个最重要的步骤。在报告组件和故障组件之间可能存在许多技术层。当调查问题时，网络、磁盘和驱动程序只是要考虑的少数组件而已。
以下提问可以帮助您集中在问题的发生位置，以便您隔离问题层。
- 该问题是否特定于一个平台或操作系统，还是对于多个平台或操作系统都很常见。
- 是否支持当前环境和配置？
切记，如果如果有一层报告此问题，该问题不一定源自该层。确定问题起源的位置在于了解其存在的环境。请花费些时间来完整的描述问题环境，包括操作系统和版本，所有对应的软件和版本以及硬件信息。请确认是否在受支持配置的环境中运行；很多问题可以追溯至软件级别不兼容：这些软件不能一起运行或尚未经过完整测试。
问题发生在什么时候？
制定引至故障的事件的详细时间线，特别是针对那些一次性发生的情况。逆向作业是执行此操作的最简单方式：从报告错误的时间开始（尽可能确切，甚至精确到毫秒），并通过可用的日志和信息进行逆向作业。通常，您只需要查看在诊断日志中发现的第一个怀疑事件；但是，执行此操作不一定简单，这需要练习。
如果涉及到多个拓扑层，并且每个拓扑层都有其自身的诊断信息，那么确定何时停止查看尤其困难。
要制定详细的事件时间线，请回答以下提问：
- 该问题只在白天或晚上的特定时间发生吗？
- 该问题多久发生一次？
- 哪种事件顺序导致报告此问题的时间？
- 该问题是在环境更改后（如升级或安装软件和硬件）后发生的吗？
以上类型提问的回应可以为您提供参考框架，可在根据框架调查此问题。
问题在哪些条件下发生？
知道问题发生时其他什么系统和应用程序正在运行是故障诊断的一个重要部分。
有关环境的这些及其他提问可帮助确定问题的根本原因：
- 这些问题总是在执行同一任务时出现吗？
- 需要发生特定顺序的事件才能出现此问题吗？
- 与此同时是否有其他应用程序失败？
回答以上类型的问题可帮助您说明问题发生的环境，以及与所有依赖项进行关联。
切记，只是因为多个问题可能在大约同一时间发生，这些问题不一定相关。
是否能够再现问题？
从故障诊断角度来看，“理想”问题是会再现的一种问题。
通常，如果问题能够再现，那么您可以有更多的一系列工具或过程来供支配，以帮助进行调查。因此，可以再现的问题通常比较容易调试和解决。不过，能够再现的问题可能有一个缺点：如果问题具有重大业务影响，那么您可能不希望将其重现！
如有可能，请在测试或开发环境中重现问题，此类环境通常会在调查期间提供更多灵活性和控制。
提示： 简化此场景以将问题隔离到怀疑的组件上。
以下提问可帮助您再现此问题：
- 能在测试机上再现此问题吗？
- 是否有多个用户或应用程序遇到此相同类型的问题？
- 可以通过运行单个命令、一组命令、特定应用程序或独立应用程序来重现此问题吗？