第一篇：IT運維手冊(故障及處理)

IT運維手冊

第二篇 硬件篇 一計算機章 ㈤常見問題 1主機

⑴無法正常開機 ①硬盤燈亮

多為顯示器或LCD排線問題，可插入系統引導盤看有無反應，若無反應，則為硬件問題，建議售后處理；若有反應，則為軟件問題，可重裝系統。②硬盤燈不亮

I電源問題

需更換電源和電池，多為電源適配器或電池損壞造成的提供電壓不穩。可更換同型號電源線，排查故障。

II內存問題

拔插內存條或更換插槽。可能是內存條松動或自配內存條不兼容造成，若因不兼容，可通過更改BIOS設置解決。

III灰塵問題

筆記本長期不清洗，積壓過多灰塵會造成靜電或短路，可拆開外殼用吹風機清理灰塵。

IV主板問題 主板問題是造成不能開機最大可能因素，主板為集成電路，任何地方損壞都會造成硬盤無法通電，從而不能開機，建議去售后處理。⑵無法正常上網 ①網絡設置問題

此原因較多出現于需手動指定IP、網關、DNS服務器聯網方式下，及使用代理服務器上網的，應仔細檢查計算機的網絡設置。

②DNS服務器的問題

I當IE無法瀏覽網頁時，可先嘗試用IP地址來訪問，如果可以訪問，則為DNS的問題，造成DNS的問題可能是聯網時獲取DNS出錯或DNS服務器本身問題，可手動指定DNS服務（地址可以是當地TSP提供的DNS服務器地址，也可用其它地方可正常使用DNS服務器地址。在網絡的屬性里進行（控制面板-網絡和撥號連接-本地屬性-TCP/IP協議-屬性-使用下面的DNS服務器地址）。不用的ISP有不同的DNS地址。有時候則是路由器或網卡的問題，無法與ISP的DNS服務連接，這種情況可重啟路由器或重新設置路由器。

II本地DNS緩存出現問題，為提高網站訪問速度，系統會自動將已經訪問過并獲取IP地址的網站存入本地DNS緩存里，一旦繼續訪問此網站，則不再通過DNS服務器而直接從本地DNS緩存取出該網站的IP地址進行訪問。所以，如果本地DNS緩存出現問題，會導致網站無法訪問。可以在“運行”中執行ipconfig /flushdns來重建本地DNS緩存。③IE瀏覽器本身的問題

IE瀏覽器本身出現故障或IE被惡意修改破壞都會導致無法瀏覽網頁，可嘗試用上網助手“IE修復專家”來修復或者重裝IE瀏覽器。④網絡防火墻問題

如果網絡防火墻設置不當，如安全等級過高、不小心把IE放進了阻止訪問列表、錯誤的防火墻策略等，可嘗試檢查策略、降低防火墻安全等級或直接關掉試試是否恢復正常。2顯示器 ⑴無圖像顯示 ①開機無反應

I檢查電腦的外部接線是否接好，把各個連線重新插一遍，看故障是否排除。

II如果故障依舊，接著打開主機箱查看機箱內有無多余金屬物，或主板變形造成的短路，聞一下機箱內有無燒焦的糊味，主板上有無燒毀的芯片，CPU周圍的電容有無損壞等。

III如果沒有，接著清理主板上的灰塵，檢查顯卡等硬件是否有松動，然后檢查電腦是否正常。IV如果故障依舊，則故障可能由內存、顯卡、CPU、主板等設備引起。接著使用插拔法、交換法等方法分別檢查內存、顯卡、CPU等設備是否正常，如果有損壞的設備，更換損壞的設備。

②未檢測到信號

臺式機開機時鍵盤燈不亮、主機風扇正常運轉，則多數屬于鏈接線的問題,將電腦與主機間的鏈接線拔下后清理插頭/孔的灰塵進行重試。⑵藍屏

①首先了解發生藍屏前電腦的情況及所做的操作。如果電腦在CPU或內存等超頻后，出現藍屏，則藍屏故障與超頻有關，只要將頻率恢復正常即可。

②如果電腦在光驅讀盤時被非正常打開導致藍屏，則藍屏故障是由于被誤操作引起的，此故障一般將光盤重新放入光驅，再關上光驅托盤即可。

