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

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

以下事情發生在9月22日的4:30~5:00PM

在分別和專案經理A、架構組同事dy的領導F通完電話後，馬上通知負責業務的同事以及相關的領導，讓項目的相關干係人瞭解情況，並且知道技術部門正在處理相關事宜。（後續需要QA將故障處理流程納入改進計劃）

回到公司後，和架構組同事dy以及領導F開會，瞭解兩點辦接到故障後截至到目前我們掌握的情況和以及做的相關處理，從溝通中知道目前只是從QQ上接受到項目組傳送過來的伺服器作業記錄server log，還缺少伺服器的訪問日誌access log，也沒有拿到疑似“死機”時刻的Thread Dump，從掌握的server log上可以看到懷疑是connection pooling的問題！

我告誡同事，機器和人其實也挺像的，當機器已經疑似“死機”的情況下，一定已經有很多併發症，表象下面可能掩蓋了真象，而且真象可能不只一點！我們可以只懷疑connection pooling的問題，但是必須從多個方面的線索來證明，目前還沒有拿到12點故障發生時的其他日誌，妄下判斷沒有意義，更何況connection pooling的配置問題上次已經發生，項目組應該有了經驗，存在可能性項目組又再忽略了問題，這個可以去電確認，現在趕快拿到其他日誌，要求5點半之前分析出一些可能的蛛絲馬跡！

 

以下事情發生在9月22日的5:30~6:00PM

快解決下班的時候，去詢問了同事dy的工作進展，得到的回覆如下：

1. 項目組部署上線的時候，為了效能最佳化，關閉了系統的access log，所以沒有得到今天啟動並執行訪問日誌；
2. 項目組在中午12點左右疑似“死機”時，項目組進行了Thread Dump，但是在nohup的重新導向輸出結果中沒有Thread Dump的內容；
3. 已經和項目組同事確認檢查connection pooling的版本，懷疑存在串連沒有釋放的情況發生，造成線程掛起，最終導致weblogic掛起；
4. 從server log上，還可以看到有錯誤資訊，顯示可能Weblogic沒有被正常關閉，又重新啟動了Weblogic，懷疑Weblogic運行不正常。

我說沒有一本書說為了效能最佳化，就要關閉access log，那麼奧運網站、新浪、網易這些訪問量比我們大多的網站，都沒有access log嗎？人家是全部關掉access log呢，還是有選擇地進行access log呢？還有，現在的懷疑都有可能，但是我們要講證據，關鍵是那我下一步的行動計劃是什嗎？得到回答如下：

1. 告知項目組開啟Weblogic http access 的日誌，並且配置了日誌格式，在日誌中記錄請求處理時間以便下次發生時分析；
2. 告知項目組練習Thread dump 的使用，確認能夠通過當前操作擷取Thread dump的日誌；
3. 建議針對本次上線新增的功能進行壓力測試，看是否能夠重現問題；

對於dy的回答，我的回應如下：

1. 你沒有做好最壞的打算！今天我們“好彩”在不繁忙時段出現問題，明天不一定有這樣的運氣，只是告知項目組練習使用，能確保明天再發生的時候，項目組就已經會並且能做到嗎？
2. 如果明天在使用者高峰時出現問題，項目組一定是緊急重新啟動，越快越好地重新恢複處理，剛才說的這些動作在疑似“死機”情況下，假如項目組都已經正確掌握並且操作，需要執行多少時間，你知道嗎？
3. 我的要求是，明天你到現場去，去現場感受壓力，做好最壞的打算，出現問題的時候，力保能夠獲得一手的資料！

做以上的決定，來源與以下的幾點經驗體會：

1. 法官與偵探：項目組找SDU去救火，我們的工作思維還是慢條斯理，看似專家，其實心態不對，“把資料呈上來吧”的法官老爺姿態是不是不對呢？為了分析問題、定位問題和解決問題，應該像偵探一樣去找各種可能的線索，說起偵探，誰聽說過不重視現場證據、不去現場的偵探！
2. 醫生與醫患：我們罵醫生沒有職業操守和敬業精神，到底什麼才是？！地震其實告訴我們答案，感同身受，醫者父母心，說的就是這個道理。項目組找SDU，我們的解決辦法好像是“你還沒有流那麼多血，如果多了有生命危險，我們就馬上做手術”——摘自一個多月前親耳聽到博士醫生對病人說的話！
3. 服務意識：沒有了服務意識，下次誰還再來找你，SDU飛虎隊不是安出來的名堂，是要靠打出來的威信。做管理是這樣，接電話做服務也是這樣，寫程式做UI也一樣，寫架構做介面也是一樣，沒有服務意識，能做好嗎？