發生在眼前的故事：不做好最壞的打算，往往事情就會去到最壞的地步（五）

續《發生在眼前的故事：不做好最壞的打算，往往事情就會去到最壞的地步（四）》

以下事情發生在9月23日的10:10~12:00AM

比dy早5分鐘到了現場，先進行分工協助，不要因為出現了故障而亂了手腳！

1. 統一思想，專案經理A、負責電話和QQ服務的同事不用分心，繼續維持服務，並且還要保證服務的品質不能下降！
2. 如果我們再次提前發現出現疑似“死機”的事故徵兆，繼續保持目前故障公告流程，讓業主以及終端使用者及時知道；
3. 如果是終端使用者或者業主發現問題，一定先做好對終端使用者和業主的致歉、溝通工作，並且告知技術人員正在跟進此問題，今天確實發生了這種情況給大家的工作造成了不便，並告知系統在10分鐘後可以正常使用。（因為目前都是採用重啟的恢複手段，所以可以這樣告知使用者）；
4. 有關的最新處理情況，我們會主動發布給服務小組。

dy已經到現場，知道他肯定還挂念著java的connection pooling的問題，安排他落實connection pooling的參數化配置情況。

接著和負責健康監控的cdw溝通，跟進他的監控方法發現可以進行改進，以往檢查是否可以訪問登入頁面的監控方法只能確定、斷定故障是否發生，我們需要對故障是否即將發生進行預警。火線培訓cdw、wxy同事Weblogic的監控方法，讓同事知道我們還能夠提前預警，讓負責服務的同事知道，可能未來將有故障發生，並且將監控工作轉wxy同事負責。

（下周我們要開展針對Weblogic伺服器的系統監控培訓，讓更多的同事具備常規檢查能力）

和cdw跟進本日的服務日誌、訪問日誌、程式日誌等，希望定位故障發生之前或者確切發生時，業主或者使用者當時訪問什麼、進行什麼業務處理。從服務日誌上可以看到發生的情況與昨日9月22日發生的情況一致，錯誤資訊雷同；從訪問日誌上看發現沒有包含請求耗時time-taken的訪問日誌，可以斷定可能訪問日誌還沒有完全正確設定，並且讓dy和專案經理A調整了日誌設定。

接著，和cdw一起對日誌進行分析，通過疑似“死機”時的訪問日誌分析，雖然沒有包含請求耗時time-taken，但是可以發現三點定性的結論：

1. 從日誌上可以看到本日有一些業主、終端使用者從6點半就開始使用我們的IT系統；
2. 從肉眼對日誌上分析，可以看到每分鐘這些業主、終端使用者的訪問量不是很大，因為日誌記錄了每個訪問者的IP地址，結合cdw給我們的解釋，可以看到並發的請求數不是很大；
3. 特別是在疑似“死機”的時刻，也可以確定當時的並發量不是很大，因為日誌記錄在解決“繁忙”的疑似“死機”時刻，並發的訪問量也不是很大，IP地址在日誌記錄中，基本上還是保持順序記錄。

從上面的基本分析，如果分析是正確，那麼我們從新開啟的time-taken的訪問日誌上，就可以找到造成效能隱患、阻塞訪問隱患、死結訪問隱患的業務功能列表，通過大約40分鐘的日誌分析，我們從包含time-taken的access log分析出10個可疑的功能點。

能得到以上的部分結論，並且找出10個可疑功能點，來源於以往經驗和體會：

1. 出現疑似“死機”狀態的系統一般是出現了一些併發症，不要輕易地認為已經找到癥結，要象CSI一樣細緻進行“屍體解剖”，多懷疑可能的原因，找到證據去推翻或者證明可疑的原因！這種思維導向，往往更加有效，救火和現在對付金融危機的救市一樣，要打組合拳。
2. 不要小看每一秒的改進，10個可疑的功能點，每個功能的耗時都是幾秒層級，每減少一秒，意味著可以有更多的服務資源可以服務其它請求！

（補充：如何分析出10個可疑功能點，內容涉及較多技術術語，可待以後再出CSI版本的故障分析報告，但是心態和方法是一樣。）