Linux问题的故障排除过程

尽管很高兴相信汽车，家庭影院系统，计算机和Linux永远不会崩溃，但实际情况是它们确实存在。

许多人对Linux没有任何问题，但是确实希望获得最佳信息和指导的人。 您可以从许多地方获得专业帮助。 例如，如果您从Red Hat等主要供应商购买了Linux，则您有权从该供应商处获得某种级别的服务。 实际上，您实际购买的是服务。 Internet上的各种网站和论坛都提供了其他帮助。 您的地理区域中也可能有本地用户组，​​您甚至可能有一些使用Linux并愿意提供帮助的朋友。 不要犹豫，使用任何可用的资源。

在大多数情况下，我们中使用Linux的人更喜欢甚至喜欢做我们自己的故障排除。

解决任何类型的问题都是一门艺术和一门科学。 解决诸如计算机中出现的技术问题也需要大量专门知识。

解决任何性质的问题的任何方法（包括计算机和Linux的问题）都不仅应包括症状列表以及修复或规避引起症状的问题所必需的步骤。 这种所谓的“症状修复”方法对老式经理（那些不参加开放组织的经理）在纸面上看起来不错，但实际上很糟糕。

诺达

我使用的问题解决过程涉及五个基本步骤：

1. 知识
2. 观察
3. 扣除
4. 行动
5. 测试中

解决问题时，您可能已经按照这些步骤进行操作，但甚至没有意识到。 如果每次解决问题时都遵循这些步骤，那么大多数时候您应该会成功。 这些步骤是通用的，适用于解决大多数类型的问题，而不仅仅是计算机或Linux的问题。

多年来，我一直使用这些步骤来解决电子和计算机问题，而没有意识到。 让他们为我编纂代码使我在解决问题上更加有效，因为当我陷入困境时，我可以查看我已采取的步骤，验证我在流程中的位置，并在必要时从适当的步骤重新开始。

在过去，您可能还听说过其他一些用于解决问题的术语。 此过程的前三个步骤也称为问题确定，即查找问题的原因。 最后两个步骤是解决问题，实际上是在解决问题。

知识

第一步是要了解您要解决问题的主题。 您至少必须至少了解Linux，甚至更好，您必须了解可以与Linux交互并影响Linux的其他因素，例如硬件，网络，甚至环境因素，例如温度，湿度和温度。 Linux系统在其中运行的电气环境会对其产生影响。

可以通过阅读有关Linux和其他主题的书籍和杂志来获得知识。 您可以参加课程，研讨会和会议。 您也可以在网络环境中并通过与其他知识渊博的人进行交互来设置多台Linux计算机。

我个人的喜好是-尝试使用Linux或网络之类的特定作品，然后参加一两堂课来正式化我所获得的知识。

请记住，博格用一句话来形容“没有抵抗力是徒劳的”。 知识就是力量。

观察

解决问题的第二步是观察问题的症状。 重要的是要注意所有问题的症状。 观察什么工作正常也很重要。

现在不是尝试解决该问题的时间。 只是观察。

观察的重要部分是问自己有关所见和未见的问题。 除了您需要提出的特定于问题的问题之外，还有一些一般性问题要问：

• 这个问题是由硬件，Linux，应用软件还是缺乏用户知识或培训引起的？
• 这个问题和我见过的其他问题类似吗？
• 是否有错误消息？
• 是否有与该问题有关的日志条目？
• 错误发生之前计算机上正在发生什么？
• 如果未发生错误，我期望发生什么？
• 最近有关系统硬件或软件的任何更改吗？

在您回答这些问题时，其他问题也会显示出来。 这里要记住的重要事情是收集尽可能多的信息。 这可以增加您对特定问题的了解，并有助于找到根本原因。

使用在线资源搜索类似的错误。 可能已经报告了此问题，并且已对此进行了修复。

收集数据时，切勿假设从他人那里获得的信息是正确的。 自己观察一切。 如果您正在与远程人员一起工作，这可能是一个主要问题。 仔细询问是必不可少的，并且在尝试确认所给信息时，允许远程访问所涉及系统的工具非常有用。

向远程站点的人提问时，切勿提出引导性问题。 他们将通过回答您认为想听的内容来帮助您。

在其他时候，您收到的答案将取决于该人对Linux和计算机的总体了解程度。 当一个人知道（或认为他知道）关于计算机时，您收到的答案可能包含难以证明的假设。 最好不要让其他人实际执行检查项目所需的任务，而要问“您检查了吗……”。 与其告诉别人他或她应该看到的内容，不如让用户向您解释或描述他或她看到的内容。 同样，对机器的远程访问可以让您确认所提供的信息。