③如果電腦在帶電插拔某設備時發生藍屏，則藍屏與帶電插拔設備有關，一般重新啟動電腦即可恢復。

④如果電腦在使用某一個應用程序軟件時發生藍屏，則藍屏故障可能是由此程序軟件引起的，一般將程序軟件卸載，再重新安裝即可排除故障；如果不行，則可能是程序軟件本身有錯誤，不能使用。⑤如果電腦在進入系統后就出現藍屏，引起藍屏故障的原因可能較多，需要逐步進行排除。先用殺毒軟件查殺病毒，排除病毒造成的藍屏故障，如果故障排除，則是病毒造成的藍屏故障。

⑥如果故障依舊，重新啟動電腦，然后再用安全模式啟動電腦，啟動后退出系統再重新啟動到正常模式，如果排除則是系統錯誤造成的藍屏故障。二網絡章 ㈡實際操作 2網絡運維常用工具 ①驅動精靈

驅動精靈是一款集驅動管理和硬件檢測于一體的、專業級的驅動管理和維護工具。驅動精靈為用戶提供驅動備份、恢復、安裝、刪除、在線更新等實用功能。另外除了驅動備份恢復功能外，還提供了Outlook地址簿、郵件和 IE 收藏夾的備份與恢復。并且有多國語言界面供用戶選擇。

利用驅動精靈的驅動程序備份功能，在電腦重裝前，將電腦中的最新版本驅動程序通通備份下載，待重裝完成時，再試用它的驅動程序還原功能安裝，便可節省驅動程序安裝的時間。驅動精靈對于手頭上沒有驅動盤的用戶十分實用，用戶可以通過本軟件將系統中的驅動程序提取并備份出來。②360硬件大師

360硬件大師是一款專業易用的硬件工具，準確的硬件檢測可協助辨別硬件的真偽，并能準備提供中文的硬件名稱，使電腦配置一目了然，防止在購買電腦的時候被奸商蒙騙。此外還具有溫度監測、性能測試、一鍵電腦優化等功能。㈢常見網絡問題及解決方案 1電腦安裝網卡后啟動速度降低

①TCP/IP設置中設置了“自動獲取IP地址”，啟動計算機時，計算機都會主動搜索當前網絡中的DHCP服務器，所以計算機啟動的速度會降低，這種情況可選擇“指定IP地址”。

②安裝太多網絡通訊協議或服務，計算機啟動時尋找和加載程序時間加長。可在本地連接的屬性中刪除不必要的協議和服務，對局域網的一般應用而言，有TCP/IP協議，MICROSOFT網絡用戶，MICROSOFT網絡的文件和打印機三個網絡組建即可。2網絡中的某臺計算機挪動后，線路連接出現中斷，將水晶頭用手按住時，網絡連通情況為時斷時續。計算機Ping本機地址成功，Ping外部地址不通，使用測線儀對網絡線路進行測量，發現部分用于傳輸數據的主要芯線不通。

①拔下水晶頭，檢查水晶頭與網卡接口，若網卡RJ-45接口中的部分彈簧片松動，導致網卡接口與RJ-45頭沒有連接好，用鑷子將彈簧片復位，再行接入后故障即可排除。②采用網絡測線儀對雙絞線兩端接頭進行測試，必要時可讓兩端雙絞線脫離配線架、模塊或水晶頭直接進行測量確診，以防因連接問題造成誤診，確診后即可沿網絡路由對故障點進行人工查找。如果有專用網絡測試儀就可直接查到斷點處與測量點間的距離，從而更準確地定位故障點。對線路斷開的處理，通常可將雙絞線、銅芯一一對應纏繞連接后，加以焊接并進行外皮的密封處理，也可將斷點的所有芯線斷開，分別壓制進入水晶頭后用對接模塊進行直接連接。如果無法查找斷點或無法焊接，在保證斷開芯線不多于4根的情況下也可在兩端將完好芯線線序優先調整為1、2、3、6，以確保信號有效傳輸。在條件許可的情況下，也可用新雙絞線重新進行布設。五視頻會議系統 ㈠寶利通視頻會議系統 3常見問題

⑴系統不響應遙控器

