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