This article has been published on ‘Network Administrator World’ in 2007, copyrights belong to ‘Network Administrator World’.
It was firstly posted on 51CTO blog; no transmission, re-publication, or printing is allowed without explicit authorization of the author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
劉志勇
作爲一個網絡管理員，唯一高興的是完成最後一個任務。這就是這個職業的魅力和生命之所在。以前我們已經許多次精疲力盡，然後放棄。但是，我將在本文儘可能幫助廣大網絡管理員降低現實的困難。
我願意和讀者們共享自己的經驗和祕訣。
窺視網管員的工具包
真正的硬件工具
每個網管員由於各自實際情況不同，隨身攜帶的真正的硬件工具也未必相同。我的硬件工具包包括：螺絲刀、網卡、牙醫鏡和微型手電筒、線纜測試儀、錄音設備等東西。下面我講一下這些工具都幹什麼用。
螺絲刀：這個工具毋庸多言，就是拆開機箱用的。但有些服務器，比如早期的Compaq服務器（現在很少見了，說實話我也幾乎沒有見到過），這個螺絲刀就必須是Compaq(Toex)螺絲刀，其末端是星形的，普通的十字螺絲刀是不能使用的。
網卡：用於在工作站或服務器上修復常見的問題，有時候可以用來確認原來的網卡是否有問題。
牙醫鏡和微型手電筒：這是個組合工具，可以讓我在緊急時很容易看到組件的反面和主板。
線纜測試儀：用於網絡佈線的故障和測試定位，如果線纜測試儀很高級，可對線纜進行週期性檢測，確保佈線系統的質量。在評估認證後，將電纜測試儀存儲的測試結果複製到計算機上並打印出來，作爲網絡佈線基準文檔。
錄音設備：相信讀者看到這設備肯定驚訝得下巴都掉了……其實，我也是從歷次的教訓中獲取的經驗。還記得有多少次在一個複雜的故障檢修過程中一次又一次執行相同的步驟和操作嗎？就好比在家中丟失了東西以後在已經找過的地方反覆搜尋，這合理嗎？我是從第一分鐘起，將我所採用的每一個步驟口述到錄音設備中，這種記錄能使我回顧所採用的方法，並決定是否還要遵循檢修的路徑以及結果的本質。我之所以採用口述的方式，而不是用紙筆來記錄故障檢修的過程就是因爲：厭倦！人們往往可以手寫記錄下故障檢修過程的前面幾個步驟，或者前面幾個小時所採用的步驟，但會隨着時間的推移，厭倦會導致這種工作的中斷：所採用的步驟沒有記錄或者是跳過了記錄。而口述是一種相對比較輕鬆的記錄故障檢修過程的工作，能記錄下自始至終的每一步。
其他的工具，要視乎你的工具包是否還有額外的空間，以及你實際的情況，比如，昂貴的FLUKE網絡測試儀器，並不是每個人都會配備的。
軟件工具包
網管員可以根據自己的習慣、愛好等選擇適合自己的軟件工具包，軟件工具包的形式可以是LiveCD或者集成了維修工具的Windows PE啓動光盤，也可以是別的光盤，我用的Windows PE啓動光盤是深山紅葉工具光盤，很好用，網絡上有很多與之相類似的工具光盤。Live Cd我選擇的是Knoppix漢化版，Live CD的選擇有很多，比如Trinity Rescue Kit等等，都可以作爲急救用的Live CD。
現在閃存容量越來越大了，加之現在的新電腦都支持從閃存啓動系統，我們完全可以製作成Live USB，在一定程度上比Live CD更爲靈活。即使不做Live USB，也可以把常用的工具拷貝到閃存內，以備急需。關於這方面可以參考我在2007年5期《電腦自做》第96-101頁刊登的《閃存擴展 隨心而動》文章。
還有一些驅動軟盤，雖說現在軟盤和軟驅近乎絕跡了，但有些場合還是需要的，比如RAID驅動程序等等。
This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
雜項
其他還有一些亂七八糟的東西，我帶的就有小門墊、工作服、套衫、休閒鞋、巧克力什麼的。很驚訝吧？嗯。我帶的小門墊的真實作用是在擁擠的服務器房繞電纜的時候，我跪在上面用來保護我的膝蓋。而不是跪下向客戶和管理人員請罪，哈哈！
很多公司對員工的着裝有很嚴格的要求，必須穿正式的服裝，不能穿休閒的，那麼在髒亂的庫房和機房裏，這一身正式的、嚴肅的服裝是不是很讓你爲難？我帶一套工作服、套衫、休閒鞋就是爲了應付這種窘境的。
巧克力是幹什麼的？不怕各位笑話，我這人有時候有點膽怯，面對未知的故障的時候有時會感到恐懼，這時候吃點巧克力能提高血糖幫助消除恐懼感。
筆記本
從一定意義來說，它可以說是工作日誌。你可以用紙媒介的本子來記筆記，也可以用電子版形式的，只要能達到目的就好，我用的是電子文檔。筆記本對於我來說，它的作用就是告訴我：出現問題時，哪些發生了變化。
當出現一個新的問題時，所要問的第一件事往往就是出現問題之前，是否有什麼變化。
任何網絡操作系統都是一個有問題的系統，有時因爲一些不能解釋的原因，甚至大部分無害的變化都有可能變得一團糟。如果你的筆記本，記錄了每個服務器、每個設備所有變化的詳細日誌，能節省你用在故障檢修上的數個小時。作爲我來講，我有每個服務器單獨的Excel電子表格，記錄了安裝新軟件包、安排重新啓動與否、添加新驅動器或者別的軟件等等，還有時間、日期、服務器每次變化的屬性。
如果在本週對服務器所做的更改，在下週引起了問題，那麼你的筆記本就將發揮非常大的作用。
筆記本對於任何故障的成功解決非常重要。一個人對管理機器明晰，而他的同事卻什麼都不懂，這就毫無意義了。我認爲，這是一種非常危險的處境，特別是問題中的任務對網絡的安全至關重要。如果一旦這個人發生意外，其餘的人該怎麼辦呢？
從實踐經驗來看，隨着新過程的發展將其文檔化的做法是值得鼓勵的。我就有過這種經歷：曾經完美處理過一些事情，但僅僅過了一個月之後就遺忘了！這時候我多麼希望自己以前就記錄到筆記本上啊！這種情況經常會發生。
實際上，根據我的經驗，當出現問題時，不論是打印驅動程序被破壞，還是客戶端連不上網絡，都應該記筆記。十有八九在開始進行之前，當處理問題之後，回到辦公室就會忘記自己做了什麼。
想象一下，如果處理問題時和不斷升級必須有一段停機時間，回想使用的規程可能沒有歸檔，會怎麼樣呢？
筆記的歸檔也很重要。雖然歸檔的內容有一些可能會過時了，比如Windows NT，但無論什麼方法，都要保存起來。一些詳細任務可能再次適用於當前的網絡。另外，當按照新規程部署或者進行Beta測試時，歸檔就更爲重要。如果堅持這種做法，這樣任何人走入服務器機房都可以按照歸檔的筆記執行任務，這對網絡管理工作不是很好嗎？
This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
故障檢修祕訣
Hello，現在我們終於到達了文章最重要的部分。
我的心得
記得MCSE曾經說過，超過58%的故障檢修成功是基於經驗的，無論這種經驗的知識來源於一般計算機系統知識還是所面對的具體問題的知識。剩下的故障檢修成功因素包括運氣，研究工作和你原本的解決問題的能力。
我認爲，重要的是：提高你的故障檢修技巧是長久之計，而不是得到後就可以忘記的結果。
故障檢修技巧雖然主要是通過積累經驗來提高，但實際上，也可以通過閱讀（文章、博客和論壇等）、培訓和其他的方式獲得。
如果你缺乏使用Linux服務器的經驗，這並不意味着在解決問題時你就就一定缺少經驗，即使你具有豐富的技藝也可能只在特定的故障檢修情形中看到其他人會忽視的方面。Nike有一句廣告詞，我很讚賞，這就是：Just do it! 就是說，不要讓你的經驗阻礙你獲取更多的經驗！
故障檢修的步驟
這裏列出的步驟，是用於解決所有問題的“基礎”，是指導解決問題的基礎。
故障檢修的步驟有：識別問題、診斷故障、找出解決方案並實施、確認故障是否解決、記錄解決方案。
識別問題：就是鑑別問題是屬於硬件問題還是故障問題。
診斷故障：區分故障的症狀和起因。確認系統故障是否由於底層的、基本的因素所致；確定這樣的症狀，是否有利於解決其起因。
找出解決方案並實施：毫無疑問，這個步驟通常是反覆的，一次又一次的過程。
確認故障是否解決：上個步驟的解決方案一般需要在不同條件下測試多次。
記錄解決方案：有時候，我經常成功的實踐了一個很好的解決方案，但是忘記了這是在以後遇到同樣的問題時更好解決問題的一個關鍵。這種情況下，就不得不重新學習這個方案，很明顯，花費幾分鐘的時間記錄在排除故障過程中的每一個解決方案很快就能使你獲得巨大的意外收穫。
總結
微軟公司提出過一個故障檢修方法論：謂之D.E.T.E.C.T。這是由一組微軟微軟技術支持工程師創立的方法，爲我們提供了一個策略。實際上，這些步驟是放之四海皆準的，無論是交換機故障，還是Windows服務器故障，抑或是Linux服務器故障，都適用。
D.E.T.E.C.T是：
D Discover 發現問題
在用戶層次上與用戶交談，試着瞭解他們使用的軟件（如果可能的話，包括髮布的版本）以及他們的硬件是否在硬件兼容性列表內。問題表現出的症狀是什麼。
E Explore 探索界限
是否能夠鑑別自從上一次報告系統正常以來都發生了那些變化？能否鑑別問題發生時運行的是什麼軟件嗎？
T Track 跟蹤可能的方法
你可以從處理這些故障中學習並通過跟蹤所採取的步驟，避免陳舊的、效率低下的嘗試——錯誤的方法。
E Execute 實施方法
撇開管理問題，以便在第一個方案的嘗試失敗時不會受到其它部門的干擾。若方案A失敗就應考慮方案B。不要忘記在執行解決問題的任務之前備份重要的系統和應用程序。
C Check 檢驗成功
T 總結
不管是什麼樣的故障排除方法，本質上所有的方法都是遵從一個基本的模式：
發送者——→接受者
輸入——處理——輸出模式
按照微軟D.E.T.E.C.T方法論，進行故障查找明顯的是成功解決系統問題的第一步。
故障檢修的定義
方法論
相信很多網管員都會嘆息過：如果能夠恢復這一切就好了。
在很大程度中，故障檢修是一種方法論。木工有一句話可以引用在這裏：兩次測量，一次切斷。網管員在任何情況下都應三思而後行。
遵從故障排除的黃金規則可以減少你的痛苦：“一次只改變一個變量。”一次改變一個變量，然後進行成功或失敗的測試，這樣就能有效的證明我們排除故障工作工作的結果。這就是方法論的精髓。
我再次強調：在排除故障時，一次一個變量並進行測試。相信我！
一小時原則
經驗表明，缺乏經驗的網管員，尤其是剛入行的，更容易誤入歧途。在查找問題時視野狹窄或者錯過了即時的觀察就有可能誤入歧途。狹窄的視野是一個陷阱，沒有考慮到外部因素可能會產生問題。外部因素有時也會導致災難。在我剛入行的時候，總是從主管的角度來觀察網絡環境，但實際上，總有一些在我控制之外的因素也會對我們產生影響。
在任何一種情況下，基本上應該將排除故障恢復狀態尋求幫助的工作時間限制爲一小時。我比較傾向的方法是隻進行一個小時解決服務器等問題的工作，如果不能解決問題或者保證合理的結束，就給技術支持小組打電話或者與這個領域的同行進行探討。一定要充分利用在這個領域中的同行專家資源。
在一些技術論壇，比如網管員世界論壇、51CTO論壇可以找到該領域的同行，也可加入他們的QQ羣，提供和接受解決所遇到問題的建議。根據一小時原則，當你已經花費了一個小時試圖解決問題時，立刻去QQ羣或者論壇呼叫同行。
故障時間價值的計算
故障時間的價值，也是在故障檢修時要考慮的一個因素。
但是根據我的實際經驗，很多工作人員可能會以系統故障爲藉口停止工作並且可能回家，請問，在辦公室中，你看到過員工利用計算機故障時間來回復耽誤的電話嗎？沒有。很多員工可能只是說計算機系統崩潰了而無法工作。
我覺得故障時間價值的計算，不是三言兩語能夠說明白的，總之，系統故障時間的代價決定了你解決問題的方法，系統故障時間是非常昂貴的，即時在一個很小的企業中，你也可以估算出系統故障時間的代價究竟值多少人民幣。
This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
故障檢修圖
我寫書或者寫技術文章，總是從一個提綱或者腦圖開始。如果故障檢修也像這樣，那麼會更好的進行，並且更加有效。我的經驗是，在白板上創建故障檢修路線圖。每次當我遇到困難的時候，離開機房回到自己的辦公室——這往往是解決問題的靈丹妙藥——可以靜下心來，用清晰的和平衡的頭腦進行思考。
通過在白板上創建故障檢修圖，你可以在工作中包含很多業務管理者。很多業務管理者都熟悉在會議室中反映情況，那裏是很舒適的地方。通過在問題的解決方案中包括業務上的管理者，我們不僅能夠獲得新鮮的血液和新鮮的見解，而且還能夠在技術和業務團體之間樹立正面的管理。通過這樣的手段，可以向他們宣傳解決方案，而且更重要的是，可以迫使他們接受我們的方案。無數的研究以及你自己的工作經驗已經說明有領導們的支持時，成功的機率會更高。
學習曲線分析
實際上就是分析解決故障是否在自己的能力範圍之內。這裏提供一個表格：
|
問題的本質 |
技能 |
學習曲線 |
建議解決方案 |
|
簡單 |
高 |
低級 |
自行解決 |
|
經常發生，不困難 |
中 |
中級 |
在經過一些學習和陰暗解答之後解決問題好處包括能夠很好的利用學習時間。因爲這種類型的問題頻繁發生，一旦進行學習並找到了解決方案，那麼下一次解決問題就很容易。 |
|
頻繁發生，問題介於簡單和困難之間 |
低到中 |
中級到高級 |
這時與技術顧問或專家組成團隊就很有意義。可以讓專家展示解決方案，以便在將來能夠獨立的解決問題。 |
|
在壽命期間只發生一次，非常困難 |
不存在 |
很高級 |
交給別人做。保留一個專家來解決問題，並努力進行解釋。 |
這個表格展現了一個決策模式，可以用於解決問題和利用外部專家的技能時。
對於前兩種情況，可能要很好的利用你的時間來解決問題。對於後兩個情況而言，明顯的需要幫助才能將系統故障時間和公司與相關問題的損失減少到最小的程度。
在早期排除故障的工作中，瞭解你要解決的問題的本質，並確定你是否能夠獨立解決問題，還是需要其他的幫助以加強工作。
整體衡量：過多的檢修，過少的時間
工作的成功是以整體衡量的，不要陷入故障檢修的黑洞中而沒有很好的完成其他工作。
實際上，如果給予足夠的時間，很多網管員都能夠解決問題。但是，時間對於我們每一個人都有限制。你會發現並沒有足夠的時間來完成想要做的任何事情。你有沒有發現過這麼一個情況：從星期一開始查找一個故障，當擡頭看時間時卻發現已經是星期五下午了？是否注意到了在我們埋頭查找問題時，其他的工作已經堆積如山？
即時你有很高的排除網絡故障的技能，但也可能被提升並領導IT部門，你是否明白，你的角色已經改變，你應該將故障檢修的任務委派給一個下屬。因爲故障檢修的時間問題中包含有核心能力。
結交更多的同行朋友
很多時間，都是花費在爭論問題究竟是與硬件有關還是與軟件有關。
如果你在一方面很強，例如軟件方面，那麼正在查找沒有解決方案的軟硬件問題時，而解決方案很可能就從你所薄弱的一方出現。就是說，如果從有優勢的一方已在上市解決問題，往往是另一方導致了我們的失敗。我的經驗告訴我，不止有一個壞掉的網卡導致了軟件相關的網絡問題！
所以，我的建議是，結交更多的同行朋友！這是查找硬件和軟件相關問題時的一個技巧。
讀者可以在網管員世界論壇找到相同領域的同行。
回顧上世紀90年代，這是怎樣的一個漫長、離奇和有趣的旅程啊！從Netware的升起和隕落到Windows Server統治的出現，再到Linux的崛起，這個過程是相當快的。但是有些事情會一直保持下去，包括對於頂尖的排除故障技能的需要。隨着信息化的進展，對於這些技能的需要、尋找和使用更加明顯，因爲，每一個網管員不再被看作是後臺的技術人員，事實上，現在網管員已經引起了高層的重視，因爲故障事件是令人難以置信的代價！即使是非技術的高管也能夠理解這點。隨着信息化更大的進展，信息化承擔重要任務的、企業範圍內的應用，更多的前臺管理人員需要網管員卓越的排除故障技能來保證這些東西正常運行。
祝你們好運！
This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
This article was published on Network Administrator World in 2007, and the copyrights belong to Network Administrator World. The article was first posted on 51CTO blog, no transmission, re-publication, printing allowed unless with explicit authorization of author.
本文已與2007年刊登在《網管員世界》，版權歸《網管員世界》所有。網絡首發51CTO博客，轉載請務必註明出處並告知本人。
劉志勇
二〇〇七年八月於天津