①遙控器中沒有電池、電池電量不足或電池耗盡； ②遙控器中電池安裝不正確；

③紅外傳感器接收不到遙控器信號或遙控器信號受到干擾； ⑵拿起遙控器，監視器屏幕保持黑屏 ①監視器電源線未插入； ②監視器為正確連接到系統。㈡科達視頻會議系統 3常見問題

⑴本會場在會議中本端講話有較大回聲 ①麥克風位置擺放不適合。

檢查使所有的麥克風距離揚聲器都在3米以上，且沒有麥克風正對著揚聲器。

②遠端會場揚聲器輸出音量過大。

與遠端會場聯絡，請其檢查并降低音量。

③當召開多級級聯的會議、主會場發言時，分會場沒有閉音。

當召開多級級聯的會議、主會場發言時，最好要求分會場將本地麥克風閉音或主會場將各分會場遠端閉音。⑵終端開啟后沒有聲音輸出。①音頻輸入線路異常。

用一個已確認正常工作的音頻輸入設備連接到終端之后再聽聲音。

②音頻輸出線路異常。

用一個已確認正常工作的音頻輸入設備連接到輸出設備，確認輸出線路和音箱等音頻輸出設備正常。③終端的音量是否太低或為靜音狀態。

通過遙控器改變聲音大小或靜音狀態。第五篇 制度篇 三各單位

㈠信息化管理工作制度 ㈡信息化管理崗位職責

第二篇：運維故障處理思路

事件/故障處理應該要有什么思路 導讀：

在講解事件、故障處理思路前，我先講一個故障場景（以呼叫中心系統作為一例子）：

業務人員反映呼叫中心系統運行緩慢，部份電話在自助語言環節系統處理超時，話務轉人工座席，人工座席出現爆線情況。

運維人員開始忙活了，查資源使用情況、查服務是否正常、查日志是否報錯、查交易量還有沒有??時間不知不覺的在敲鍵盤、敲鍵盤、敲鍵盤中過去，但是原因還未定位。

經理過來了解情況：“系統恢復了嗎？”、“故障影響是什么？”、“交易中斷了嗎？”??

運維人員趕緊敲鍵盤，寫sql，看交易量；敲鍵盤，寫命令，看系統資源、情況??

最終，定位到問題原因是其中一個功能沒有控制返回數量，導致內存泄露。針對這個故障，業務希望運維能否更快的解決故障的恢復，經理希望制定優化呼叫中心故障處理流程，做了以下幾件事：

1.優先故障處理過程的時間——”能通過鼠標完成的工作，不要用鍵盤“ 2.提前發現故障，加強監控——“技術早于業務發現問題，監控不僅是報警，還要協助故障定位”

3.完善故障應急方案——“應急方案是最新的、準確的、簡單明了的” 4.長遠目標：故障自愈——”能固化的操作自動化，能機器做的讓機器做“ 下面將從故障常見的處理方法開始介紹，再從故障前的準備工作（完善監控、制定應急方案等方式）來解決經理提出的問題，并提出未來解決故障的想法。

1、常見的方法：

1）確定故障現象并初判問題影響

在處理故障前，運維人員首先要知道故障現象，故障現象直接決定故障應急方案的制定，這依賴于運維人員需要對應用系統的整體功能有一定的熟悉程度。確認了故障現象后，才能指導運維人員初判斷故障影響。2）應急恢復

運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。

有了上述故障現象與影響的判斷后，就可以制定故障應急操作，故障應急有很多，比如：

? ? ? ? ? ? ? 服務整體性能下降或異常，可以考慮重啟服務； 應用做過變更，可以考慮是否需要回切變更； 資源不足，可以考慮應急擴容；

應用性能問題，可以考慮調整應用參數、日志參數； 數據庫繁忙，可以考慮通過數據庫快照分析，優化SQL； 應用功能設計有誤，可以考慮緊急關閉功能菜單； 還有很多??

另外，需要補充的是，在故障應急前，在有條件的情況需要保存當前系統場景，比如在殺進程前，可以先抓個CORE文件或數據庫快照文件。

3）快速定位故障原因

? 是否為偶發性、是否可重現

