对问题进行故障诊断

故障诊断是解决问题的一种系统方法。故障诊断的目标是确定无法按照预期进行工作的原因,并阐述如何解决问题。

故障诊断过程的第一步是完整地描述问题。问题描述可帮助您和“HCL® 技术支持”人员了解要从哪里开始查找导致问题的原因。此步骤包含问一些需要“问自己”的基本问题:

  • 问题的症状是什么?
  • 问题在哪里发生?
  • 问题何时发生?
  • 问题发生的条件是什么?
  • 问题能否再现?

对这些疑问的回答常常就可以很好地描述问题,这也是走向问题解决之路的最佳方式。

问题的症状是什么?

开始描述问题时,最显然的疑问是“问题是什么?” 这看起来是很浅显的疑问;不过,您可以将它分解成多个针对性更强的疑问,以便更好地描述问题。这些疑问可能包括:

  • 谁或什么报告了问题?
  • 错误代码和消息是什么?
  • 系统出现了怎样的故障?例如,它是陷入循环、挂起、崩溃、性能下降还是结果不正确?
  • 问题会对业务产生什么影响?

问题发生在哪儿?

确定问题来源并非总是很容易,但是这是解决问题最重要的一步。报告组件和故障组件之间可能存在许多技术层。调查问题时,网络、磁盘和驱动程序只是要注意的一小部分组件。

以下提问可帮助您关注问题发生在何处,以便隔离问题层:

  • 该问题是特定于某个平台或操作系统,还是普遍存在于多个平台或操作系统?
  • 是否支持当前环境和配置?

请记住,虽然一个层报告问题,但问题并不一定发源于该层。识别问题发源地的一部分工作是了解问题所在的环境。花一些时间完整描述问题环境,包括操作系统和版本、所有相应软件和版本以及硬件信息。确认运行所在的环境具有受支持的配置;许多问题的原因可追溯到不兼容的软件级别,即这些软件级别并不用于一起运行或尚未一起经过全面测试。

问题何时发生?

详细绘制引起失败的各个事件的时间线,尤其对于那些只发生一次的情况。可通过反向工作来最方便地做到这一点:在报告错误时(尽可能精确,甚至直到毫秒)启动并通过可用的日志和信息反向工作。通常,您只需要看到在诊断日志中找到的第一个可疑事件;不过,这并非总是能够轻松做到的,需要在实践中提高。当涉及多个技术层,并且每一个都有自己的诊断信息时,特别难以知道应该在什么时候停止寻找。

要制定详细的事件时间线,请回答以下问题:

  • 问题是否仅在白天或晚上的特定时间发生?
  • 问题发生的频率如何?
  • 什么顺序的一系列事件导致报告问题?
  • 问题是否在环境更改(如升级或安装软件/硬件)后发生?

回应此类疑问可帮助向您提供调查问题时的参考框架。

问题发生的条件是什么?

了解问题发生时哪些系统和应用程序正在运行是故障诊断的一个重要部分。以下有关您环境的提问可帮助您确定问题的根本原因:

  • 此问题总是在执行同一任务时发生吗?
  • 是否需要发生特定顺序的一系列事件,问题才会出现?
  • 是否有其他应用程序同时也发生故障?

回答这些类型的问题可以帮助您说明问题发生时所处的环境并找出所有依赖关系。请记住,虽然多个问题可能同时发生,但这些问题不一定都有关联。

问题是否能重现?

从故障诊断角度来讲,理想的问题是可再现的问题。通常,对于可以再现的问题,有大量的工具或过程可供您选择用来帮助进行调查。因而,可以再现的问题常常更容易调试并解决。但是,会重复出现的问题可能具有以下缺点:如果此问题会严重影响业务,那么您会不希望它重现。如有可能,请在测试或开发环境中重现问题,此类环境通常会在调查期间提供更多灵活性和控制。

  • 可在测试系统上重现问题吗?
  • 是否有多个用户或应用程序遇到相同类型的问题?
  • 问题是否可以通过运行单个命令、一组命令或特定的应用程序或单机应用程序来再现?