教你處理Linux系統問題的五個步驟
我們一直有這樣一個希望,希望我們身邊的一切,比如汽車上的系統,家庭影院系統,電腦系統,亦或是 Linux 系統能永不出錯的運轉著。這個想法聽起來很棒,生活里一般也正是如此。
事實上,你花錢買的也就是這種服務。另外,除了供應商,你還可以從各種各樣的網站和論壇上獲得幫助。你所在地區的 Linux 用戶使用組和其他使用 Linux 的朋友,都會非常樂意為你提供援手。別猶豫,盡管充分利用這些資源吧!
其實在大多數時間里,我們當中的大多數 Linux 系統使用者更加喜歡自己檢修、解決自己在使用系統過程中所遇到的問題。
我們不得不承認,無論是解決什么類型的問題都是一種藝術和技術。解決技術上的問題,諸如電腦故障之類的,就需要一系列的專業知識了。
但在我們實際解決問題的過程中,我們需要的絕不僅僅是一張寫著問題和解決步驟的清單。這種只靠步驟清單來解決問題的辦法,也就是我們俗稱的“對癥下藥”。它來自于那些觀念陳舊的管理者們(這些管理者大都缺乏基層實踐),它聽起來很理想,但卻經不起實踐。那么,我們應該怎樣正確的處理問題呢?
一、概要
下面是我用來解決Linux使用問題時的五個基本步驟:
1.儲備知識
2.觀察問題
3.推測原因
4.動手解決
5.測試效果
然而當你處理問題時,雖然你可能已經遵循了上述步驟,但是并沒有真正意識到它。如果你每次忙著解決問題時都遵循這個流程,那想來大多數時候你都能成功解決問題。這些方法步驟是通用的、適用于解決絕大多數問題的,并不僅僅局限于解決Linux或電腦問題。
很多年來,我一直在使用這些方法步驟來解決電子和電腦方面的問題,卻并沒有意識到在使用它。當我被問題卡住,規范化解決問題的流程使得我更有效的解決遇到的問題。在處理問題的過程中,我會不斷回顧已經經歷過的步驟,判斷自己處在哪一步。在確實需要的時候,我也會重復一個適當的步驟。
你可能已經在過去聽說過一些其他的適用于解決問題的方法。這一過程的前三個步驟也被稱為確定問題,即尋找問題的原因。***的兩個步驟是解決問題。
1.儲備知識
在解決問題方面,擁有足夠的知識是***步。你必須至少了解Linux基本知識,甚至熟悉可能影響到Linux的領域,例如硬件、網絡還有環境因素,如溫度、濕度和Linux系統操作可能涉及的電氣環境。
獲得知識的途徑有很多。你可以閱讀相關的書籍和雜志,也可以參加課程、研討會和其他會議。你也可以通過網絡,與其他同樣使用 Linux 的、知識淵博的人交流。
我個人傾向是“玩” Linux 。其實更加準確的說法是用Linux去實驗操作,例如搭建網絡方面,然后通過聽課來理順自己獲得的經驗和知識。
要記住,如果沒有足夠的知識,那么“抵抗是徒勞的”(這里借用博格人的名言)。知識就是力量。
2.觀察問題
解決問題的第二步是觀察問題的癥狀。重要的是注意到所有的問題特征。解決一個問題之前,觀察有什么是正常工作的也是很重要的。
現在還不到動手解決問題的時候,你只需要觀察問題。
觀察的重要內容之一就是去問自己看到和看不到什么的問題。除了你要問自己的特殊問題,還有一些一般性的問題要問問自己:
◆造成這個問題的原因是硬件、Linux系統本身、應用軟件或者是相關人員缺乏知識和培訓所導致的誤操作?
◆我以前遇到過這樣的問題么?
◆有錯誤的提示么?
◆日志里有關于這個問題的記錄么?
◆在錯誤發生之前,計算機的***操作是什么?
◆當這個問題沒有發生時,應該出現的正確結果是什么?
◆最近有關系統硬件和或軟件的設置有被改變么?
這些問題將會在你努力尋找它們的答案的時候自己暴露出來。而對于你來說,更重要的是去收集盡可能多的信息。這將會增加你這類問題的了解和徹底解決這類問題的知識。
使用在線資源搜索類似的錯誤,也許有人已經報告了這個問題,并給出了解決方案。
當你收集數據的時候,永遠不要假設從別人那里獲得的數據是正確的。請注意觀察你工作的一切細節。如果你正在和一個在遠方的人一起工作,這可能會是一個主要的問題。這時,仔細詢問變得至關重要。而當你試圖確認自己給出的信息時,允許遠程訪問系統問題的工具非常有用。
當詢問在遠程站點的人時,永遠不用問誘導性的問題。他們將盡全力幫助你,有問必答。
在其他時候,你得到的答案一般都取決于你問的那個人對 Linux 的了解程度和電腦知識水平。當一個人懂得或認為他知道關于電腦的知識,你得到的回答可能包含很難反駁的假設。相比于問一句“你檢查過了么”,更好的做法是安排另外一個人來實際執行任務所需的檢查。并且,相比于告訴一個人他/她應該看到什么結果,還不如簡單的讓用戶解釋和描述他/她看到的。再強調一次,對機器的遠程訪問可以讓你確認自己給出的信息。
***的問題解決者是那些從來不會理所當然的人。他們從來不會假定他們擁有的信息是100%正確和完整的。當你擁有的信息看起來自相矛盾時,如果你對此毫無辦法那就重新來過吧。
3.推測原因
從你觀察到的現狀推斷出可能導致問題的原因。
藝術在解決問題上也適用。根據你的知識和過去的經驗觀察問題就是一種演繹藝術,這有點神奇。伴隨著科學方法,依靠產生的靈感、直覺、或神秘的心理過程,找到一些有助于查找問題根本原因的線索。
在某些情況下,這是一個相當簡單的過程。比如你看到一個錯誤代碼,并通過查找現有資料弄明白它的意思。然后,應用自己知道的大量知識推測問題的原因(這是解決問題過程中最為藝術的一步)。在某些情況下,這種推測可能很難作為問題測定過程的一部分。
這個推測的過程有助于記住問題特征而不是記住問題。問題產生了特征現象。但你想解決的是問題而不是問題特征。
#p#
4.動手解決
現在是時候來解決問題了。不要害怕,這通常是最簡單的部分,最難的部分(分析如何解決問題)剛才已經過去了。在你知道問題的原因后,正確的修復一個問題是很容易的。
解決方案多種多樣,可能需要更換硬件的驅動,或者是去更新一些軟件程序。
對于一些有錯誤的軟件,如果你或者你的組織沒有足夠的能力修復它,那至少你可以用適當的方法把錯誤報告給作者或其他組織。我曾經就用Bugzila給紅帽公司報告了幾個錯誤。任何人都可以創建自己Bugzila賬號,并查找現有的錯誤或報告一個新的錯誤。
5.測試效果
采取了修復措施后就應該要進行測試了。通常意義上,這意味著要從任務失敗的地方開始重新操作和重復實驗。
如果修復措施沒起作用,你應該從錯誤開始的地方再運行一遍程序試試。由于錯誤可能會因為你的修復操作而發生變化,所以你要意識到這一點,并對程序運行結果和問題特征進行記錄,以便在下一次迭代修復時對解決方案作出相應的修改。這樣做即使沒能解決問題,問題特征的變化在后續的處理過程里也是很有參考價值的。
二、舉個例子
這是一個幾年前發生在我自己身上的案例。那時候,我曾經在一個實驗室兼職做 Linux 系統管理員。這個問題相當簡單,但足以說明我所概述的方法步驟。
我收到了一封來自我們測試員的電子郵件。郵件里說,他安裝的一個用來測試的軟件崩潰了。錯誤提示信息是系統交換空間不足(SWAP)。這是用戶操作后給我的初步反饋和觀察結果。
從我所知道來看,被用來測試應用程序的系統有高達 16GB 的內存和 2GB 的交換空間。而以往的使用經驗也表明,這些計算機里的交換空間幾乎用不到,它們的內存使用率也往往低于 25% 。
基于上述幾點,我推斷問題并非真的出在交換空間上,因為這幾乎是不可能的。但我仍然保持對它的懷疑,即便這個可能性很小。其實,你也許也發現了許多程序提供的錯誤提示是有誤導嫌疑的,自己觀察的結果反而可以讓你獲得更多有用的信息。
我為測試人員提供了一些自己的意見。我登錄到計算機中,用 free 命令來查看內存和交換空間使用情況。我發現大量的內存還空閑著,而且交換空間沒有被動用。按照我所知道的,如果交換空間的實際使用率為零,那么也就是說開機以后很有可能從未分配可用交換空間,而且內存也沒有分頁。
以我以往的經驗看,解決問題的關鍵就是錯誤信息提示。從提示來看,很像是程序想要向系統索取一些資源卻沒有成功。而對于計算機來說,其他可消耗的資源主要就是 CPU 和硬盤空間。
這并不像 CPU 的問題。所以我用 df 命令檢查一下文件系統,發現 var 文件夾滿了。我推斷/var 空間全滿是導致問題的原因。
我們的系統平常都是給 var 文件夾設置 1.5 GB 大小。通常情況下,我們是在 /opt 中安裝應用程序。這也是我們測試的軟件安裝的地方。
我與測試人員探討這個問題,他告訴我說他確實把應用程序安裝在了 /var 目錄。我告訴他要先從 /var 卸載安裝的應用程序,并在 /opt 里重新安裝。采取這一措施之后,我示意程序員進行測試,結果不出所料,問題被成功解決。
一般來說,你要想解決一個問題,至少需要重復一些步驟。比如說,如果執行給定的修復措施不能解決問題,你可能需要嘗試另一種辦法或者可能需要回到觀察步驟并收集有關該問題的詳細信息。
三、必要的過程分析
很多年來,我一直在教別人怎么修復硬件和軟件的問題。我也一直在思考人們使用的解決問題的思路是否已經足夠規范化。當我被教授了這種解決問題的方法步驟后,它使得我能夠在努力解決問題時清楚的意識到自己處在哪一步。這讓我能分析我在哪里出現錯誤,并重回正軌。
你解決問題的方法流程可能也不一樣。也許你還沒意識到你的思路是一個可描述性和可重復的過程。但是,如果你成功解決了電腦出現的問題,那你所采用的方法就是好方法。了解這個解決問題的方法流程,無論它是否適合你,未來都會有助于你解決遇到的問題。