权威支持: 为有效进行产品故障诊断做好准备的 12 种方式

为实现更灵活的故障诊断进行仔细地准备

当讨论用于故障诊断和问题确定的技术和工具时，通常大多数的讨论都是关于发现问题之后所要进行的工作。然而，理想情况下，谨慎的系统管理员或者故障诊断者应该早在问题发生之前就开始思考这项工作；换句话说，将环境准备好，以便在问题最终出现时可以更快速并且更有效地执行故障诊断。

本文提出了十二项建议，您可以实现这些建议以帮助提高解决问题的速度，即使是在最复杂的生产环境中。这个建议列表，既不是权威性的、也不是绝对的，它基于对客户端环境的常规观测结果和 IBM WebSphere Support 所发现的问题。然而，每个环境都有其独特的因素和约束，而它们可能使得这些建议中的某些内容更加（或者更不）实际或者适用。在您对这些（以及其他）操作进行评估时，可以为您的环境构建一个自定义故障诊断计划，并使用这个列表作为您的起点。即使您不可能充分地实现这个列表中的每一条建议，但是您所采用的每个步骤仍然可以为您节约时间，并且行之有效：

1. 创建并维护系统体系结构图
2. 创建并跟踪所有问题确定构件的目录
3. 特别注意仅在问题出现时才生成的转储和其他构件
4. 查看并优化正常运行期间的诊断级别
5. 监视底层操作系统和网络度量
6. 准备好在出现问题的时候主动生成附加诊断信息
7. 定义诊断信息收集计划，并实施它
8. 建立基准
9. 周期性地清除、存档或者清理旧的日志和转储
10. 消除日志中虚假的错误和其他干扰信息
11. 保存更改日志
12. 为正在运行的系统设置运行状况监视

接下来的部分将详细地说明以上的每个步骤。

回页首

1. 创建并维护系统体系结构图

体系结构图显示了整体系统的所有主要组件（一些计算机和正在这些计算机中操作的软件组件），它们如何通信，以及系统中处理相关请求的主要流程。对于简化和加速许多与故障诊断相关的任务，使用一个好的、且最新的体系结构图是非常有帮助的。特别是，系统体系结构图可以帮助您：

• 确定在系统中寻找相关信息或者线索（关于导致问题发生的原因）的位置。
• 在您的组织内部以及在尝试向 IBM Support 说明复杂环境的时候，需要在故障诊断任务所涉及的各个部门之间进行清晰地交流。
• 回答并验证所有的故障诊断者都特别喜爱的一个问题：最近发生了什么更改？

体系结构图应该明确，并且足够简洁，以便人们能够快速理解。特别是，它应该尽可能地显示每个软件组件的实际当前版本，以及所有硬件组件的名称和地址。

回页首

2. 创建并跟踪所有问题确定构件的目录

故障诊断活动最初常常重点关注于寻找和检查各种问题确定构件（如日志文件、转储文件等文件），这些构件是在问题出现前或者出现时生成的。它需要提前知道要寻找哪些文件、它们位于何处，并要确保确实正确地生成了它们，并且在需要的时候它们将是可用的。

为您系统中所有重要问题确定构件建立目录：

• 说明每个文件用于什么情况、它的名称、位置、目的、典型内容及其大小。在这种情况下，使用系统体系结构图是非常方便的，因为它可以帮助您检查整个系统，以及可能产生有价值问题确定构件的所有组件。
• 不要仅满足于“知道”该构件的存在。尽管从理论上讲，可以对所有内容进行设置并进行记录，但是没有任何东西可以替代实际测试来验证该原则。周期性地检查此活动系统，以验证所有期望的日志文件和其他构件被照常写入。
• 确保有足够的磁盘空间（在适当的位置），以便继续写入所有相关的诊断文件，并接收在事故期间可能生成的任何其他文件。
• 请确保不要太快地清除您的构件。如果出现了事故，您可能需要回过头去查阅在检测到该事故之前的数小时内所生成的日志文件。特别是，请确保在事故后重新启动系统时，不会意外地删除或者覆盖这些文件。

回页首

3. 特别注意仅在问题出现时才生成的转储和其他构件

在查看问题确定构件的时候，人们常常更多关注于日志文件，这些日志文件通常是在系统的整个生命周期中不断生成的。请记住，还有许多非常有价值的问题确定构件，它们仅在问题出现的时候才生成，或者由系统自动生成，或者由管理员的某项特殊操作而生成。

在大多数情况下，提供了各种配置选项以控制如何以及何时生成这些构件：

• 对于在检测到问题的时候可以自动生成的任何文件：如果自动地产生这个文件，并且对配置进行相应地设置，那么请仔细考虑这项操作潜在的好处（和影响）。不要遗漏这个问题。如果潜在的好处很大，而影响很小，那么请确保启用这一功能。
• 对于可能由管理员的特定操作而生成的文件：通常在执行特定操作之前，该文件对系统只有很小的或者根本没有影响。如果可能，做好必要的准备和配置更改，以确保该操作在需要的时候是可用的，并进行测试以确保它能够按预期进行工作。