最好的问题解决者是那些从来不认为任何事情都是理所当然的人。 他们从不认为自己拥有的信息是100％准确或完整的。 当您所拥有的信息似乎与自身或症状矛盾时，请从头开始，好像您根本没有信息一样。

扣除

从对症状的观察中推断出可能是问题所在。

这就是艺术应用于解决问题的地方。 从您对问题的观察以及您的知识和过去的经验中推论得出的艺术是将艺术（也许还有一点魔术）与科学相结合，以产生灵感，直觉或其他一些神秘的心理过程，从而为根本原因提供一些线索问题。

在某些情况下，这是一个相当简单的过程。 您可以查看错误代码，并从可用的来源中查找其含义。 然后，您可以运用大量的知识来推断出问题的成因（巧妙的部分）。 在其他情况下，这可能是问题确定过程中非常困难的部分。

记住症状不是问题，这会有所帮助。 问题导致症状。 您不仅要解决症状，还要解决真正的问题。

行动

现在是执行适当的修复操作的时候了。 这通常是简单的部分。 困难的部分是之前发生的事情-找出要做什么。 在知道问题的原因之后，很容易确定要采取的正确维修措施。

这可能是更换有故障的硬盘驱动器或主板，或者可能有必要升级甚至修复某些软件。

对于存在错误的软件，如果您不具备自己或在组织内部进行修复的技能，则最不应该做的就是使用适当的方法报告错误。 我已经使用Bugzilla向Red Hat报告了一些错误。 任何人都可以创建一个Bugzilla帐户并搜索现有的类似错误或报告新错误。

测试

在采取一些明显的维修措施后，应对维修进行测试。 这通常意味着首先执行失败的任务或执行折断的位。

如果修复操作未成功，则应从观察到的症状重新开始操作。 由于您已采取的措施，它们可能已更改，您需要意识到这一点，以便在流程的下一次迭代中做出明智的决策。 即使问题没有得到解决，症状的改变对于决定如何进行也可能非常有价值。

一个例子

根据我自己的经验解决问题的一个例子发生在几年前，当时我在测试实验室环境中担任兼职Linux系统管理员。 这很简单，但是可以说明我概述的步骤的流程。

我收到一位测试人员发送的电子邮件，表明他在测试中安装的应用程序崩溃了。 它发出错误消息，表明它已超出交换空间。 这是用户执行并发送给我的初始观察结果 。

我的知识告诉我，用于测试此应用程序的系统具有16GB的RAM和2GB的交换空间。 以前的经验（知识）告诉我，这些计算机中的交换空间几乎从未被触及过，RAM使用率通常远远低于这些设备中16GB RAM的25％。

在这一点上，我推断问题实际上并不是交换空间的问题，因为这似乎是不可能的。 我仍然可以保持这种可能性，尽管只是非常轻微。 您会发现程序提供的许多错误消息可能会引起误解，而用户的观察甚至会更加令人误解。

我自己做了一些观察。 我登录到该框，并使用free命令作为查看内存和交换空间的工具。 很多可用RAM和交换空间使用为零。 我知道，如果交换空间使用量实际上为零，那么很可能从未分配任何可用的交换空间，并且自上次引导以来未发生任何调页。

我还从以前的经验（知识）中推论出，该错误消息中可能存在真相。 那样的话，很可能会耗尽一些资源或其他资源。 其他主要的消耗性资源是CPU周期和磁盘空间。

这似乎不是CPU问题，所以我使用df命令观察了磁盘空间，该命令表明/ var文件系统已满。 我推断出整个文件系统是问题的原因。

我们所有的系统都以1.5GB的/ var文件系统启动。 我们的政策是在/ opt中安装应用程序，这是我们要测试的程序的安装位置。

我与测试人员讨论了这个问题，并被告知他确实已经在/ var中安装了该应用程序。 我告诉他从/ var卸载并在/ opt所属的位置安装该应用程序。 采取此操作后 ，我让他通过执行先前失败的操作来测试纠正性应用程序。 测试成功，问题解决了。

解决问题时，有必要至少回溯一些步骤。 例如，如果执行给定的纠正措施不能解决问题，则可能需要尝试其他措施，或者可能需要返回观察步骤并收集有关问题的更多信息。

分析你的过程

多年来，我一直在教人们修复硬件和软件。 我认为我们中的许多人都使用某种形式的问题解决过程，无论该过程是否已正式化。 当我被告知有关此过程的信息时，它使我能够了解在解决问题的过程中它在何时何地发生了故障。 这使我能够分析出哪里出了问题，并重回正轨。

您的过程可能有所不同，并且您可能没有意识到您实际上有一个可描述和可重复的过程。 但是，如果您成功解决了计算机问题，则可以。 意识到该过程，无论对您有多大的帮助，都可以帮助您解决将来的问题。

翻译自: https://opensource.com/business/15/10/troubleshooting-process-linux-problems