故障現象是否可以重現，對于快速解決問題很重要，能重現說明總會有辦法或工具幫助我們定位到問題原因，而且能重現的故障往往可能是服務異常、變更等工作導致的問題。

但，如果故障是偶發性的，是有極小概率出現的，則比較難排查，這依賴于系統是否有足夠的故障期間的現場信息來決定是否可以定位到總是原因。

? 是否進行過相關變更

大部份故障是由于變更導致，確定故障現象后，如果有應的變更，有助于從變更角度出現分析是否是變更引起，進而快速定位故障并準備好回切等應急方案。

? 是否可縮小范圍

一方面應用系統提倡解耦，一支交易會流經不同的應用系統及模塊；另一方面，故障可能由于應用、系統軟件、硬件、網絡等環節的問題。在排查故障原因時應該避免全面性的排查，建議先把問題范圍縮小到一定程序后再開始協調關聯團隊排查。

? 關聯方配合分析問題 與第（3）點避免同時各關聯團隊同時無頭緒的排查的同時，對于牽頭方在縮小范圍后需要開放的態度去請求關聯方配合定位，而對于關聯方則需要有積極配合的工作態度。

? 是否有足夠的日志

定位故障原因，最常用的方法就是分析應用日志，對運維人員不僅需要知道業務功能對應哪個服務進程，還要知道這個服務進程對應的哪些應用日志，并具備一些簡單的應用日志異常錯誤的判斷能力。

? 是否有core或dump等文件

故障期間的系統現場很重要，這個在故障應急前建議在有條件的情況下留下系統現場的文件，比如COREDUMP，或TRACE采集信息等，備份好一些可能被覆蓋的日志等。

上述是一般性的故障常見的方法，在重大故障或多方處理的故障出現時，往往小范圍的排查不利于快速解決，需要啟動緊急處理的流程，建議可以考慮以下溝通：

? ? ? ? ? ? 召集相關人員 描述故障現狀

說明正常應用邏輯流程 陳述變更

排查進展，展示信息 領導決策

2、完善監控

1）從監控可視化上完善

完善的監控策略需要有統一的可視化操作界面，在制定完善的監控策略后，故障處理人員需要能夠快速的看到相應的運行數據，比如：能夠看到一段時間的趨勢、故障期間的數據表現、性能分析的情況等等數據，且這些數據可以提前制定好策略直接推出分析結果給故障處理人員，這樣就大大提高了故障的處理效率，以呼叫中心系統為例，需要提前配置好以下實時交易數據，以便故障定位：

-交易性能數據：平均交易耗時、系統內部模塊交易耗時（IVR交易耗時、接口總線交易耗時）、關聯系統交易耗時（核心交易耗時、工單系統交易耗時等）-重要交易指標數據：交易量、IVR交易量、話務量、座席通話率、核心交易筆數、工單等系統交易量

-交易異常情況數據：交易成功率、失敗率、錯誤碼最多交易-按服務器分析交易數據：按server統計各服務交易處理筆數，交易總耗時 有了以上交易數據，并通過監控按一定頻率統計，運維人員在出現故障時，通過鼠標即點擊即可看到故障什么時候開始，是系統內部有問題還是關聯系統有問題，最突出的交易是哪一支，各服務器交易量是否均衡等情況。

2）從監控面上完善

監控最基本的工作就是實現對負載均衡設備、網絡設備、服務器、存儲設備、安全設備、數據庫、中間件及應用軟件等IT資源的全面監控管理。在應用軟件類的監控工作中，不僅需要有服務進程、端口等監控，還需要有業務、交易層的監控。

全面性的應用監控可以讓故障提前預警，并保存了影響應用運行環境的數據，以縮短故障處理時間。

3）從監控告警上完善

完善的監控策略需要有清晰的監控告警提示，值班人員要以根據監控告警即可作出簡單的問題定位與應急處理方案。比如類似以下的監控短信：

22時，【理財應用系統】中【應用服務器LC_APPsvrA 10.2.111.111】的【前置應用模塊】出現【應用端口：9080】不存在，該端口作用【提供理財應用處理（負載均衡部署）】，原因可能為【SERVER1服務異常停止】，監控系統己進行以下應急處理【自動執行端口進程啟動】，該事件緊急程度【高】。管理員可以通過短信內容看到哪個系統、哪個應用、哪個模塊出了什么問題，可能是什么原因，對業務有什么影響，是否需要馬上處理（比如凌晨出現此預警是否可以延遲到次日處理）等信息。