回页首

4. 查看并优化正常运行期间的诊断级别

有效的服务能力始终是一种折衷。一方面，为了尽最大可能在问题第一次出现时确定导致该问题的原因，您希望在任何时候都不断地收集系统的尽可能多的诊断数据。但是收集非常详细的诊断信息（例如，始终启用跟踪功能）可能导致性能开销的提高。因此，出于性能方面的原因，您可能希望在系统正常运行期间禁用所有诊断功能。您需要在这两个矛盾的目标之间找到适当的平衡。

在缺省情况下，大多数产品和环境往往因为过于保守（始终启用相对较小的诊断集）而出现错误。如果在系统投入运行之前，不需要任何人查看启用的诊断集，那么这就可能是一种正确的方法。然而，作为设计的主动故障诊断计划中的一部分，检查您的特定环境的特定约束、特定问题的可能性和特定性能需求是非常必要的，然后在正常的稳定状态期间启用尽可能多的附加诊断。

回页首

5. 监视底层操作系统和网络度量

在查找诊断信息的时候，通常倾向于重点关注日志、转储和其他与失败组件或者应用程序直接相关的文件，但是基础硬件、操作系统和网络通常也可以提供一些有价值的信息，用于跟踪问题的来源。

有些度量常常受到忽视，或者仅在复杂问题研究过程的后期才加以考虑，然而它们中的许多内容都比较简单、并且易于捕获。在某些非常困难的情况下，特别是与网络相关的问题，这些信息常常在跟踪问题来源的任务中扮演重要的角色。

当然，要永久性地监视每个单独的系统级度量并不实际，但是在可能的情况下，可以定期地对一个轻量级的系统级度量集进行监视，以便您能够在问题出现之前（捕获问题的发展）和问题出现时获得相关的数据。根据您的软件环境，您可能可以访问各种操作系统工具或者专用的系统管理工具（如 IBM Tivoli® 产品套装），以便对监视工作提供帮助。如果没有这些工具，那么您可以编写一些简单的命令脚本，以便周期性地运行和收集最有价值的统计信息。

回页首

6. 准备好在出现问题的时候主动地生成附加诊断信息

除了处理事故发生时所出现的诊断构件之外，您的故障诊断计划还应该考虑在数据消失或者重新启动系统之前需要执行的任何附加显式操作（一旦检测到事故，需要执行该操作以获取附加的信息）。

很明显，可能存在无数种这样的操作，并且您不可能执行所有的操作。相反，您必须尝试为系统预测最可能的故障模式，并决定在各种情况下，哪些操作最可能产生最有用的信息。对应用程序和系统体系结构进行仔细查看，这是一个重要信息来源，以便帮助您开始制定这样的计划，与 IBM Support 网站上的 MustGather 文档集一样。每个 MustGather 文档都适用于某一种特定的问题类型，并给出了在各种情况下需要收集的、推荐的诊断信息的明确指示。

回页首

7. 定义诊断信息收集计划，并实施它

假设您已经确定了可用于问题确定的关键诊断构件，并且已经确保这些构件是可用的、尽可能保证最好的质量，那么您还需要一个明确的、有良好文档记录的计划，以便在事故出现时实际地收集这些构件。当问题发生的时候，常常会出现混乱，以及将系统恢复到正常运行状态的巨大压力，从而产生各种错误，在故障诊断过程中导致不必要的延迟或者普遍的困难。制定一个操作计划，可以确保每个人都能够清楚具体的操作计划，并提前预演该计划的执行，这些都是非常关键的。

您的计划应该包含诊断构件的集合（它总是在问题发生时出现或者自动生成的），以及一组特定的操作（可以使用这些操作来生成附加的诊断信息，特别是在问题出现的时候），正如前面所建议的。

最简单的诊断收集计划可以采用简单的、手写文档的方式，该文档列出了必须采取的所有手工步骤的细节信息。要想更加有效，可以通过提供一个或者多个命令脚本（可以调用这些脚本以执行一组复杂的操作）、或者通过使用更完善的系统管理工具，尝试为这个计划中尽可能多的操作实现自动化。现在作为 IBM Support Assistant 的一部分提供了各种收集器工具和脚本，它们可以为您提供一个很好的框架，以便开始实现许多诊断收集任务的自动化。

回页首

8. 建立基准

“与昨天没有出现问题的时候相比，现在有什么不同呢？”

要帮助回答这个问题，您必须主动地收集并且维护一个基准：有关系统正常运行时的状态的广泛信息。

