IT系統(tǒng)故障排查流程指南一、適用場景與觸發(fā)條件本流程適用于各類IT系統(tǒng)（包括但不限于業(yè)務系統(tǒng)、服務器、網(wǎng)絡設備、存儲系統(tǒng)、數(shù)據(jù)庫等）在運行過程中出現(xiàn)異常時的標準化排查工作。具體觸發(fā)場景包括但不限于：系統(tǒng)功能異常：業(yè)務模塊無法訪問、操作失敗、數(shù)據(jù)返回錯誤（如頁面報錯、接口超時、交易中斷等）；功能驟降：系統(tǒng)響應緩慢、卡頓，服務器CPU/內存/磁盤IO/網(wǎng)絡帶寬等資源利用率持續(xù)異常升高；服務中斷：系統(tǒng)完全無法訪問（如網(wǎng)站無法打開、APP無法登錄、數(shù)據(jù)庫連接失敗等）；安全告警：檢測到異常登錄、病毒入侵、數(shù)據(jù)泄露、網(wǎng)絡攻擊等安全事件；用戶批量投訴：同一時間段內收到多個用戶關于同一系統(tǒng)問題的反饋；主動巡檢發(fā)覺：通過日常監(jiān)控、日志審計等手段發(fā)覺潛在故障風險（如磁盤空間不足、證書過期、服務進程異常等）。二、標準化故障排查步驟詳解（一）故障信息收集與初步記錄目標：全面、準確捕獲故障基礎信息，為后續(xù)分析提供依據(jù)，避免信息遺漏導致排查偏差。故障基本信息登記通過故障管理平臺、電話、郵件等渠道接收故障信息，記錄以下內容：故障發(fā)生時間（精確到分鐘，如“2024-05-2014:30”）；故障觸發(fā)場景（如“用戶登錄時”“數(shù)據(jù)批量導入時”“系統(tǒng)啟動時”）；故障現(xiàn)象描述（具體錯誤提示、異常表現(xiàn)，如“提交按鈕后頁面彈出‘500InternalServerError’”）；影響范圍（受影響用戶數(shù)、業(yè)務模塊、地域范圍，如“華東區(qū)域用戶無法訪問訂單模塊”）；報障人信息（姓名、聯(lián)系方式，如“*工，138”）；故障是否可復現(xiàn)（如“每次登錄必現(xiàn)”“偶現(xiàn)，平均每小時1次”）。輔助信息收集若故障涉及特定操作，要求報障人提供復現(xiàn)步驟（詳細到每一步操作）；調取系統(tǒng)監(jiān)控截圖（如CPU使用率、響應時間曲線）、錯誤日志片段（截取關鍵錯誤信息，如堆棧跟蹤）；記錄故障發(fā)生前的近期變更（如系統(tǒng)版本更新、配置調整、數(shù)據(jù)遷移、安全補丁安裝等）。（二）故障影響評估與分級目標：根據(jù)故障對業(yè)務的影響程度，確定處理優(yōu)先級，合理調配資源。故障等級劃分標準等級定義標志性特征P1（緊急）核心業(yè)務中斷，造成重大損失或廣泛負面影響全局系統(tǒng)不可用、核心交易停滯、用戶投訴量激增（如100+用戶/小時）、安全事件導致數(shù)據(jù)泄露P2（重要）部分業(yè)務功能異常，影響局部用戶體驗，但核心業(yè)務可運行非核心模塊（如報表、統(tǒng)計）無法使用、功能下降（響應超時率＞30%）、部分用戶無法訪問P3（一般）邊緣功能異?；蚺及l(fā)問題，對業(yè)務影響較小個別用戶反饋問題、非核心頁面樣式錯亂、日志提示輕微警告（如磁盤使用率＞80%但未影響業(yè)務）P4（低危）信息收集或優(yōu)化類問題，無實際業(yè)務影響咨詢類問題、操作建議、監(jiān)控指標異常但無業(yè)務影響分級處理要求P1級：15分鐘內啟動應急響應，故障處理人（*工程師）需立即到場，1小時內提交初步處理方案，4小時內恢復核心業(yè)務；P2級：30分鐘內響應，2小時內定位根因，8小時內解決或提供臨時workaround；P3級：2小時內響應，1個工作日內解決；P4級：1個工作日內響應，納入常規(guī)優(yōu)化任務。（三）故障類型初步判斷目標：基于收集的信息，快速鎖定故障方向（硬件/軟件/網(wǎng)絡/數(shù)據(jù)/安全等），避免盲目排查。常見故障類型及判斷依據(jù)硬件故障：服務器/網(wǎng)絡設備指示燈異常（如紅燈頻繁閃爍）、硬件報錯日志（如磁盤SMART錯誤、內存故障報警）、物理設備無法啟動（如服務器黑屏、網(wǎng)絡端口down）；軟件故障：應用進程崩潰、服務無法啟動、數(shù)據(jù)庫報錯（如連接數(shù)耗盡、死鎖）、中間件異常（如Tomcat啟動失敗、Redis連接超時）；網(wǎng)絡故障：無法ping通目標IP、端口不通（telnet失?。?、網(wǎng)絡延遲高（ping值＞200ms）、丟包率＞5%、DNS解析異常；數(shù)據(jù)故障：數(shù)據(jù)丟失、數(shù)據(jù)不一致（如訂單金額與實際不符）、數(shù)據(jù)庫功能驟降（如慢查詢導致鎖表）、備份失??；安全故障：異常IP登錄、病毒文件告警、權限被篡改、敏感數(shù)據(jù)泄露痕跡。輔助判斷工具硬件：服務器廠商管理工具（如iDRAC、iLO）、硬件檢測軟件（如MemTest）；軟件：應用日志（Tomcatcatalina.out、Nginxerror.log）、數(shù)據(jù)庫日志（Oraclealert.log、MySQLslowquerylog）、進程監(jiān)控工具（top、taskmgr）；網(wǎng)絡：ping、tracert、telnet、netstat、Wireshark抓包分析；數(shù)據(jù)：數(shù)據(jù)庫監(jiān)控工具（如Prometheus+Grafana、Datadog）、數(shù)據(jù)校驗腳本。（四）深入定位與根因分析目標：通過工具測試、日志分析、環(huán)境比對等方法，精準定位故障直接原因和根本原因。分層排查策略（從外到內、從簡到繁）應用層：檢查應用進程狀態(tài)（是否存活、CPU/內存占用）、接口響應狀態(tài)（調用第三方接口是否成功）、配置文件（是否正確修改，如數(shù)據(jù)庫連接參數(shù)、緩存地址）；示例：若用戶反饋“登錄失敗”，需檢查應用日志中“登錄模塊”是否有“密碼錯誤”“用戶不存在”或“數(shù)據(jù)庫連接超時”等關鍵詞，并驗證數(shù)據(jù)庫用戶表數(shù)據(jù)是否正常。中間件層：檢查服務容器（如Tomcat、Nginx）配置（端口沖突、線程池設置）、集群狀態(tài)（負載均衡是否正常、節(jié)點是否存活）、緩存服務（Redis/Memcached是否滿載、連接數(shù)是否超限）；示例：若頁面加載緩慢，需排查Nginx是否配置了正確的upstream節(jié)點，或Redis緩存是否存在大量key過期失效。系統(tǒng)層：檢查服務器資源（CPU是否被某個進程長時間占用、內存是否溢出、磁盤空間是否不足）、系統(tǒng)日志（/var/log/messages、Windows事件查看器）、內核參數(shù)（如文件句柄數(shù)限制、最大連接數(shù)）；示例：若服務器頻繁宕機，需通過dmesg命令查看內核日志是否有“硬件錯誤”“內存溢出”等記錄，或使用top定位高CPU進程。網(wǎng)絡層：檢查網(wǎng)絡連通性（本地到目標服務器、跨網(wǎng)段連通性）、端口開放狀態(tài)（防火墻規(guī)則、安全組配置）、帶寬使用情況（是否被異常流量占用）；示例：若無法訪問外部業(yè)務系統(tǒng)，需排查本地防火墻是否放行了目標端口，或通過mtr定位網(wǎng)絡中斷節(jié)點。數(shù)據(jù)層：檢查數(shù)據(jù)庫狀態(tài)（主從復制是否延遲、表空間是否滿鎖、索引是否失效）、數(shù)據(jù)一致性（對比主從庫、緩存與數(shù)據(jù)庫數(shù)據(jù)）、備份文件完整性；示例：若出現(xiàn)“數(shù)據(jù)丟失”，需先確認是否為誤操作，通過binlog日志回滾數(shù)據(jù)，或從備份庫恢復。根因分析（5Why法）對定位到的直接原因追問“為什么”，直至找到根本原因。示例：故障現(xiàn)象“訂單提交失敗”→直接原因“數(shù)據(jù)庫連接超時”→追問“為什么連接超時”→“數(shù)據(jù)庫連接池耗盡”→追問“為什么連接池耗盡”→“未及時釋放無效連接”→根本原因“代碼中未對關閉連接的異常進行處理，導致連接泄漏”。（五）解決方案制定與執(zhí)行目標：根據(jù)根因，制定針對性解決方案，優(yōu)先恢復業(yè)務，再優(yōu)化根治。解決方案優(yōu)先級臨時方案：快速恢復業(yè)務，適用于P1/P2級故障（如重啟服務、切換備用節(jié)點、調整閾值限制）；永久方案：徹底解決故障，適用于P2/P3/P4級故障（如修復代碼bug、更換硬件設備、優(yōu)化配置參數(shù)）。解決方案執(zhí)行規(guī)范變更管理：執(zhí)行方案前需在變更管理平臺提交申請（注明變更內容、風險、回滾計劃），經(jīng)運維負責人（*經(jīng)理）審批后實施；風險控制：高風險操作（如數(shù)據(jù)庫修改、系統(tǒng)重啟）需在測試環(huán)境驗證，并準備回滾方案（如配置備份、數(shù)據(jù)快照）；操作記錄：詳細記錄每一步操作步驟、執(zhí)行時間、操作人（如“14:50*工執(zhí)行systemctlrestartnginx命令”）。常見故障解決方案示例場景1：應用進程崩潰→操作：檢查日志確認崩潰原因（如內存溢出），重啟進程（nohupjava-jarapp.jar&），若內存溢出則優(yōu)化代碼或調整JVM參數(shù)；場景2：磁盤空間不足→操作：清理臨時文件（rm-rf/tmp/*），清理日志文件（>/var/log/app.log），擴展磁盤空間（若為云服務器則擴容磁盤）；場景3：網(wǎng)絡不通→操作：檢查物理鏈路（網(wǎng)線是否松動）、防火墻規(guī)則（iptables-L）、安全組配置（云平臺控制臺檢查），開放對應端口。（六）解決效果驗證與業(yè)務恢復目標：確認故障已解決，業(yè)務恢復正常，避免遺留問題。驗證維度功能驗證：復現(xiàn)故障場景，確認功能可正常使用（如“重新登錄系統(tǒng)，成功進入首頁”）；功能驗證：監(jiān)控關鍵指標（響應時間、吞吐量、資源利用率），確認恢復至正常范圍（如“頁面響應時間＜2s，CPU使用率＜70%”）；穩(wěn)定性驗證：持續(xù)監(jiān)控30分鐘以上，確認無異常復現(xiàn)（如“無進程崩潰、無新錯誤日志”）；業(yè)務驗證：關聯(lián)業(yè)務流程測試（如“登錄→下單→支付→物流查詢”全流程正常）。用戶通知故障解決后，需通過郵件、企業(yè)等方式向受影響用戶發(fā)送通知（如“訂單系統(tǒng)故障已修復，可正常使用”）；若故障導致業(yè)務數(shù)據(jù)異常（如訂單重復、金額錯誤），需同步數(shù)據(jù)修復方案及預計完成時間。（七）故障總結與知識沉淀目標：復盤故障處理過程，提煉經(jīng)驗教訓，完善知識庫，避免同類問題重復發(fā)生。總結內容故障根因分析（最終確認的根本原因，如“Redis緩存穿透導致數(shù)據(jù)庫壓力過大”）；處理過程評估（哪些步驟高效/低效，如“日志分析工具使用熟練，但變更審批流程耗時過長”）；遺留問題（未完全解決的隱患，如“需優(yōu)化代碼中的連接池管理，預計下個版本上線”）；改進措施（預防同類故障的建議，如“增加Redis緩存預熱機制、設置數(shù)據(jù)庫慢查詢告警”）。知識沉淀將故障處理過程、根因、解決方案整理成《故障案例文檔》，至知識庫；更新監(jiān)控指標（如新增“Redis緩存命中率”“數(shù)據(jù)庫連接池使用率”監(jiān)控）；修訂應急預案（如調整“數(shù)據(jù)庫主從切換”觸發(fā)條件）。三、故障排查記錄模板故障基本信息故障編號IT-20240520-001故障名稱訂單系統(tǒng)提交失敗故障發(fā)生時間2024-05-2014:30故障級別P2（重要）影響范圍華東區(qū)域所有用戶無法提交訂單報障人*工（138）現(xiàn)象描述用戶“提交訂單”按鈕后，頁面提示“500InternalServerError”，訂單未是否可復現(xiàn)100%復現(xiàn)排查過程記錄步驟操作內容1.信息收集獲取用戶復現(xiàn)步驟（登錄→選擇商品→填寫地址→提交），導出Nginx錯誤日志2.初步判斷分析錯誤日志，疑似數(shù)據(jù)庫事務異常3.深入定位*工程師通過showengineinnodbstatus檢查，發(fā)覺事務未提交導致鎖表4.解決方案執(zhí)行回滾未提交事務，優(yōu)化批量導入腳本（添加事務提交邏輯）5.效果驗證復現(xiàn)提交訂單流程，監(jiān)控數(shù)據(jù)庫連接數(shù)和事務狀態(tài)總結與后續(xù)根本原因批量訂單導入腳本未提交事務，導致數(shù)據(jù)庫鎖表，阻塞訂單提交接口遺留問題無（批量導入腳本已修復）改進措施1.增加數(shù)據(jù)庫事務超時告警；2.批量操作限制在低峰期執(zhí)行；3.加強代碼review知識庫訂單系統(tǒng)事務異常處理案例負責人*工完成時間2024-05-2016:00四、關鍵注意事項與風險規(guī)避（一）保持溝通協(xié)同，避免信息壁壘故障處理過程中，需及時向運維負責人（經(jīng)理）、業(yè)務接口人（產(chǎn)品經(jīng)理）同步進展（如“已定位到數(shù)據(jù)庫鎖表，預計30分鐘內解決”）；跨團隊協(xié)作時（如開發(fā)、運維、數(shù)據(jù)庫、網(wǎng)絡），指定唯一接口人（如*工），避免多人對接導致信息混亂。（二）避免操作盲動，優(yōu)先保護現(xiàn)場未明確根因前，禁止盲目重啟服務器、刪除文件或修改核心配置（如數(shù)據(jù)庫表結構），避免擴大故障范圍；高風險操作前，必須備份當前配置（如Nginx配置文件、數(shù)據(jù)庫表），保證可快速回滾。（三）全程記錄操作，便于復盤追溯詳細記錄每一步排查操作、執(zhí)行命令、返回結果（如“14:50執(zhí)行showprocesslist，發(fā)覺10個未提交事務”）；保留關鍵日志文件（如錯誤日志、監(jiān)控截圖），作為故障分析的依據(jù)。（四）優(yōu)先業(yè)務恢復，再優(yōu)化根治P1/P2級故障需“先恢復、后優(yōu)化”，可通過臨時方案（如重啟服務、切換備用節(jié)點）快速恢復業(yè)務，避免業(yè)務長時間中斷；永久優(yōu)化方案需在業(yè)務穩(wěn)定后實施，避免邊修復邊優(yōu)化引發(fā)二次故障。（五）注重根因分析，避免重復故障故障解決后，必須通過5Why法、魚骨圖等工具分析根本原因，而非僅解決表面問題（如“重啟服務解決崩潰”后，需分析崩潰原因并修復代碼）；定期組織故障復盤會，邀請開發(fā)、運維、業(yè)務團隊參與，共享經(jīng)驗教訓。（六）及時上