IT系統(tǒng)故障排查標(biāo)準化流程手冊一、適用故障場景本手冊適用于企業(yè)IT系統(tǒng)各類故障的標(biāo)準化排查與處理，涵蓋以下典型場景：系統(tǒng)不可用：如業(yè)務(wù)系統(tǒng)無法登錄、頁面報錯502/503、數(shù)據(jù)庫連接失敗等導(dǎo)致業(yè)務(wù)中斷的情況；功能異常：如系統(tǒng)響應(yīng)緩慢、接口超時、服務(wù)器CPU/內(nèi)存/磁盤占用率持續(xù)過高影響用戶體驗；功能失效：如核心業(yè)務(wù)流程卡頓、數(shù)據(jù)同步失敗、第三方接口調(diào)用異常等模塊功能異常；數(shù)據(jù)異常：如數(shù)據(jù)丟失、重復(fù)、錯亂，或備份恢復(fù)失敗等數(shù)據(jù)相關(guān)問題；安全事件：如疑似賬號盜用、惡意攻擊、漏洞利用等需緊急響應(yīng)的安全類故障。二、標(biāo)準化故障排查流程（一）故障發(fā)覺與上報故障發(fā)覺監(jiān)控系統(tǒng)自動告警：通過Zabbix、Prometheus等工具觸發(fā)CPU、內(nèi)存、網(wǎng)絡(luò)流量等閾值告警時，值班運維人員需立即查看告警詳情；用戶反饋：通過客服、企業(yè)群、工單系統(tǒng)等渠道收到用戶反饋的故障現(xiàn)象時，需記錄故障發(fā)生時間、用戶操作路徑、錯誤提示等信息；主動巡檢：運維人員定期巡檢系統(tǒng)狀態(tài)時，發(fā)覺日志報錯、服務(wù)進程異常等情況，需立即標(biāo)記為待處理故障。故障上報值班人員確認故障后，10分鐘內(nèi)通過企業(yè)ITSM系統(tǒng)創(chuàng)建故障工單，填寫“故障編號-故障類型-發(fā)生時間-初步現(xiàn)象”，并根據(jù)影響范圍和嚴重程度劃分優(yōu)先級（P1-P4，P1為最高級，如全業(yè)務(wù)中斷）；優(yōu)先級P1/P2故障需立即通知運維主管及業(yè)務(wù)接口人，同步故障概況及初步影響；工單需明確“第一負責(zé)人”（一般為值班運維人員），全程跟蹤處理進度，保證信息傳遞暢通。（二）故障初步分析信息收集收集故障現(xiàn)場信息：包括系統(tǒng)截圖、錯誤日志（應(yīng)用日志、系統(tǒng)日志、數(shù)據(jù)庫日志）、用戶操作記錄、監(jiān)控數(shù)據(jù)曲線（如故障前后5分鐘的服務(wù)器功能指標(biāo)）；確認故障范圍：明確故障影響的具體業(yè)務(wù)模塊、用戶群體（如“僅華東區(qū)域用戶無法登錄”）、是否伴隨其他關(guān)聯(lián)系統(tǒng)異常。初步判斷基于收集的信息，快速定位故障可能層級：基礎(chǔ)設(shè)施層：服務(wù)器硬件故障（如磁盤壞道）、網(wǎng)絡(luò)中斷（如交換機宕機）、機房斷電等；平臺層：操作系統(tǒng)異常（如服務(wù)進程僵死）、中間件故障（如Tomcat啟動失?。?shù)據(jù)庫功能瓶頸（如鎖表、連接池滿）；應(yīng)用層：代碼BUG（如接口參數(shù)錯誤）、緩存失效（如Redis連接超時）、第三方服務(wù)依賴異常（如支付接口返回超時）；數(shù)據(jù)層：數(shù)據(jù)損壞、主從同步延遲、備份文件缺失等。若初步判斷無法明確層級，需立即啟動深度排查流程。（三）故障深度排查根據(jù)初步判斷的故障層級，分層級使用工具進行精準定位：1.基礎(chǔ)設(shè)施層排查硬件檢查：通過iDRAC/iLO等遠程管理工具查看服務(wù)器硬件狀態(tài)，檢查磁盤SMART信息、內(nèi)存錯誤日志、CPU溫度等；網(wǎng)絡(luò)連通性測試：使用ping、tracert、telnet命令測試目標(biāo)服務(wù)器端口可達性，如telnet192.168.1.1008080檢查應(yīng)用服務(wù)端口是否開放；網(wǎng)絡(luò)設(shè)備檢查：登錄交換機/路由器查看端口流量、錯誤包統(tǒng)計，確認是否存在網(wǎng)絡(luò)環(huán)路、帶寬擁塞等問題。2.平臺層排查操作系統(tǒng)檢查：使用top、htop查看進程資源占用，jps檢查Java進程狀態(tài)，df-h檢查磁盤空間是否不足；中間件檢查：對于Tomcat，查看catalina.out日志定位啟動失敗原因，通過JConsole監(jiān)控JVM內(nèi)存泄漏；對于Nginx，檢查error.log確認配置語法錯誤或upstream超時；數(shù)據(jù)庫檢查：通過showprocesslist查看MySQL連接狀態(tài)，使用slow.log定位慢查詢，執(zhí)行showmasterstatus檢查主從同步狀態(tài)。3.應(yīng)用層排查日志分析：使用ELK（Elasticsearch+Logstash+Kibana）或Splunk檢索應(yīng)用關(guān)鍵詞錯誤（如“NullPointerException”“TimeoutException”），定位具體代碼行或調(diào)用鏈；鏈路跟進：通過SkyWalking或Zipkin跟進接口調(diào)用路徑，確認是服務(wù)內(nèi)部異常還是下游依賴服務(wù)超時；壓力測試：若懷疑功能問題，使用JMeter模擬并發(fā)請求，觀察接口響應(yīng)時間、錯誤率是否隨負載升高而惡化。4.數(shù)據(jù)層排查數(shù)據(jù)一致性校驗：對比主庫與從庫數(shù)據(jù)差異，使用pt-table-checksum工具檢查MySQL數(shù)據(jù)一致性；備份文件驗證：嘗試恢復(fù)備份文件至測試環(huán)境，確認備份文件完整性及可恢復(fù)性；事務(wù)日志分析：通過MySQL的binlog或Oracle的redolog回放操作，定位數(shù)據(jù)異常發(fā)生的時間點及操作人。（四）解決方案實施臨時措施：針對緊急故障（如P1級），優(yōu)先實施臨時恢復(fù)方案，保障業(yè)務(wù)盡快運行：服務(wù)重啟：僵死進程或服務(wù)異常時，執(zhí)行systemctlrestarttomcat或/etc/init.d/nginxrestart；流量切換：使用F5或Nginx負載均衡將故障節(jié)點流量切至備用節(jié)點；數(shù)據(jù)回滾：若數(shù)據(jù)異常由誤操作導(dǎo)致，通過備份文件或binlog回滾至故障前狀態(tài)。根本解決：臨時措施生效后，48小時內(nèi)完成根因分析并實施永久解決方案：代碼修復(fù)：開發(fā)人員定位BUG后，提交代碼版本更新并部署至測試環(huán)境驗證；配置優(yōu)化：調(diào)整數(shù)據(jù)庫連接池大?。ㄈ鏼axActive:50）、JVM堆內(nèi)存參數(shù)（如-Xms2g-Xmx4g）等；硬件更換：確認硬件故障后，聯(lián)系供應(yīng)商更換故障磁盤、內(nèi)存等組件；第三方協(xié)調(diào)：若故障源于第三方服務(wù)（如短信接口），通過供應(yīng)商工單推動問題解決。方案審批：P1/P2級解決方案需經(jīng)運維主管及業(yè)務(wù)部門負責(zé)人審批后實施，P3/P4級由第一負責(zé)人評估后執(zhí)行。（五）故障驗證與復(fù)盤效果驗證功能驗證：在測試環(huán)境或灰度環(huán)境執(zhí)行解決方案后，模擬用戶操作路徑，確認故障現(xiàn)象已消除，核心功能（如登錄、下單、支付）恢復(fù)正常；功能驗證：通過監(jiān)控工具對比故障前后的系統(tǒng)功能指標(biāo)（如CPU使用率、接口響應(yīng)時間），確認未引入新的功能瓶頸；數(shù)據(jù)驗證：校驗修復(fù)后數(shù)據(jù)的完整性和一致性，保證無數(shù)據(jù)丟失或錯亂。復(fù)盤總結(jié)故障解決后24小時內(nèi)，由運維主管組織故障復(fù)盤會，參與人員包括第一負責(zé)人、開發(fā)、業(yè)務(wù)接口人等；復(fù)盤內(nèi)容包括：故障發(fā)生原因（根因分析）、處理過程中的不足（如響應(yīng)延遲、溝通不暢）、改進措施（如優(yōu)化監(jiān)控告警閾值、完善應(yīng)急預(yù)案）；編寫《故障復(fù)盤報告》，明確責(zé)任人和整改時限，同步至IT知識庫，避免同類問題重復(fù)發(fā)生。三、配套記錄模板模板1：IT故障初始記錄表字段名填寫說明示例故障編號ITSM系統(tǒng)自動，格式：FT+年月日+流水號（如FT2023901）FT2023901故障發(fā)生時間精確到分鐘（如2023-10-0114:30:00）2023-10-0114:30:00發(fā)覺渠道監(jiān)控告警/用戶反饋/主動巡檢監(jiān)控告警故障現(xiàn)象具體描述故障表現(xiàn)，避免模糊表述（如“系統(tǒng)很慢”改為“訂單接口響應(yīng)超時5秒”）訂單列表頁加載失敗，提示“500ServerError”影響范圍明確影響業(yè)務(wù)/用戶區(qū)域（如“華東區(qū)域用戶”“支付模塊”）全網(wǎng)用戶無法登錄嚴重程度P1（致命業(yè)務(wù)中斷）/P2（嚴重功能異常）/P3（輕微功能下降）/P4（不影響業(yè)務(wù)）P1第一負責(zé)人值班運維人員姓名（用*代替）張*初步處理措施已執(zhí)行的臨時操作（如“重啟Tomcat服務(wù)”）檢查Tomcat日志，暫無處理模板2：故障排查過程記錄表排查時間操作步驟使用工具/命令結(jié)果描述負責(zé)人14:35-14:40查看服務(wù)器CPU/內(nèi)存/磁盤使用率Zabbix監(jiān)控面板CPU使用率5%，內(nèi)存70%，磁盤使用率85%（/data分區(qū)不足）張*14:40-14:45檢查Tomcat應(yīng)用日志tail-fcatalina.out報錯“java.io.IOException:Nospaceleftondevice”張*14:45-14:55清理Tomcat臨時文件及過期日志rm-rf/tmp/*&&find/logs-name“*.log”-mtime+7-delete/data分區(qū)釋放空間20GB，磁盤使用率降至65%張*14:55-15:00重啟Tomcat服務(wù)systemctlrestarttomcat服務(wù)啟動成功，訪問訂單列表頁正常張*模板3：故障解決方案驗證表驗證項目驗證方法驗證結(jié)果（通過/不通過）驗證人驗證時間用戶登錄功能模擬5個不同區(qū)域用戶登錄系統(tǒng)通過李*2023-10-0115:30訂單接口功能JMeter并發(fā)100請求，持續(xù)10分鐘，觀察響應(yīng)時間平均響應(yīng)時間800ms，無錯誤李*2023-10-0115:45數(shù)據(jù)完整性對比故障前后訂單主表數(shù)據(jù)，檢查是否存在丟失或重復(fù)數(shù)據(jù)一致，無異常王*2023-10-0116:00四、關(guān)鍵操作提示安全規(guī)范：故障排查前需確認操作權(quán)限，避免越權(quán)訪問生產(chǎn)環(huán)境；涉及服務(wù)器或數(shù)據(jù)庫變更時，必須提前備份配置及數(shù)據(jù)；禁止在業(yè)務(wù)高峰期執(zhí)行高風(fēng)險操作（如重啟核心服務(wù)、修改數(shù)據(jù)庫結(jié)構(gòu)），確需執(zhí)行的需提前報批并通知業(yè)務(wù)方。溝通協(xié)作：故障處理過程中，第一負責(zé)人需每30分鐘在ITSM系統(tǒng)更新處理進度，重大進展（如臨時措施生效、根因定位）需即時同步相關(guān)方；若故障涉及多部門（如開發(fā)、網(wǎng)絡(luò)、安全），需每日召開簡短碰頭會，同步進展及下一步計劃。文檔記錄：所有操作步驟（包括臨時措施和最終解決方案）需詳細記錄在排查過程記錄表中，關(guān)鍵日志截圖需作為附件留存；復(fù)盤報告需明確“根因分類”（如代碼缺陷/配置錯誤/硬件故障/第三方原因