在很多公司中，IT、資料中心、業務系統一出故障，會有很多人被叫到作戰室（就是一個為了解決該問題，而把所有相關人員集中在一起的一個會議室）, 但是對於這個問題他們是否可以修復, 是否他們應該負有責任, 經常沒有線索.
「證據」(基礎架構監控資料, 日誌檔案, 使用者投訴等等) 表明了症狀, 但是與 root cause 無關. 只有很多的日誌資訊和高階別的告警並不會給你與這個問題根因真正相關的答案.
為了遠離這種場景, 真正的「證據」應該是什麼? 你應該問什麼問題?
是一個使用者抱怨還是所有使用者都受影響?
「只是」CEO 抱怨一個問題, 因為一份 BI 報告在他的老 IE7 上無法工作? 或者「只是」使用聯通上網的終端使用者? 瞭解一個問題發生在非常小的使用者群, 還是說全中國的使用者都受到影響, 是重中之重.
交付鏈(如: CDN, 第三方, ISP, 雲供應商, 託管服務, 手機網路)有問題麼?
當代 web 應用、移動服務、網際網路服務、O2O業務等依賴一長串交付鏈的服務. 知道每個的影響會告訴你是否應該檢查自己的資料中心, 還是說應該打電話給服務商.
關鍵事務是否受影響?
是否關鍵業務比如保險投保受到影響? 還是說報錯的頁面早已經不用了? 你需要監控最關鍵的業務效能.
是這個應用的問題麼?
應用很複雜. 如果你知道問題是發生在這個應用裡, 你然後需要進行故障隔離, 然後讓對應的開發和架構師定位問題效率更高.
這個問題與糟糕的程式碼有關麼?
如果客戶使用載入緩慢、體驗很差，應用響應時間很慢, 第一個問題應該是是否與糟糕的程式碼有關. 你需要分析程式碼級別的效能熱點來找到是否原因是低效的演算法還是缺乏程式碼和架構的最佳實踐.
這個問題在虛擬機器、容器、中介軟體...裡麼?
如果虛擬機器(如:VMware, EC2...)或你的容器(Docker)或你的中介軟體或你的應用執行時（如：tomcat）沒有正確的 size, 或者和其他虛擬機器及容器存在資源爭用也可能引起效能問題. 如果你知道虛擬機器的效能影響到了應用, 你會知道引入 VM 專家, 而不是應用開發, 來解決這個問題.
容器、中介軟體、應用執行時同理。
是基礎架構導致的問題麼?
如果不是應用自身問題, 而是因為 app 執行在資源不足的基礎架構上會怎樣? 如果需要執行垃圾回收的 CPU 因為超用導致不可用會怎樣? 那麼是時候考慮拆分應用或擴充套件基礎架構了.
是應用伺服器的問題麼?
因為不正確的配置或錯誤的部署, 應用伺服器也可能是效能問題的原因. 正確的資源池(執行緒, 資料來源等)大小, 安全配置或日誌引數都會影響效能. 如果發現是應用伺服器的問題, 如果是商業應用伺服器，你需要聯絡 IBM, Oracle, 微軟專家；如果是開源應用伺服器，你需要聯絡貴司的相關中介軟體專家.
總結
有了這些問題的答案, 你可以消除作戰室, 迅速定位問題根源, 最佳化並找到解決方案. 所以不需要 20 人的作戰室, 你只需要3個人 - 一個開發, 一個測試, 一個運維 - 評估詳細的效能 insight, 並引入需要的專家. 完美!
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.