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

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

以下事情發生在9月22日的8:45~11:30AM

周一早上，系統E上線的第一個早上，8:45分公司還沒有上班，致電專案經理A，詢問服務人員是否已經到位，得到的回答是

1. 項目組同事在7點鐘已經到達客戶辦公，利用客戶8點鐘上班前一個小時進行最後的生產系統測試；
2. 從8點上班到現在系統目前運行正常；
3. 項目組的同事已經分為三個部分的人員開展工作，同事cdw負責對系統進行健康監控，同事lq負責在QQ或者電話上回答問題，另外一個同事負責後續功能點的開發；

在瞭解完這些情況後，我要求項目組向我提供系統E的健康監控資料，主要是系統E目前的吞吐率，也就是平均每秒完成的請求數，專案經理A說等會監控後，用短訊通知我。

11:01分收到cdw同事以下的短訊：到目前為止，系統當前的會話數是126個，最高會話數是162個，總會話數是341個。

11:05分收到cdw同事的電話，我正在忙，告知等會回電。

11:30分左右，打電話給專案經理A，告知除了系統的會話數外，其實我們最關心的是系統的吞吐率，並發訪問量，也就是每秒鐘完成的請求數，可以從中看到系統的訪問量的多少，通過經驗值可以知道系統的繁忙程度以及啟動並執行正常程度。專案經理A說同事cdw正在通過控制台監控，還不太會如何從控制台上看到這些指標。我的回答是：OK，那好好學習如何看Weblogic控制台。

另外告知專案經理A，除了從系統的技術角度看系統的繁忙以及輸送量外，還可以從業務的角度看系統的輸送量，比如，早上建立的單據有多少單，處理完畢多少單，與上線前的舊系統對比環比趨勢如何？這些資料都能夠說明系統的運行情況。

專案經理A在電話裡回複，等他們進行資料收集後再告知我，目前系統的運行還一切正常。

 

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

周一的工作總是較為繁忙，一來也考慮到系統E剛上線，項目組同事還有一些服務的工作在進展，所以等到下午4點打電話詢問專案經理A系統的運行情況，回答是：上午和我通完電話後，大概12左右，系統又發生類似“死機”的現象了！該現象是由我方的監控人員發現的，剛好是在中午下班的時刻，所以我們很快就重啟服務恢複！

聽到專案經理A這麼說，我罵了專案經理A：

1. 發生了這樣重大的故障，為什麼發生了4個小時，而且是我電話才告訴我，如果我們忙的話，是不是準備將問題瞞下去！這種做法是溫水煮“青蛙”!#$%@#!$
2. 如果這個時候，使用者投訴我們，我們連事情都不知道，那是多麼的被動！
3. 我們的業主有知情權，雖然當時在中午吃飯的時間，使用者量也不大，我們監控及時，對故障的響應很快！但是，我們現在不能保證沒有下次，有下次的話，也不一定還會在系統較沉寂的時刻，所以我們必須知會業主，我們存在這種情況，但是我們正在嚴密監控！
4. 4個小時，證明公司還未能定義並且執行故障的升級服務流程，專案經理A領導Z知道了，Z的領導W和F還不知道，我們怎麼能及時調動資源進行危機處理呢！

我罵完後，專案經理A領導Z已經在2點半左右通知了架構組的同事dy，但是目前還沒有解決！我說好吧，當務之急，我馬上調動資源解決問題，另外繼續監控服務健康情況，專案經理A需要寫一個報告告知業主，這個事多難做也得做。（事後情況是專案經理A當天還是沒有告知業主，還是報了僥倖心理！）

和A通完電話後，和dy的領導F打電話，他說他也是才剛剛聽dy說這個事情，我說，由於沒有及時升級到我們，其實錯過了最好的跟蹤處理時機，鑒於以往已經發生的情況，我現在趕會公司，趕快就事情開展處理。今天我們只能算是“好彩”，剛好故障發生的時間不在業務繁忙時段，而且我們有備而來，及時恢複了，但是我們不能掉以輕心，因為下一次，我們不一定有這樣的“運氣”！

 

（補序：國慶前的一個周，是在緊張忙碌的節奏中度過，現在憑記憶以及手機的短訊、通話記錄整理回憶，希望能夠重構整個故事，順便預告一下，現世報其實是有的！）