请记住，可能需要周期性地更新这个基准信息。因为系统在不断地发展、负载在不断地发生变化，所以什么是“正常”状态的代表，通常在一段时间内并非一成不变。同样，如果系统经历了不同的活动周期（例如，在特定的日期或者一天中的某个特定时段），那么对于每个时期，可能需要收集不同的基准。

回页首

9. 周期性地清除、存档或者清理旧的日志和转储

这个列表中的一些其他建议表明，生成尽可能多的不同类型的诊断构件，并且尽可能地详细。虽然这看起来是矛盾的，但是大量的信息并不总是好的。在某些环境中，允许日志文件无限制地增长，或者旧的日志和转储文件不断地堆积，经过数月甚至数年。事实上，这很可能会妨碍故障诊断的过程：

• 可能要花费大量宝贵的时间对许多旧的信息进行排序（手动进行排序，或者使用扫描所有文件的工具），以找到当前的信息。
• 对于收集和传输问题确定构件的工具，如收集脚本，如果它们必须传输大量的、不必要的旧信息，那么它们的运行可能会慢得多。如果对于每个新的事故，每次都要传输相同的旧信息，那么将会更加糟糕。
• 在极端的情况下，由于累积大量旧的构件，系统可能会用尽所有的磁盘空间。

您的主要目标应该是在问题发生前和发生时，收集尽可能多的诊断信息。您还希望保存或者存档足够多的历史诊断信息，以作为进行比较的基准，并且在万一没有立即检测到某个问题的情况下，用于观察某些问题的缓慢堆积。但是应该将这种历史数据与当前问题确定构件分开进行保存，这样它们就不会互相干扰。

各种 IBM 产品，如 WebSphere Application Server，提供了自动清除或者轮转某些日志文件的功能。对于其他的日志文件和转储，则必须定期手动地存档或者清除。

回页首

10. 消除日志中虚假的错误和其他干扰信息

在 IBM Support 中，有时我们会发现系统和应用程序运行于生成大量错误消息的模式中，甚至在正常运行期间也不例外。很明显，这种良性的、或者常见的错误并不是非常重要，但是它们使得要在所有这些干扰信息中发现不正常的错误变得更加困难。为了简化将来的故障诊断工作，可以排除所有这些常见的错误，或者寻找一种方式来标记它们，以便能够轻松地将它们与重要的错误区分开来。

回页首

11. 保存更改日志

正如前面多次提到的，对于大多数故障诊断实践，其中一个重要的方面是在正常工作的系统和存在问题的系统之间找出它们的不同之处，并且使用基准是帮助解决这个问题的一种方法。另一种可以帮助您确定系统差异的操作是，准确地保存一段时间内系统中所应用的所有更改的日志。当问题出现时，您可以通过日志查看可能引起该问题的任何近期的更改。您还可以将这些更改映射到过去收集的各种基准，以确定如何采用这些基准来解释相关的差异。

您的日志至少应该跟踪所有的升级和软件修复（应用于系统中的每个软件组件），包括基础结构产品和应用程序代码。它还应该跟踪任何组件中的每项配置更改。在理想的情况下，它还应该根据系统的使用情况，跟踪所有已知的更改；例如，负载方面预期的增长、用户调用的不同操作的混合、等等。

在复杂的 IT 环境中（许多团队服务于该环境中不同的部分），要维护一个精确的、最新的和全局的更改日志，这项任务可能是相当困难的。您可以使用各种工具和技术来帮助完成这项任务，从使用简单的数据收集脚本（类似于那些用于收集诊断数据的脚本）收集配置的常规快照，到使用复杂的系统管理实用工具。

请注意，更改控制的概念，以及保存更改日志，通常比故障诊断所涉及的领域更加广泛。它也被认为是用于管理复杂系统以防止各种问题（而不是对它们进行故障诊断）的重要的最佳实践之一。

回页首

12. 为正在运行的系统设置运行状况监视

在大多数实际情况下，可能导致更大问题的一些小问题或者较大的问题，可能潜伏很久都不会被发现。或者，系统的整体运行状况或者性能随着时间的推移可能会慢慢地下降，直到最后导致出现严重的问题。很显然，您越早检测到出错的地方，您将有越多的时间和机会来收集有价值的诊断信息，并将其用于故障诊断。因此，制定连续监测系统整体运行状况的良好策略，是整个故障诊断计划中一个重要的部分。这可能包括前面已经介绍过的诊断数据的大量相同来源，区别在于，在这种情况下，您不仅希望收集这些信息，还希望对其进行周期性地扫描，以确保不存在任何问题，而不是等待来自外部的问题报告。同样，简单的命令脚本或者复杂的系统管理工具（如果可用的话）都可以用于帮助实施这种监视。

回页首

结束语

要在复杂的环境中正确地对问题进行故障诊断，您需要考虑许多因素和观点，并且对于不同的特定情况，具体的内容也不相同。我们希望，这个列表说明了准备工作将会带来回报，并为您开始定义自己的自定义故障诊断计划提供基础。