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

IT運維手冊

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

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

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

I電源問題

需更換電源和電池，多為電源適配器或電池損壞造成的提供電壓不穩(wěn)?？筛鼡Q同型號電源線，排查故障。

II內(nèi)存問題

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

III灰塵問題

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

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

此原因較多出現(xiàn)于需手動指定IP、網(wǎng)關(guān)、DNS服務器聯(lián)網(wǎng)方式下，及使用代理服務器上網(wǎng)的，應仔細檢查計算機的網(wǎng)絡(luò)設(shè)置。

②DNS服務器的問題

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

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

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

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

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

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

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

②未檢測到信號

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

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

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

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

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

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

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

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

360硬件大師是一款專業(yè)易用的硬件工具，準確的硬件檢測可協(xié)助辨別硬件的真?zhèn)危⒛軠蕚涮峁┲形牡挠布Q，使電腦配置一目了然，防止在購買電腦的時候被奸商蒙騙。此外還具有溫度監(jiān)測、性能測試、一鍵電腦優(yōu)化等功能。㈢常見網(wǎng)絡(luò)問題及解決方案 1電腦安裝網(wǎng)卡后啟動速度降低

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

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

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

⑴系統(tǒng)不響應遙控器

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

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

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

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

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

與遠端會場聯(lián)絡(luò)，請其檢查并降低音量。

③當召開多級級聯(lián)的會議、主會場發(fā)言時，分會場沒有閉音。

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

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

②音頻輸出線路異常。

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

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

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

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

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

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

業(yè)務人員反映呼叫中心系統(tǒng)運行緩慢，部份電話在自助語言環(huán)節(jié)系統(tǒng)處理超時，話務轉(zhuǎn)人工座席，人工座席出現(xiàn)爆線情況。

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

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

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

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

1.優(yōu)先故障處理過程的時間——”能通過鼠標完成的工作，不要用鍵盤“ 2.提前發(fā)現(xiàn)故障，加強監(jiān)控——“技術(shù)早于業(yè)務發(fā)現(xiàn)問題，監(jiān)控不僅是報警，還要協(xié)助故障定位”

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

1、常見的方法：

1）確定故障現(xiàn)象并初判問題影響

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

運維最基本的指標就是系統(tǒng)可用性，應急恢復的時效性是系統(tǒng)可用性的關(guān)鍵指標。

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

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

應用性能問題，可以考慮調(diào)整應用參數(shù)、日志參數(shù)； 數(shù)據(jù)庫繁忙，可以考慮通過數(shù)據(jù)庫快照分析，優(yōu)化SQL； 應用功能設(shè)計有誤，可以考慮緊急關(guān)閉功能菜單； 還有很多??

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

3）快速定位故障原因

? 是否為偶發(fā)性、是否可重現(xiàn)

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

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

? 是否進行過相關(guān)變更

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

? 是否可縮小范圍

一方面應用系統(tǒng)提倡解耦，一支交易會流經(jīng)不同的應用系統(tǒng)及模塊；另一方面，故障可能由于應用、系統(tǒng)軟件、硬件、網(wǎng)絡(luò)等環(huán)節(jié)的問題。在排查故障原因時應該避免全面性的排查，建議先把問題范圍縮小到一定程序后再開始協(xié)調(diào)關(guān)聯(lián)團隊排查。

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

? 是否有足夠的日志

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

? 是否有core或dump等文件

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

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

? ? ? ? ? ? 召集相關(guān)人員 描述故障現(xiàn)狀

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

排查進展，展示信息 領(lǐng)導決策

2、完善監(jiān)控

1）從監(jiān)控可視化上完善

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

-交易性能數(shù)據(jù)：平均交易耗時、系統(tǒng)內(nèi)部模塊交易耗時（IVR交易耗時、接口總線交易耗時）、關(guān)聯(lián)系統(tǒng)交易耗時（核心交易耗時、工單系統(tǒng)交易耗時等）-重要交易指標數(shù)據(jù)：交易量、IVR交易量、話務量、座席通話率、核心交易筆數(shù)、工單等系統(tǒng)交易量

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

2）從監(jiān)控面上完善

監(jiān)控最基本的工作就是實現(xiàn)對負載均衡設(shè)備、網(wǎng)絡(luò)設(shè)備、服務器、存儲設(shè)備、安全設(shè)備、數(shù)據(jù)庫、中間件及應用軟件等IT資源的全面監(jiān)控管理。在應用軟件類的監(jiān)控工作中，不僅需要有服務進程、端口等監(jiān)控，還需要有業(yè)務、交易層的監(jiān)控。

全面性的應用監(jiān)控可以讓故障提前預警，并保存了影響應用運行環(huán)境的數(shù)據(jù)，以縮短故障處理時間。

3）從監(jiān)控告警上完善

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

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

4)從監(jiān)控分析上完善

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

5)從監(jiān)控主動性上完善

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

3、應急方案

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

1）內(nèi)容精&簡

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

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

另外，系統(tǒng)級里還涉及一些基本應急操作，比如擴容、系統(tǒng)及網(wǎng)絡(luò)參數(shù)調(diào)整等。（2）服務級：

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

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

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

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

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

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

2）應急方案是一項持續(xù)的工作

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

3）關(guān)注運維人員對應用關(guān)鍵信息的認識

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

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

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

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

4、智能化事件處理

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

