我们一直有这样一个希望，希望我们身边的一切，比如汽车上的系统，家庭影院系统，电脑系统，亦或是 Linux 系统能永不出错的运转着。这个想法听起来很棒，生活里一般也正是如此。
事实上，你花钱买的也就是这种服务。另外，除了供应商，你还可以从各种各样的网站和论坛上获得帮助。你所在地区的 Linux 用户使用组和其他使用 Linux 的朋友，都会非常乐意为你提供援手。别犹豫，尽管充分利用这些资源吧！
其实在大多数时间里，我们当中的大多数 Linux 系统使用者更加喜欢自己检修、解决自己在使用系统过程中所遇到的问题。
我们不得不承认，无论是解决什么类型的问题都是一种艺术和技术。解决技术上的问题，诸如电脑故障之类的，就需要一系列的专业知识了。
但在我们实际解决问题的过程中，我们需要的绝不仅仅是一张写着问题和解决步骤的清单。这种只靠步骤清单来解决问题的办法，也就是我们俗称的“对症下药”。它来自于那些观念陈旧的管理者们(这些管理者大都缺乏基层实践)，它听起来很理想，但却经不起实践。那么，我们应该怎样正确的处理问题呢?
一、概要
下面是我用来解决Linux使用问题时的五个基本步骤：
1.储备知识
2.观察问题
3.推测原因
4.动手解决
5.测试效果
然而当你处理问题时，虽然你可能已经遵循了上述步骤，但是并没有真正意识到它。如果你每次忙着解决问题时都遵循这个流程，那想来大多数时候你都能成功解决问题。这些方法步骤是通用的、适用于解决绝大多数问题的，并不仅仅局限于解决Linux或电脑问题。
很多年来，我一直在使用这些方法步骤来解决电子和电脑方面的问题，却并没有意识到在使用它。当我被问题卡住，规范化解决问题的流程使得我更有效的解决遇到的问题。在处理问题的过程中，我会不断回顾已经经历过的步骤，判断自己处在哪一步。在确实需要的时候，我也会重复一个适当的步骤。
你可能已经在过去听说过一些其他的适用于解决问题的方法。这一过程的前三个步骤也被称为确定问题，即寻找问题的原因。最后的两个步骤是解决问题。
1.储备知识
在解决问题方面，拥有足够的知识是第一步。你必须至少了解Linux基本知识，甚至熟悉可能影响到Linux的领域，例如硬件、网络还有环境因素，如温度、湿度和Linux系统操作可能涉及的电气环境。
获得知识的途径有很多。你可以阅读相关的书籍和杂志，也可以参加课程、研讨会和其他会议。你也可以通过网络，与其他同样使用 Linux 的、知识渊博的人交流。
我个人倾向是“玩” Linux 。其实更加准确的说法是用Linux去实验操作，例如搭建网络方面，然后通过听课来理顺自己获得的经验和知识。
要记住，如果没有足够的知识，那么“抵抗是徒劳的”(这里借用博格人的名言)。知识就是力量。
2.观察问题
解决问题的第二步是观察问题的症状。重要的是注意到所有的问题特征。解决一个问题之前，观察有什么是正常工作的也是很重要的。
现在还不到动手解决问题的时候，你只需要观察问题。
观察的重要内容之一就是去问自己看到和看不到什么的问题。除了你要问自己的特殊问题，还有一些一般性的问题要问问自己：
◆造成这个问题的原因是硬件、Linux系统本身、应用软件或者是相关人员缺乏知识和培训所导致的误操作?
◆我以前遇到过这样的问题么?
◆有错误的提示么?
◆日志里有关于这个问题的记录么?
◆在错误发生之前，计算机的最后操作是什么?
◆当这个问题没有发生时，应该出现的正确结果是什么?
◆最近有关系统硬件和或软件的设置有被改变么?
这些问题将会在你努力寻找它们的答案的时候自己暴露出来。而对于你来说，更重要的是去收集尽可能多的信息。这将会增加你这类问题的了解和彻底解决这类问题的知识。
使用在线资源搜索类似的错误，也许有人已经报告了这个问题，并给出了解决方案。
当你收集数据的时候，永远不要假设从别人那里获得的数据是正确的。请注意观察你工作的一切细节。如果你正在和一个在远方的人一起工作，这可能会是一个主要的问题。这时，仔细询问变得至关重要。而当你试图确认自己给出的信息时，允许远程访问系统问题的工具非常有用。
当询问在远程站点的人时，永远不用问诱导性的问题。他们将尽全力帮助你，有问必答。
在其他时候，你得到的答案一般都取决于你问的那个人对 Linux 的了解程度和电脑知识水平。当一个人懂得或认为他知道关于电脑的知识，你得到的回答可能包含很难反驳的假设。相比于问一句“你检查过了么”，更好的做法是安排另外一个人来实际执行任务所需的检查。并且，相比于告诉一个人他/她应该看到什么结果，还不如简单的让用户解释和描述他/她看到的。再强调一次，对机器的远程访问可以让你确认自己给出的信息。
最好的问题解决者是那些从来不会理所当然的人。他们从来不会假定他们拥有的信息是100%正确和完整的。当你拥有的信息看起来自相矛盾时，如果你对此毫无办法那就重新来过吧。
3.推测原因
从你观察到的现状推断出可能导致问题的原因。
艺术在解决问题上也适用。根据你的知识和过去的经验观察问题就是一种演绎艺术，这有点神奇。伴随着科学方法，依靠产生的灵感、直觉、或神秘的心理过程，找到一些有助于查找问题根本原因的线索。
在某些情况下，这是一个相当简单的过程。比如你看到一个错误代码，并通过查找现有资料弄明白它的意思。然后，应用自己知道的大量知识推测问题的原因(这是解决问题过程中最为艺术的一步)。在某些情况下，这种推测可能很难作为问题测定过程的一部分。
这个推测的过程有助于记住问题特征而不是记住问题。问题产生了特征现象。但你想解决的是问题而不是问题特征。
4.动手解决
现在是时候来解决问题了。不要害怕，这通常是最简单的部分，最难的部分(分析如何解决问题)刚才已经过去了。在你知道问题的原因后，正确的修复一个问题是很容易的。
解决方案多种多样，可能需要更换硬件的驱动，或者是去更新一些软件程序。
对于一些有错误的软件，如果你或者你的组织没有足够的能力修复它，那至少你可以用适当的方法把错误报告给作者或其他组织。我曾经就用Bugzila给红帽公司报告了几个错误。任何人都可以创建自己Bugzila账号，并查找现有的错误或报告一个新的错误。
5.测试效果
采取了修复措施后就应该要进行测试了。通常意义上，这意味着要从任务失败的地方开始重新操作和重复实验。
如果修复措施没起作用，你应该从错误开始的地方再运行一遍程序试试。由于错误可能会因为你的修复操作而发生变化，所以你要意识到这一点，并对程序运行结果和问题特征进行记录，以便在下一次迭代修复时对解决方案作出相应的修改。这样做即使没能解决问题，问题特征的变化在后续的处理过程里也是很有参考价值的。
二、举个例子
这是一个几年前发生在我自己身上的案例。那时候，我曾经在一个实验室兼职做 Linux 系统管理员。这个问题相当简单，但足以说明我所概述的方法步骤。
我收到了一封来自我们测试员的电子邮件。邮件里说，他安装的一个用来测试的软件崩溃了。错误提示信息是系统交换空间不足(SWAP)。这是用户操作后给我的初步反馈和观察结果。
从我所知道来看，被用来测试应用程序的系统有高达 16GB 的内存和 2GB 的交换空间。而以往的使用经验也表明，这些计算机里的交换空间几乎用不到，它们的内存使用率也往往低于 25% 。
基于上述几点，我推断问题并非真的出在交换空间上，因为这几乎是不可能的。但我仍然保持对它的怀疑，即便这个可能性很小。其实，你也许也发现了许多程序提供的错误提示是有误导嫌疑的，自己观察的结果反而可以让你获得更多有用的信息。
我为测试人员提供了一些自己的意见。我登录到计算机中，用 free 命令来查看内存和交换空间使用情况。我发现大量的内存还空闲着，而且交换空间没有被动用。按照我所知道的，如果交换空间的实际使用率为零，那么也就是说开机以后很有可能从未分配可用交换空间，而且内存也没有分页。
以我以往的经验看，解决问题的关键就是错误信息提示。从提示来看，很像是程序想要向系统索取一些资源却没有成功。而对于计算机来说，其他可消耗的资源主要就是 CPU 和硬盘空间。
这并不像 CPU 的问题。所以我用 df 命令检查一下文件系统，发现 var 文件夹满了。我推断/var 空间全满是导致问题的原因。
我们的系统平常都是给 var 文件夹设置 1.5 GB 大小。通常情况下，我们是在 /opt 中安装应用程序。这也是我们测试的软件安装的地方。
我与测试人员探讨这个问题，他告诉我说他确实把应用程序安装在了 /var 目录。我告诉他要先从 /var 卸载安装的应用程序，并在 /opt 里重新安装。采取这一措施之后，我示意程序员进行测试，结果不出所料，问题被成功解决。
一般来说，你要想解决一个问题，至少需要重复一些步骤。比如说，如果执行给定的修复措施不能解决问题，你可能需要尝试另一种办法或者可能需要回到观察步骤并收集有关该问题的详细信息。
三、必要的过程分析
很多年来，我一直在教别人怎么修复硬件和软件的问题。我也一直在思考人们使用的解决问题的思路是否已经足够规范化。当我被教授了这种解决问题的方法步骤后，它使得我能够在努力解决问题时清楚的意识到自己处在哪一步。这让我能分析我在哪里出现错误，并重回正轨。
你解决问题的方法流程可能也不一样。也许你还没意识到你的思路是一个可描述性和可重复的过程。但是，如果你成功解决了电脑出现的问题，那你所采用的方法就是好方法。了解这个解决问题的方法流程，无论它是否适合你，未来都会有助于你解决遇到的问题。
作者：天寒
来源：51CTO