4)從監控分析上完善

完善的監控策略不僅需要有實時的數據告警，也要有匯總數據的分析告警,實時數據分析的告警的重要性不用多說，對于匯總分析的數據則能發現潛在風險，同時也為分析疑難雜癥提供幫忙。

5)從監控主動性上完善

監控不僅僅是報警，它還可以做得更多，只要我們想辦法賦予它主動解決事件的規則，它便有為管理員處理故障的能力。

3、應急方案

提前制定好故障應急方案是很有必要的，但在日常工作過程中我們的應急方案遇到一些問題： 1）應急方案缺乏持續維護，缺乏演練，信息不及時、不準確； 2）應急方案過于追求大而全，導致不利于閱讀與使用； 3）應急方案形式大于實際使用效果，方案針對性不強； 4）只關注應急方案的內容，但沒有關注運維人員對方案的理解； 針對上述常見問題，我認為應急方案需要做到以下幾點：

1）內容精&簡

很多人可能會認為故障出現的形式各種各樣，所以應急方案需要涉及到方方面面。但實際的故障處理過程中，我們可以發現其實我們的應急措施往往重復使用幾個常用的步驟，所以我認為應急方案要有重點，如果一個應急方案可以應對平時故障處理80%的場景，那這個應急手冊應該是合格的。過于追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變更一個應付檢查的文檔。以下是我覺得應用系統應急方案應該有的內容：（1）系統級：

能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。

另外，系統級里還涉及一些基本應急操作，比如擴容、系統及網絡參數調整等。（2）服務級：

能知道這個服務影響什么業務，服務涉及的日志、程序、配置文件在哪里，如何檢查服務是否正常，如何重啟服務，如何調整應用級參數等。（3）交易級：

能知道如何查到某支或某類交易出現了問題，是大面積、局部，還是偶發性問題，能用數據說明交易影響的情況，能定位到交易報錯的信息。這里最常用的方法就是數據庫查詢或工具的使用。

知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。（4）輔助工具的使用：

有時候，需要借助一些工具或自動化工具輔助分析并應急，這時需要有輔助工具如何使用的方法。（5）溝通方案：

溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。（6）其它：

上述5點內容如何都完備，相信這個應急手冊己可以解決80%的故障恢復工作。

2）應急方案是一項持續的工作

有了應急方案，如何讓運維人員持續去更新是難點。我認為要解決這個難點，需要先讓運維人員經常使用這個手冊。如果一個手冊沒有場景可以用，那就需要管理者為運維人員創造機會去使用這個手冊，比如應急演練。

3）關注運維人員對應用關鍵信息的認識

前兩點關注了手冊，最后一點我覺得有必要關注使用這個手冊的人。有些運維人員認為應用運維人員沒有能力去把應用系統本身的內容了解得很透徹，所以應用運維人員在故障處理過程中的地位很尷尬，運維人員掌握操作權，但卻不知道應該操作什么。

對此，我認同應用運維人員不需要掌握應用系統的業務功能，但我覺得就對應用系統本身來講應用運維人員需要具備以下最基本的能力：（1）知道應用系統這個是干什么的，基本的業務是什么；（2）知道應用架構部署、上下游系統邏輯關系；

（3）知道應用下的服務的作用、端口、服務級的應急處理，日志等數據信息如何找到并簡單定位。

（4）知道應用系統重要的時間點及任務，比如開業、停業、換日、定時任務的時間點以及如何判斷這些任務是否正確（5）知道最重要的幾支交易的流程；（6）知道常見數據庫表結構，并能使用。

4、智能化事件處理

處理方法如下圖（詳細的智能化涉及監控、規則引擎、配置工具、CMDB、應用配置庫等模塊協同工作，具體介紹后續分析）

第三篇：代維故障處理規范

代維故障處理規范

為保證代維單位及時高效地處理故障，結合公司實際制定本規范。

一、故障分類

按照目前代維公司維護的界面分工，需要代維處理的故障主要分為基站設備故障（主要為動力配套設備）、基站停電故障、光纜線路故障（按線路級別分干線、本地網、接入網）、室內分布系統。