第三篇：代維故障處理規(guī)范

代維故障處理規(guī)范

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

一、故障分類

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

二、故障通知程序

1、基站設(shè)備故障

基站設(shè)備故障由網(wǎng)管中心值班人員通過監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時間內(nèi)修復障礙，代維公司未能在規(guī)定時間內(nèi)修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經(jīng)理。

2、基站停電故障

基站停電由網(wǎng)管中心值班人員通過動力環(huán)境監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時間內(nèi)修復障礙，代維公司未能在規(guī)定時間內(nèi)修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經(jīng)理。

3、光纜線路故障

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

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

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

4、室內(nèi)分布系統(tǒng)

室內(nèi)分布系統(tǒng)故障由網(wǎng)管中心值班人員通過監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員和無線中心主任，并做好故障派單記錄，基站代維管理員接到通知后應立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時間內(nèi)修復障礙，代維公司未能在規(guī)定時間內(nèi)修復障礙的，基站代維管理員應立即通知動力代維中心主任和部門分管經(jīng)理，網(wǎng)管中心值班人員應通知部門無線分管經(jīng)理。

三、故障處理記錄

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

2、對于線路故障，應在處理故障結(jié)束后24小時內(nèi)提交故障處理記錄。

四、故障處理支撐

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

五、故障歸口及上報

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

二○一二年一月十七日

第四篇：linux服務器故障之運維經(jīng)驗總結(jié)

服務器故障之運維經(jīng)驗總結(jié)

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

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

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

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

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

必須搞清楚的問題有：

? ? ? ? ? ? ? ? ? 故障的表現(xiàn)是什么？無響應？報錯？ 故障是什么時候發(fā)現(xiàn)的？ 故障是否可重現(xiàn)？

有沒有出現(xiàn)的規(guī)律（比如每小時出現(xiàn)一次）

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

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

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

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

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

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

三、之前發(fā)生了什么? $ history

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

四、現(xiàn)在在運行的進程是啥? $ pstree-a$ ps aux

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

五、監(jiān)聽的網(wǎng)絡(luò)服務

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

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

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

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

六、CPU 和內(nèi)存

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

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

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

七、硬件

$ lspci$ dmidecode$ ethtool

有很多服務器還是裸機狀態(tài)，可以看一下：

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

網(wǎng)卡是否設(shè)置好? 是否正運行在半雙工狀態(tài)? 速度是10MBps? 有沒有 TX/RX 報錯?

八、IO 性能

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

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

CPU被誰占用：系統(tǒng)進程? 用戶進程? 虛擬機?

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

九、掛載點 和 文件系統(tǒng)

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

? ? ? ? ? ? 一共掛載了多少文件系統(tǒng)?

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

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

磁盤空間是否還有剩余?

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

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

十、內(nèi)核、中斷和網(wǎng)絡(luò)

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

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

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

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

你還可以看一下 Linux TCP tuning 了解網(wǎng)絡(luò)性能調(diào)優(yōu)的一些要點。

十一、系統(tǒng)日志和內(nèi)核消息

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

? ? ? 查看錯誤和警告消息，比如看看是不是很多關(guān)于連接數(shù)過多導致？ 看看是否有硬件錯誤或文件系統(tǒng)錯誤?

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

十二、定時任務

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

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

在出現(xiàn)故障的時候，是否正好有某個備份任務在執(zhí)行？

十三、應用系統(tǒng)日志

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

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

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

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

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

結(jié)論

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

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

這個故障看起來是和 IO/硬件/網(wǎng)絡(luò) 或者 系統(tǒng)配置(有問題的代碼、系統(tǒng)內(nèi)核調(diào)優(yōu), …)相關(guān)。

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

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

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

運維工作指導手冊

一、資源和業(yè)務規(guī)劃及申請

1、項目計劃書模板

2、背景和業(yè)務目標規(guī)劃

3、組織和人力資源規(guī)劃

4、硬件資源規(guī)劃

5、業(yè)務規(guī)劃

6、財務預算

二、組織和人力資源管理

1、管理職責

2、設(shè)置組織機構(gòu)(成立、任命、部門手冊、崗位職責

3、人力資源招聘

4、入職培訓和轉(zhuǎn)正

5、薪酬待遇

6、績效考核

7、人才培養(yǎng)和團隊建設(shè)

三、財務和行政資源管理

1、管理職責

2、硬件資源配置

3、費用和報銷管理

4、財務統(tǒng)計和核算

四、其他工作管理

1、作息制度

2、工作計劃和匯報制度

3、固定資產(chǎn)低值易耗品管理

4、工具管理

5、備品備件和耗材管理

6、實驗室管理

7、數(shù)據(jù)監(jiān)控中心管理

8、檔案室管理

9、收入管理

五、設(shè)備和基站移交

1、排查

2、檢測

3、比對驗收

4、設(shè)備整改和更換

5、交接

六、簽訂合同和新建、更換設(shè)備

1、明確建設(shè)要求

2、簽定合同

3、新建和更換設(shè)備

七、運營

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

2、制定巡檢計劃并執(zhí)行

3、確定數(shù)據(jù)監(jiān)控計劃并執(zhí)行

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

5、確定數(shù)據(jù)和工作報告計劃并執(zhí)行

6、確定關(guān)系維護計劃并執(zhí)行

八、附錄 流程和規(guī)章制度