2018年10月10日凌晨2點接到信調值班員電話，單位資訊運維統一監管（I6XXX）系統報警顯示公司門戶和網站系統性能檢測報警，頁面訪問響應時長和模擬登入功能異常，實際情況是網站和門戶系統執行正常，稍有寬心，現在單位執行指標考核太變態，壓力太大啊。立即開始協調人員進行故障排查，涉及門戶、網站、效能檢測、I6000系統運維人員，還有可能涉及網路，現在系統部署結構都很複雜，想想頭大，現梳理一下整個故障排查處理過程，總結經驗教訓，給運維人生留下一絲絲痕跡。

   一、系統部署架構及資料流分析

          由於是二級單位且規模較小（與5年前相比，主要的都一級部署了，混的越來越差了），所有監控都由總部統一檢測，自己沒有許可權，很被動啊。本單位的系統如門戶、網站、資訊通訊管理等系統在本地部署，在本地部署一套檢測點，檢測的資料統一上報到總部，總部效能檢測彙總資料到運維統一監管系統集中展示，總部值班人員24小時值班監控，本地也有值班人員訪問總部運維統一監管系統進行24小時檢測。

           二、故障排查分析

 10月10日凌晨發生的告警是間斷性的，一會正常一會異常，參與效能檢測的系統有多套，只有門戶、網站系統間斷性的，對問題判斷帶來一定的難度。根據經驗進行排查吧。

1. 先由門戶、網站管理員到現場進行系統排查，同時協調效能檢測運維人員配合，確認入口網站系統本身是正常執行的，然後確認每一個檢測URL是否正常，確認沒有問題。
2. 排查效能檢測伺服器，確認其中一臺伺服器的作業系統執行緩慢，初步確認可能存問題，但是其他幾個系統沒有問題，不是很確認，所以同時進行其他方面排查。
3. 排查備份系統，確認備份系統是否影響帶網路頻寬，此前有過類似的問題，備份任務執行時佔用了大部分頻寬，導致網路很慢，最終確認備份正常。
4. 使用分析工具，通過效能分析系統進行分析，發現效能檢測伺服器請求門戶和完整URL響應時長很長，但是使用者終端訪問門戶、網站都很正常，初步確定是效能檢測伺服器有問題。
5. 決定重啟效能檢測伺服器，觀察再看看，經過一段時間執行各檢測點都正常。

開始分析效能檢測伺服器執行日誌，發現是效能檢測伺服器需要呼叫windows的WMI服務，而該服務按照安全整改要求已經關閉了，長時間呼叫失敗，耗盡系統資源導致作業系統執行緩慢，所以出現間歇性異常。

        三、經驗總結

1. 該問題排查時間較長，定位問題過程不明確，涉及到關聯其他系統，導致整個處理過程持續近10個小時以上，還好上級監控值班人員對此項執行指標考核較鬆，未記錄執行異常事件。
2. 長時間未發生資訊系統異常事件，人員思想意識有鬆懈，出現電話聯絡不上運維人員的情況。效能檢測系統正式執行在2個月左右，運維人員對系統整個執行、配置情況不太熟，耽誤了問題的排查時間。
3. 由於非正常的資訊化專案實施的系統，整個要求和管理上不到位，平時沒有對該伺服器進行巡檢和監控，作業系統執行緩慢而沒有發現。