IT系統(tǒng)故障排查與維護手冊前言本手冊旨在為IT系統(tǒng)運維人員提供標準化的故障排查與維護操作指引，通過規(guī)范流程、明確責(zé)任、細化步驟，提升故障響應(yīng)效率與系統(tǒng)穩(wěn)定性，降低因操作不當引發(fā)的風(fēng)險。手冊內(nèi)容基于行業(yè)最佳實踐結(jié)合企業(yè)實際場景編制，適用于各類IT基礎(chǔ)設(shè)施（服務(wù)器、網(wǎng)絡(luò)設(shè)備、應(yīng)用系統(tǒng)等）的日常維護與異常處理，是運維團隊的核心操作參考指南。一、手冊適用范圍與核心價值（一）適用范圍本手冊適用于企業(yè)內(nèi)部IT系統(tǒng)的全生命周期維護，具體包括：硬件設(shè)備：服務(wù)器、存儲設(shè)備、網(wǎng)絡(luò)交換機/路由器、防火墻等；軟件系統(tǒng)：操作系統(tǒng)（WindowsServer/Linux）、數(shù)據(jù)庫（MySQL/Oracle）、中間件（Tomcat/Nginx）、業(yè)務(wù)應(yīng)用系統(tǒng)等；基礎(chǔ)設(shè)施：機房環(huán)境（供配電、溫濕度、機柜）、網(wǎng)絡(luò)鏈路（局域網(wǎng)/廣域網(wǎng)）、云服務(wù)資源（ECS/RDS等）的故障排查與日常維護。（二）核心價值標準化：統(tǒng)一故障處理流程，避免因人員經(jīng)驗差異導(dǎo)致操作遺漏；高效化：通過分步驟指引與模板化記錄，縮短故障定位與恢復(fù)時間；可追溯：規(guī)范維護文檔管理，為后續(xù)優(yōu)化與責(zé)任界定提供依據(jù)；風(fēng)險控制：明確安全操作要點，降低誤操作對系統(tǒng)造成二次損害的概率。二、故障標準化排查流程（一）故障發(fā)覺與初步判斷故障發(fā)覺渠道用戶反饋：通過客服系統(tǒng)、運維或業(yè)務(wù)部門上報，記錄故障現(xiàn)象（如“無法登錄系統(tǒng)”“頁面加載緩慢”）、影響范圍（如“僅銷售部門受影響”）、發(fā)生時間（精確到分鐘）；監(jiān)控系統(tǒng)告警：通過Zabbix、Prometheus等監(jiān)控平臺觸發(fā)閾值告警（如CPU使用率＞90%、磁盤空間剩余＜5%），同步記錄告警級別（P1-P4，P1為最高級，指核心業(yè)務(wù)中斷）、告警指標與設(shè)備信息；主動巡檢發(fā)覺：運維人員通過日常巡檢（如檢查服務(wù)器日志、網(wǎng)絡(luò)連通性）發(fā)覺潛在異常（如服務(wù)進程異常退出、網(wǎng)絡(luò)延遲突增）。初步判斷與分級根據(jù)故障影響范圍與緊急程度，按以下標準分級：P1級（緊急）：核心業(yè)務(wù)完全中斷（如數(shù)據(jù)庫不可用、支付系統(tǒng)故障），影響所有用戶，需30分鐘內(nèi)響應(yīng)；P2級（重要）：部分業(yè)務(wù)功能異常（如報表失敗、非核心模塊無法訪問），影響部分用戶，需2小時內(nèi)響應(yīng)；P3級（一般）：次要功能輕微異常（如頁面樣式錯亂、提示信息不準確），不影響核心業(yè)務(wù)，需4小時內(nèi)響應(yīng)；P4級（提示）：可自行恢復(fù)的臨時性異常（如偶發(fā)的緩存失效），需8小時內(nèi)記錄并觀察。（二）故障信息收集必備信息清單基本信息：故障發(fā)生時間、持續(xù)時間、影響業(yè)務(wù)/用戶數(shù)、是否已嘗試臨時解決措施；系統(tǒng)環(huán)境信息：設(shè)備型號/配置（如服務(wù)器型號、CPU/內(nèi)存規(guī)格）、操作系統(tǒng)版本（如CentOS7.9）、應(yīng)用版本（如V1.2.3）、網(wǎng)絡(luò)拓撲（故障設(shè)備在網(wǎng)絡(luò)中的位置）；現(xiàn)象與日志：具體錯誤提示（如“Connectionrefused”“ORA-00600”）、系統(tǒng)日志（/var/log/messages、Windows事件查看器）、應(yīng)用日志（Tomcatcatalina.out、業(yè)務(wù)系統(tǒng)操作日志）、監(jiān)控截圖（告警界面、功能趨勢圖）。信息收集方法遠程登錄：通過SSH、RDP等方式登錄故障設(shè)備，使用命令行工具收集信息（如Linux下用top查看進程狀態(tài)、netstat-tuln檢查端口占用；Windows下用tasklist查看進程、ping測試網(wǎng)絡(luò)連通性）；物理檢查：若涉及硬件故障（如服務(wù)器無法啟動），需現(xiàn)場檢查設(shè)備指示燈狀態(tài)（電源燈、硬盤燈）、是否有異響或焦味、線纜是否松動；工具輔助：使用Wireshark抓取網(wǎng)絡(luò)包分析流量異常，用df-h檢查磁盤使用率，用jps檢查Java進程狀態(tài)。（三）故障定位與原因分析分層排查法按網(wǎng)絡(luò)層→系統(tǒng)層→應(yīng)用層→數(shù)據(jù)層逐層定位，縮小故障范圍：網(wǎng)絡(luò)層：檢查物理鏈路（網(wǎng)線、光纖是否插牢）、網(wǎng)絡(luò)設(shè)備狀態(tài)（交換機端口是否UP、防火墻策略是否阻斷）、IP地址與DNS配置是否正確（使用ping、traceroute測試連通性）；系統(tǒng)層：檢查資源占用（CPU、內(nèi)存、磁盤I/O是否過高）、服務(wù)狀態(tài)（systemctlstatusnginx查看服務(wù)是否運行）、系統(tǒng)文件完整性（rpm-Va檢查Linux系統(tǒng)文件、sfc/scannow檢查Windows系統(tǒng)文件）；應(yīng)用層：檢查應(yīng)用進程是否存活、配置文件是否正確（如Nginx的nginx.conf、數(shù)據(jù)庫的f）、中間件日志是否有報錯（如Tomat啟動日志中的端口沖突提示）；數(shù)據(jù)層：檢查數(shù)據(jù)庫連接是否正常（mysql-hlocalhost-uroot-p測試連接）、表空間是否充足（SELECTtable_name,ROUND(((data_length+index_length)/1024/1024),2)ASsize_mbFROMinformation_schema.tables;）、數(shù)據(jù)同步狀態(tài)（主從數(shù)據(jù)庫的showslavestatus\G）。常見故障類型與定位要點無法訪問服務(wù)：優(yōu)先檢查網(wǎng)絡(luò)連通性→端口開放狀態(tài)→服務(wù)進程是否啟動；系統(tǒng)功能下降：分析CPU/內(nèi)存占用高的進程→檢查是否為惡意程序或資源泄漏→優(yōu)化系統(tǒng)參數(shù)（如調(diào)整JVM堆內(nèi)存、Linux內(nèi)核參數(shù)）；數(shù)據(jù)異常：確認數(shù)據(jù)操作時間點→檢查數(shù)據(jù)庫Binlog/WAL日志→排查是否有誤操作（如DELETE未加條件）→嘗試從備份恢復(fù)。（四）故障處理與驗證處理原則先備份再操作：對故障設(shè)備或數(shù)據(jù)實施操作前，必須進行完整備份（如數(shù)據(jù)庫全量備份、關(guān)鍵配置文件快照）；最小化干預(yù)：優(yōu)先采用臨時恢復(fù)措施（如重啟服務(wù)、切換備用設(shè)備），減少對系統(tǒng)的影響；保留操作痕跡：記錄每一步操作命令與時間（如2023-10-0115:30:00執(zhí)行systemctlrestartnginx），便于后續(xù)追溯。處理步驟臨時恢復(fù)：根據(jù)故障類型執(zhí)行對應(yīng)操作（如進程卡死則kill-9進程PID、磁盤空間不足則清理臨時文件rm-rf/tmp/*、數(shù)據(jù)庫主從故障則停止從庫并重新配置）；根因解決：針對故障原因?qū)嵤┯谰么胧ㄈ缟壌嬖诼┒吹能浖姹尽U容磁盤容量、調(diào)整網(wǎng)絡(luò)策略避免環(huán)路）；驗證測試：恢復(fù)后需進行全面驗證，包括功能測試（如用戶是否能正常登錄、數(shù)據(jù)是否能增刪改查）、功能測試（如系統(tǒng)響應(yīng)時間是否達標）、容錯測試（如再次觸發(fā)相同故障是否自動恢復(fù)）。（五）故障記錄與總結(jié)填寫故障記錄表（詳見模板一）內(nèi)容包括：故障ID、發(fā)生時間/結(jié)束時間、故障級別、影響業(yè)務(wù)、故障現(xiàn)象、原因分析、處理過程、責(zé)任人、驗證結(jié)果、改進建議。故障復(fù)盤會議P1/P2級故障需在解決后24小時內(nèi)組織復(fù)盤，由運維主管主持，參與人員包括系統(tǒng)管理員、開發(fā)工程師*、業(yè)務(wù)部門代表；復(fù)盤內(nèi)容：回顧故障處理流程是否規(guī)范、原因分析是否準確、是否存在操作疏漏、后續(xù)如何預(yù)防類似故障；輸出《故障復(fù)盤報告》，明確改進措施與責(zé)任人，更新至運維知識庫。三、系統(tǒng)規(guī)范化維護操作（一）日常巡檢巡檢周期：服務(wù)器、網(wǎng)絡(luò)設(shè)備每日巡檢1次（上午9:00）；業(yè)務(wù)系統(tǒng)每2小時巡檢1次（通過自動化監(jiān)控工具）；機房環(huán)境每日巡檢2次（8:00、18:00）。巡檢內(nèi)容與標準（詳見模板二《日常巡檢表》）硬件設(shè)備：服務(wù)器指示燈狀態(tài)（電源燈常綠、硬盤燈閃爍正常）、網(wǎng)線與光纖接口無松動、設(shè)備溫度（服務(wù)器進風(fēng)口溫度≤25℃）；系統(tǒng)資源：CPU使用率（平均＜70%）、內(nèi)存使用率（平均＜80%）、磁盤剩余空間（系統(tǒng)盤＞20%、數(shù)據(jù)盤＞10%）；服務(wù)狀態(tài)：核心進程（如Nginx、MySQL）存活、端口監(jiān)聽正常（netstat-tuln|grep端口號）、應(yīng)用響應(yīng)時間（＜2秒）；數(shù)據(jù)安全：數(shù)據(jù)庫備份任務(wù)成功執(zhí)行（檢查備份日志）、關(guān)鍵文件完整性（如配置文件MD5值比對）。異常處理：巡檢中發(fā)覺問題立即記錄，P1/P2級故障按故障流程處理，P3級故障納入當日維護計劃，P4級問題持續(xù)觀察并記錄趨勢。（二）定期維護系統(tǒng)補丁更新周期：操作系統(tǒng)補丁每月第2個周三更新（業(yè)務(wù)低峰期），應(yīng)用補丁發(fā)布后3個工作日內(nèi)完成測試與更新；流程：測試環(huán)境驗證→備份生產(chǎn)環(huán)境→分批次更新（先非核心服務(wù)器后核心服務(wù)器）→驗證功能與功能→記錄更新結(jié)果。數(shù)據(jù)備份與恢復(fù)演練備份策略：數(shù)據(jù)庫全量備份每日1次（凌晨2:00），增量備份每6小時1次（8:00/14:00/20:00）；配置文件每次修改后立即備份；備份數(shù)據(jù)保留30天；恢復(fù)演練：每月選取1份備份數(shù)據(jù)進行恢復(fù)測試（模擬數(shù)據(jù)丟失場景），驗證備份文件的完整性與可恢復(fù)性，填寫《數(shù)據(jù)恢復(fù)演練記錄表》（詳見模板三）。硬件維護服務(wù)器除塵：每季度1次，關(guān)閉電源后使用壓縮空氣清理服務(wù)器內(nèi)部灰塵，重點清理CPU散熱器、電源風(fēng)扇、內(nèi)存插槽；硬件更換：對于故障硬盤（通過SMART工具預(yù)警“Reallocated_Sector_Ct”閾值）、老化內(nèi)存（頻繁報ECC錯誤），需在業(yè)務(wù)低峰期（如周末）進行更換，更換前同步備份數(shù)據(jù)。（三）應(yīng)急演練演練周期：每季度組織1次綜合應(yīng)急演練（如服務(wù)器宕機、網(wǎng)絡(luò)中斷、數(shù)據(jù)丟失），每年開展1次跨部門協(xié)同演練（包含業(yè)務(wù)部門、IT部門、客服部門）。演練流程方案制定：運維主管*牽頭制定演練方案，明確演練目標（如“驗證主備切換時間≤5分鐘”）、場景設(shè)計（如“模擬主數(shù)據(jù)庫磁盤損壞”）、參與人員及職責(zé)；場景執(zhí)行：模擬故障發(fā)生（如通過腳本模擬數(shù)據(jù)庫宕機），運維人員按實際故障流程進行處置，記錄響應(yīng)時間、操作步驟、恢復(fù)效果；評估總結(jié)：演練后填寫《應(yīng)急演練評估表》（詳見模板四），評估內(nèi)容包括響應(yīng)及時性、操作規(guī)范性、團隊協(xié)作效率，輸出《演練改進報告》并更新應(yīng)急預(yù)案。四、常用記錄與計劃模板模板一：IT系統(tǒng)故障排查記錄表故障ID故障時間故障結(jié)束時間故障級別影響業(yè)務(wù)范圍FT20231001-0012023-10-0114:302023-10-0115:45P2銷售訂單無法提交故障現(xiàn)象描述銷售人員在提交訂單時，頁面提示“系統(tǒng)繁忙，請稍后重試”，重試3次后仍失敗，經(jīng)排查為訂單服務(wù)進程異常退出。信息收集1.監(jiān)控平臺告警：訂單服務(wù)服務(wù)器CPU使用率突升至95%，內(nèi)存占用達90%；2.應(yīng)用日志：/opt/order-app/logs/catalina.out中出現(xiàn)“OutOfMemoryError:Javaheapspace”；3.系統(tǒng)狀態(tài)：jps查看訂單進程已不存在。原因分析訂單服務(wù)在處理大額數(shù)據(jù)時，JVM堆內(nèi)存配置不足（-Xms512m-Xmx512m），導(dǎo)致內(nèi)存溢出進程崩潰。處理過程1.14:35備份訂單服務(wù)配置文件/opt/order-app/conf/server.xml；2.14:40修改JVM參數(shù)為-Xms1g-Xmx2g；3.14:42重啟訂單服務(wù)：systemctlrestartorder-service；4.14:45觀察監(jiān)控平臺，CPU/內(nèi)存使用率恢復(fù)正常，服務(wù)狀態(tài)為“Running”。驗證結(jié)果銷售人員正常提交訂單，測試10筆大額數(shù)據(jù)訂單均成功，系統(tǒng)響應(yīng)時間＜1秒。責(zé)任人系統(tǒng)管理員、開發(fā)工程師改進建議1.優(yōu)化訂單服務(wù)JVM參數(shù)，設(shè)置合理的堆內(nèi)存大??；2.增加內(nèi)存溢出告警監(jiān)控，提前預(yù)警風(fēng)險。模板二：IT系統(tǒng)日常巡檢表巡檢日期巡檢人員設(shè)備/系統(tǒng)類型巡檢項目巡檢標準巡檢結(jié)果處理意見2023-10-01張*核心數(shù)據(jù)庫服務(wù)器CPU使用率平均＜70%65%正常內(nèi)存使用率平均＜80%75%正常磁盤剩余空間系統(tǒng)盤＞20%25%正常數(shù)據(jù)庫服務(wù)狀態(tài)進程存活，端口3306監(jiān)聽正常正常2023-10-01李*網(wǎng)絡(luò)核心交換機設(shè)備溫度＜40℃38℃正常端口狀態(tài)關(guān)鍵端口UP，無錯誤包正常正常背板帶寬使用率＜70%50%正常模板三：數(shù)據(jù)恢復(fù)演練記錄表演練日期演練人員備份文件名稱備份時間恢復(fù)場景恢復(fù)步驟恢復(fù)耗時驗證結(jié)果2023-09-28王、趙mysql_full_20230927.sql2023-09-2702:00模擬訂單表數(shù)據(jù)誤刪除1.停止MySQL服務(wù)；2.刪除現(xiàn)有訂單表；3.導(dǎo)入備份文件；4.重啟MySQL服務(wù)15分鐘訂單表數(shù)據(jù)完整，業(yè)務(wù)功能正常模板四：應(yīng)急演練評估表演練日期演練場景參與人員響應(yīng)時間操作規(guī)范性（1-5分）團隊協(xié)作（1-5分）存在問題改進措施2023-09-30主服務(wù)器宕機切換系統(tǒng)、網(wǎng)絡(luò)、業(yè)務(wù)*4分20秒43備機啟動后配置未同步，導(dǎo)致部分功能不可用建立配置自動同步機制，演練前檢查備機配置五、操作安全與風(fēng)險規(guī)避要點（一）硬件操作安全服務(wù)器、網(wǎng)絡(luò)設(shè)備等硬件維護前，必須確認設(shè)備已斷電（電源插頭拔下），并等待電容完全放電（≥5分鐘）；操作人員需佩戴防靜電手環(huán)，避免靜電損壞電子元件；更換硬件時，輕拿輕放，避免用力過猛導(dǎo)致接口或插槽損壞；機房內(nèi)禁止攜帶金屬物品（如鑰匙、手表），防止短路風(fēng)險。（二）軟件操作安全修改配置文件前，務(wù)必備份原文件（命令：cp/etc/nginx/nginx.conf/etc/nginx/nginx.conf.bak），并記錄修改內(nèi)容與原因；生產(chǎn)環(huán)境執(zhí)行高危操作（如rm-rf、format）前，需雙人復(fù)核（操作人+審核人），確認命令無誤；禁止在生產(chǎn)環(huán)境直接使用root賬戶執(zhí)行業(yè)務(wù)操作，應(yīng)創(chuàng)建普通用戶并分配最小權(quán)限（如通過sudo授權(quán)）；安裝第三方軟件時，需通過官方渠道獲取安裝包，并驗證MD5值，避免植入惡意程序。（三）數(shù)據(jù)安全與隱私保護備份數(shù)據(jù)需加密存儲（使用AES-256加密算法），密鑰由運維主管與安全專員分別保管，避免單點泄露風(fēng)險；嚴禁將生產(chǎn)數(shù)據(jù)導(dǎo)出至個人設(shè)備或外部網(wǎng)絡(luò)，確因工作需要需經(jīng)部門負責(zé)人*審批，并全程留痕；故障排查中涉及的敏感信息（如用戶身份證號、交易記錄），需在記錄文檔中脫敏處理（如用*代替部分內(nèi)容）；廢棄的存儲介質(zhì)（如硬盤、U盤）需使用消磁設(shè)備徹底銷毀，或物理破壞（如砸碎盤片），防止數(shù)據(jù)恢復(fù)泄露。（四）溝通協(xié)作規(guī)范P1/P2級故障發(fā)生時，運維人員需在10分鐘內(nèi)通知運維主管及業(yè)務(wù)部門接口人，每30分鐘同步一次處理進展；跨部門協(xié)作（如開發(fā)、網(wǎng)絡(luò)、安全）時，明確接口人（如開發(fā)工程師*負責(zé)應(yīng)用層問題排查），避免多頭溝通導(dǎo)致效率低下；故障解決后，需在24小時內(nèi)向受影響業(yè)務(wù)部門發(fā)送《故障處理報告》，說明故障原因、處理過程及預(yù)防措施。六、附錄（一）常用排查命令參考系統(tǒng)類型功能命令示例Linux查看進程ps-ef|grepnginxLinux查看端口占用netstat-tuln|grep80Linux查看磁盤使