二、故障通知程序

1、基站設備故障

基站設備故障由網管中心值班人員通過監控系統發現通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業接口人，并做好故障記錄督促代維公司在規定時間內修復障礙，代維公司未能在規定時間內修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經理。

2、基站停電故障

基站停電由網管中心值班人員通過動力環境監控系統發現通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業接口人，并做好故障記錄督促代維公司在規定時間內修復障礙，代維公司未能在規定時間內修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經理。

3、光纜線路故障

干線光纜線路故障（含本地網骨干網線路）網管中心值班人員通知線路代維管理人員，同時通知傳輸中心值班工程師和傳輸中心主任，線路代維管理人員接到通知后應立即通知代維公司專業接口人，并向部門分管領導匯報，代維公司未能在規定時間內修復障礙的，網管中心值班人員應立即部門經理和公司分管領導。

本地網線路故障（本地網骨干網除外）網管中心值班人員通知線路代維管理人員，同時通知傳輸中心值班工程師和傳輸中心主任，線路代維管理人員接到通知后應立即通知代維公司專業接口人，并做好故障記錄督促代維公司在規定時間內修復障礙，代維公司未能在規定時間內修復障礙的，線路代維管理員應立即通知動力代維中心主任和部門分管經理。

接入網線路故障由客響中心112故障專業人員和網管中心值班人員誰先發現誰通知客響中心值班工程師或縣分裝維人員，客響中心值班工程師（或縣分裝維人員）判斷為線路故障應立即通知線路代維管理人員（網管中心值班人員若能直接判斷線路故障可直接通知線路代維管理人員，并告知客響中心值班工程師），線路代維管理人員接到通知后應立即通知代維公司專業接口人，并做好故障記錄督促代維公司在規定時間內修復障礙，代維公司未能在規定時間內修復障礙的，線路代維管理員應立即通知動力代維中心主任和部門分管經理。

4、室內分布系統

室內分布系統故障由網管中心值班人員通過監控系統發現通知基站代維管理員和無線中心主任，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業接口人，并做好故障記錄督促代維公司在規定時間內修復障礙，代維公司未能在規定時間內修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經理，網管中心值班人員應通知部門無線分管經理。

三、故障處理記錄

1、對于基站設備和停電故障，代維單位每周匯總一次提交基站代維管理人員，對涉及到的搶修材料應做好臺賬登記。

2、對于線路故障，應在處理故障結束后24小時內提交故障處理記錄。

四、故障處理支撐

對于已經交由代維單位處理的故障如不能及時搶通修復，運行維護部相應專業需派人到場進行指導和督促。對于影響業務的故障如代維單位不能在規定的搶修時限內完成，基站或線路代維管理人員應與相關專業工程師到場協助搶修。

五、故障歸口及上報

所有涉及代維故障需第一時間通知到代維管理中心基站或線路代維管理人員，各專業工程師及縣分工維中心工程師不得擅自調動代維人員，緊急情況下可先通知代維搶修人員后向代維管理中心報備。所有代維公司處理的故障由動力代維中心督促代維公司提交故障處理記錄后向質量管理中心進行上報。

二○一二年一月十七日

第四篇：linux服務器故障之運維經驗總結

服務器故障之運維經驗總結

作為一個運維人員，遇到服務器故障是在所難免的，要是再趕上修復時間緊、奇葩的技術平臺、缺少信息和文檔，基本上這過程都會慘痛到讓我們留下深刻的記憶。當出現此類問題時，應該如何處理？本文給大家詳盡的分析了一下，一起來看看。

我們團隊為上一家公司承擔運維、優化和擴展工作的時候，我們碰到了各種不同規模的性能很差的系統和基礎設備（大型系統居多，比如CNN或者世界銀行的系 統）。要是再趕上修復時間緊、奇葩的技術平臺、缺少信息和文檔，基本上這過程都會慘痛到讓我們留下深刻的記憶。

遇到服務器故障，問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手：

一、盡可能搞清楚問題的前因后果

不要一下子就扎到服務器前面，你需要先搞明白對這臺服務器有多少已知的情況，還有故障的具體情況。不然你很可能就是在無的放矢。

