儘管很高興相信汽車，家庭影院系統，計算機和linux永遠不會崩潰，但實際情況是它們確實存在。
在大多數情況下，我們中使用linux的人更喜歡甚至喜歡做我們自己的故障排除。
解決任何型別的問題都是一門藝術和一門科學。 解決諸如計算機**現的技術問題也需要大量專門知識。
解決任何性質的問題的任何方法（包括計算機和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所屬的位置安裝該應用程式。 採取此操作後，我讓他通過執行先前失敗的操作來測試糾正性應用程式。 測試成功，問題解決了。
解決問題時，有必要至少回溯一些步驟。 例如，如果執行給定的糾正措施不能解決問題，則可能需要嘗試其他措施，或者可能需要返回觀察步驟並收集有關問題的更多資訊。
多年來，我一直在教人們修復硬體和軟體。 我認為我們中的許多人都使用某種形式的問題解決過程，無論該過程是否已正式化。 當我被告知有關此過程的資訊時，它使我能夠了解在解決問題的過程中它在何時何地發生了故障。 這使我能夠分析出**出了問題，並重回正軌。
您的過程可能有所不同，並且您可能沒有意識到您實際上有乙個可描述和可重複的過程。 但是，如果您成功解決了計算機問題，則可以。 意識到該過程，無論對您有多大的幫助，都可以幫助您解決將來的問題。
翻譯自:
一次難忘的 MTS 故障的排除過程
microsoft ole db provider for sql server 錯誤 8004d00a 不能在指定的事務處理器中獲得新事務。或者microsoft ole db provider for sql server 錯誤 8004d00a 新事務不能登記到指定的事務處理器中。我檢視了一下...
linux啟動過程故障排除
linux機器的啟動過程 開機自檢 bios mbr引導 grub選單 載入核心 kernel 執行init程序 全部過程可以主要分為兩個過程 mbr引導和grub 第一階段失效 nbr引導區域一共只有446個位元組，所以當它出現問題時，grub選單是沒法見到的，所以我們來模擬這個問題 使用如下的命...
linux5啟動過程及故障排除
啟動過程及故障排除 1加電 cmos post 上電自檢程式 mbr 引導 grub 選單開機自檢 mbr引導 grub 選單 載入核心 執行 init 程序 讀取 etc inittab 配置檔案 執行 etc rc.d rc.sysinit指令碼 執行 etc rc.d rc 指令碼 執行 et...