虽然我们都希望汽车、家庭影院系统、电脑和 Linux 永远不会出现故障，但现实是它们确实会发生故障。
许多人使用 Linux 时没有问题，但遇到问题的人希望获得尽可能最佳的信息和指导。您可以从许多地方获得专业帮助。例如，如果您从 Red Hat 等主要供应商处购买了 Linux，您有权获得该供应商提供的某种程度的服务。事实上，您实际购买的是服务。其他帮助可以在互联网上的各种网站和论坛上找到。您所在地区也可能有本地用户组，甚至您可能有一些使用 Linux 的朋友愿意伸出援手。请随时使用您可以使用的任何和所有资源。
大多数时候，我们这些使用 Linux 的人更喜欢——甚至享受——自己进行故障排除。
解决任何类型的问题都是一门艺术和一门科学。解决技术问题，例如计算机出现的问题，也需要大量的专业知识。
任何解决任何性质问题的 approach——包括计算机和 Linux 的问题——都必须包含的不仅仅是症状列表以及修复或规避导致症状的问题所必需的步骤。这种所谓的“症状-修复”方法在纸面上看起来对老派管理者（那些不参与 开放组织 的管理者）来说不错，但在实践中却很糟糕。
KnOWDAT
我使用的解决问题过程涉及五个基本步骤
- 知识
- 观察
- 推断
- 行动
- 测试
当您排除故障时，您可能已经在遵循这些步骤，甚至没有意识到。如果您每次在解决问题时都遵循这些步骤，那么您应该在大多数情况下都取得成功。这些步骤是通用的，适用于解决大多数类型的问题，而不仅仅是计算机或 Linux 的问题。
多年来，我一直在使用这些步骤解决电子和计算机问题，而没有意识到。为我整理这些步骤使我更有效地解决问题，因为当我遇到困难时，我可以回顾我采取的步骤，验证我在流程中的位置，并在必要时从适当的步骤重新开始。
您可能在过去听说过其他一些用于解决问题的术语。此过程的前三个步骤也称为问题确定，即找到问题的原因。最后两个步骤是问题解决，即实际修复问题。
知识
对您尝试解决的问题的主题的知识是第一步。您必须至少对 Linux 有所了解，甚至更好的是，您必须了解可能与 Linux 交互并影响 Linux 的其他因素，例如硬件、网络，甚至环境因素，例如温度、湿度和 Linux 系统运行所在的电气环境如何影响它。
知识可以通过阅读有关 Linux 和其他主题的书籍和杂志来获得。您可以参加课程、研讨会和会议。您还可以只在网络环境中设置多台 Linux 计算机，并通过与其他知识渊博的人互动来获得知识。
我个人的偏好是玩——呃，实验——Linux 或某个特定部分，例如网络，然后再参加一两门课程来规范我获得的知识。
请记住，如果没有知识，“抵抗是徒劳的”，套用 Borg 的话。知识就是力量。
观察
解决问题的第二步是观察问题的症状。重要的是记下所有问题症状。观察哪些工作正常也很重要。
现在不是尝试修复问题的时候；仅仅是观察。
观察的一个重要部分是问自己关于您看到和未看到的内容的问题。除了您需要提出的特定于问题的问题之外，还有一些一般性问题要问
- 此问题是由硬件、Linux、应用软件引起的，还是由于用户缺乏知识或培训引起的？
- 此问题是否与我见过的其他问题类似？
- 是否有错误消息？
- 是否有与问题相关的日志条目？
- 错误发生前计算机上正在发生什么？
- 如果错误没有发生，我期望发生什么？
- 系统硬件或软件最近是否发生过任何更改？
当您努力回答这些问题时，其他问题会自行显现。这里要记住的重要事项是尽可能多地收集信息。这增加了您对这个特定问题的了解，并有助于找到根本原因。
使用在线资源搜索类似的错误。也许这个问题已经被报告，并且有修复程序。
当您收集数据时，永远不要假设从其他人那里获得的信息是正确的。亲自观察一切。如果您与位于远程位置的人员合作，这可能是一个主要问题。仔细提问至关重要，并且允许远程访问有问题的系统的工具在尝试确认您获得的信息时非常有帮助。
当询问远程站点的人员时，永远不要问诱导性问题；他们会尽力通过回答他们认为你想听到的内容来提供帮助。
在其他时候，您收到的答案将取决于该人对 Linux 和计算机的了解程度。当一个人了解——或认为他了解——计算机时，您收到的答案可能包含难以反驳的假设。与其问“您检查过...吗？”，不如让对方实际执行检查该项目所需的任务。与其告诉对方他或她应该看到什么，不如让用户向您解释或描述他或她看到的内容。同样，远程访问机器可以让您确认您获得的信息。
最好的问题解决者是那些从不认为任何事情是理所当然的人。他们从不假设他们拥有的信息是 100% 准确或完整的。当您拥有的信息似乎与自身或症状相矛盾时，请从头开始，就好像您根本没有信息一样。
推断
从您对症状的观察中推断问题可能是什么。
这就是艺术应用于解决问题的地方。从您对问题的观察以及您的知识和过去的经验中进行推断的艺术，是艺术，也许还有一点魔法，与科学相结合，产生灵感、直觉或其他神秘的心理过程，从而为问题的根本原因提供一些线索。
在某些情况下，这是一个相当简单的过程。您可以看到错误代码，并从您可以获得的来源中查找其含义。然后，您可以应用您掌握的丰富知识来推断——艺术的部分——问题的原因。在其他情况下，这可能是问题确定过程中非常困难的部分。
记住症状不是问题。问题导致症状。您想要修复真正的问题，而不仅仅是症状。
行动
现在是执行适当的修复操作的时候了。这通常是简单的部分。困难的部分是之前的步骤——弄清楚要做什么。在您知道问题的原因后，很容易确定要采取的正确修复操作。
这可能是更换有缺陷的硬盘驱动器或主板，或者可能需要升级甚至修复某些软件。
对于有错误的软件，如果您没有自己或在您的组织内修复它的技能，您至少应该做的是使用适当的方法报告该错误。我使用 Bugzilla 向 Red Hat 报告了一些错误。任何人都可以创建一个 Bugzilla 帐户并搜索现有的类似错误或报告新错误。
测试
在采取一些明显的修复措施后，应测试修复措施。这通常意味着执行最初失败的任务或一些练习损坏位的内容。
如果修复操作不成功，您应该重新开始该过程，从观察到的症状开始。由于您已采取的措施，症状可能已更改，您需要意识到这一点，以便在过程的下一次迭代中做出明智的决定。即使问题尚未解决，改变的症状也可能对确定如何进行非常有价值。
一个例子
几年前，在我担任测试实验室环境中的兼职 Linux 系统管理员期间，发生了一个解决问题的例子。它相当简单，但可以说明我概述的步骤的过程流程。
我收到我们的一位测试人员发来的电子邮件，指示他作为测试的一部分安装的应用程序崩溃了。它给出的错误消息表明它已用完交换空间。这是用户执行并传输给我的初始观察。
我的知识告诉我，用于测试此应用程序的系统具有 16GB 的 RAM 和 2GB 的交换空间。以前的经验（知识）告诉我，这些计算机中的交换空间几乎从未使用过，RAM 使用率通常远低于这些机器中 16GB RAM 的 25%。
此时，我推断问题实际上不是交换空间问题，因为这似乎极不可能。不过，我仍然可以保持这种可能性，尽管可能性很小。您会发现程序提供的许多错误消息可能非常具有误导性，用户的观察结果可能更是如此。
我自己做了一些观察。我登录到机器并使用 free 命令作为查看内存和交换空间的工具。大量可用 RAM，交换空间使用率为零。我知道，如果交换空间使用率实际上为零，那么很可能自上次启动以来从未分配过任何可用交换空间，也没有发生过分页。
我还从以前的经验（知识）中推断，错误消息中可能包含一些事实。也就是说，它很可能耗尽了某种资源或其他资源。其他主要可消耗的资源是 CPU 周期和磁盘空间。
这似乎不是 CPU 问题，所以我使用 df 命令观察磁盘空间，结果显示 /var 文件系统已满。我推断文件系统已满是问题的原因。
我们所有的系统都使用 kickstart 启动，/var 文件系统为 1.5GB。我们的政策是将应用程序安装在 /opt 中，而我们测试的应用程序正是设计为安装在此处的。
我与测试人员讨论了这个问题，他告诉我他确实将应用程序安装在 /var 中。我告诉他从 /var 卸载并在 /opt 中安装应用程序，这才是它所属的位置。在采取此行动后，我让他通过执行先前失败的操作来测试更正后的应用程序。测试成功，问题解决。
当您解决问题时，有必要循环回到至少某些步骤。例如，如果执行给定的纠正措施没有解决问题，您可能需要尝试另一个措施，或者您可能需要回到观察步骤并收集有关问题的更多信息。
分析您的流程
多年来，我一直在教人们修理硬件和软件。我认为我们许多人都使用某种形式的问题解决过程，无论它是否已经形式化。当我被教授有关此过程时，它使我能够了解当我努力解决问题时，它在何时何地对我来说会崩溃。这使我能够分析我在哪里出错并回到正轨。
您的流程可能不同，您可能没有意识到您实际上有一个可描述和可重复的流程。但是，如果您成功解决了计算机问题，那么您就有。了解该过程，无论对您而言是什么，都可以帮助您解决未来的问题。
1 条评论