必須搞清楚的問題有：

? ? ? ? ? ? ? ? ? 故障的表現是什么？無響應？報錯？ 故障是什么時候發現的？ 故障是否可重現？

有沒有出現的規律（比如每小時出現一次）

最后一次對整個平臺進行更新的內容是什么（代碼、服務器等）？

故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個地域的…)? 基礎架構（物理的、邏輯的）的文檔是否能找到?

是否有監控平臺可用?（比如Munin、Zabbix、Nagios、New Relic… 什么都可以）

是否有日志可以查看?.（比如Loggly、Airbrake、Graylog…）

最后兩個是最方便的信息來源，不過別抱太大希望，基本上它們都不會有。只能再繼續摸索了。

二、有誰在? $ w$ last 用這兩個命令看看都有誰在線，有哪些用戶訪問過。這不是什么關鍵步驟，不過最好別在其他用戶正干活的時候來調試系統。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前發生了什么? $ history

查看一下之前服務器上執行過的命令。看一下總是沒錯的，加上前面看的誰登錄過的信息，應該有點用。另外作為admin要注意，不要利用自己的權限去侵犯別人的隱私哦。到這里先提醒一下，等會你可能會需要更新 HISTTIMEFORMAT 環境變量來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令，同樣會令人抓狂的。

四、現在在運行的進程是啥? $ pstree-a$ ps aux

這都是查看現有進程的。ps aux 的結果比較雜亂，pstree-a 的結果比較簡單明了，可以看到正在運行的進程及相關用戶。

五、監聽的網絡服務

$ netstat-ntlp$ netstat-nulp$ netstat-nxlp

我一般都分開運行這三個命令，不想一下子看到列出一大堆所有的服務。netstat-nalp倒也可以。不過我絕不會用 numeric 選項（鄙人一點淺薄的看法：IP 地址看起來更方便）。找到所有正在運行的服務，檢查它們是否應該運行。查看各個監聽端口。在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。

如果服務器上有好幾個Java或者Erlang什么的進程在同時運行，能夠按PID分別找到每個進程就很重要了。

通常我們建議每臺服務器上運行的服務少一點，必要時可以增加服務器。如果你看到一臺服務器上有三四十個監聽端口開著，那還是做個記錄，回頭有空的時候清理一下，重新組織一下服務器。

六、CPU 和內存

$ free-m$ uptime$ top$ htop 注意以下問題:

? ? 還有空余的內存嗎? 服務器是否正在內存和硬盤之間進行swap?

還有剩余的CPU嗎? 服務器是幾核的? 是否有某些CPU核負載過多了? ? 服務器最大的負載來自什么地方?平均負載是多少?

七、硬件

$ lspci$ dmidecode$ ethtool

有很多服務器還是裸機狀態，可以看一下：

? ? 找到RAID 卡(是否帶BBU備用電池?)、CPU、空余的內存插槽。根據這些情況可以大致了解硬件問題的來源和性能改進的辦法。

網卡是否設置好? 是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?

八、IO 性能

$ iostat-kx 2$ vmstat 2 10$ mpstat 2 10$ dstat--top-io--top-bio 這些命令對于調試后端性能非常有用。

? ? ? ? 檢查磁盤使用量：服務器硬盤是否已滿? 是否開啟了swap交換模式(si/so)?

CPU被誰占用：系統進程? 用戶進程? 虛擬機?

dstat 是我的最愛。用它可以看到誰在進行 IO： 是不是MySQL吃掉了所有的系統資源? 還是你的PHP進程?

九、掛載點 和 文件系統

$ mount$ cat /etc/fstab$ vgs$ pvs$ lvs$ df-h$ lsof +D / /* beware not to kill your box */

? ? ? ? ? ? 一共掛載了多少文件系統?

有沒有某個服務專用的文件系統?(比如MySQL?)

文件系統的掛載選項是什么： noatime? default? 有沒有文件系統被重新掛載為只讀模式了？

磁盤空間是否還有剩余?

是否有大文件被刪除但沒有清空?

如果磁盤空間有問題，你是否還有空間來擴展一個分區？

十、內核、中斷和網絡

$ sysctl-a | grep...$ cat /proc/interrupts$ cat /proc/net/ip_conntrack /* may take some time on busy servers */$ netstat$ ss-s

? 你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因為大量的網絡中斷請求或者RAID請求而過載了？ ?

? ? ? SWAP交換的設置是什么？對于工作站來說swappinness 設為 60 就很好, 不過對于服務器就太糟了：你最好永遠不要讓服務器做SWAP交換，不然對磁盤的讀寫會鎖死SWAP進程。

conntrack_max 是否設的足夠大，能應付你服務器的流量? 在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的？ 如果要顯示所有存在的連接，netstat 會比較慢，你可以先用 ss 看一下總體情況。

你還可以看一下 Linux TCP tuning 了解網絡性能調優的一些要點。

十一、系統日志和內核消息

$ dmesg$ less /var/log/messages$ less /var/log/secure$ less /var/log/auth

? ? ? 查看錯誤和警告消息，比如看看是不是很多關于連接數過多導致？ 看看是否有硬件錯誤或文件系統錯誤?

分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。

十二、定時任務

$ ls /etc/cron* + cat$ for user in $(cat /etc/passwd | cut-f1-d:);do crontab-l-u $user;done

? ? ? 是否有某個定時任務運行過于頻繁? 是否有些用戶提交了隱藏的定時任務?

在出現故障的時候，是否正好有某個備份任務在執行？

十三、應用系統日志

這里邊可分析的東西就多了, 不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+Perl）應用環境里:

? ? ? ? ? Apache & Nginx;查找訪問和錯誤日志, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。

MySQL;在mysql.log找錯誤消息，看看有沒有結構損壞的表，是否有innodb修復進程在運行，是否有disk/index/query 問題.PHP-FPM;如果設定了 php-slow 日志, 直接找錯誤信息(php, mysql, memcache, …)，如果沒設定，趕緊設定。

Varnish;在varnishlog 和 varnishstat 里, 檢查 hit/miss比.看看配置信息里是否遺漏了什么規則，使最終用戶可以直接攻擊你的后端？

HA-Proxy;后端的狀況如何？健康狀況檢查是否成功？是前端還是后端的隊列大小達到最大值了？ ?

結論

經過這5分鐘之后，你應該對如下情況比較清楚了：

? ? ? 在服務器上運行的都是些啥？

這個故障看起來是和 IO/硬件/網絡 或者 系統配置(有問題的代碼、系統內核調優, …)相關。

這個故障是否有你熟悉的一些特征？比如對數據庫索引使用不當，或者太多的apache后臺進程。

你甚至有可能找到真正的故障源頭。就算還沒有找到，搞清楚了上面這些情況之后，你現在也具備了深挖下去的條件。當然還可以借助ITIL工具對CMDB資產的關聯進行深入分析。繼續努力吧！

第五篇：運維工作指導手冊(精)

運維工作指導手冊

一、資源和業務規劃及申請

1、項目計劃書模板

2、背景和業務目標規劃

3、組織和人力資源規劃

4、硬件資源規劃

5、業務規劃

6、財務預算

二、組織和人力資源管理

1、管理職責

2、設置組織機構(成立、任命、部門手冊、崗位職責

3、人力資源招聘

4、入職培訓和轉正

5、薪酬待遇

6、績效考核

7、人才培養和團隊建設

三、財務和行政資源管理

1、管理職責

2、硬件資源配置

3、費用和報銷管理

4、財務統計和核算

四、其他工作管理

1、作息制度

2、工作計劃和匯報制度

3、固定資產低值易耗品管理

4、工具管理

5、備品備件和耗材管理

6、實驗室管理

7、數據監控中心管理

8、檔案室管理

9、收入管理

五、設備和基站移交

1、排查

2、檢測

3、比對驗收

4、設備整改和更換

5、交接

六、簽訂合同和新建、更換設備

1、明確建設要求

2、簽定合同

3、新建和更換設備

七、運營

1、確定運營目標和要求,制定工作流程和制度

2、制定巡檢計劃并執行

3、確定數據監控計劃并執行

4、確定維修和故障處理計劃并執行

5、確定數據和工作報告計劃并執行

6、確定關系維護計劃并執行

八、附錄 流程和規章制度