報喜不報憂造就了資訊不對稱，讓我們面對項目風險無法及時做出反應

原以為博文《風險意識，決定了是事半功倍，還是事倍功半，甚至決定了...》中一文提到項目O已經完成升級，上周四從郵件看到了負責基礎架構的同事Y郵件，談及該項目在我們應用系統升級後，出現資料庫驅動程式不相容的情況，導致資料庫連接泄漏而緩衝池耗盡的情況，從Y的郵件上看到情況已經處理完畢。

周一下午，我以QA身份參加了抽查了該項目的項目周會，結果很不幸，聽到的使用者“無可奈何”投訴，說項目O從上周三10月30日開始應用升級後，就不斷造成系統死機，而我方處理問題的速度很慢，到周一還沒有解決問題，周一上午11點多還再次出現死機情況。

經過細緻瞭解，瞭解情況如下：

1. 10月29日周三升級後，已經出現問題，但是系統沒有進行升級復原；
2. 10月30日周四項目組進行系統進行部門核心模組的復原，並且知會了基礎架構部的同事Y要求支援，Y並且進行問題排查，認為原因已經找到，並且進行修複，完畢後發送了郵件知會了大家，包括我在內；
3. 10月31日周五上午10點左右，再次出現死機情況，證明30日晚的排查判定可能是錯誤的，此時Y趕到現場，初步排查後覺得更改資料來源的使用方式；
4. 11月1日周六進行使用方式的替換測試和實施工作，由於環境原因，沒有進行效能測試，但是從周六使用方式上看，看似正常；
5. 11月2日周日下午，項目組同事再次進行監控，發現系統正常；
6. 11月3日周一上午一早進行監控，發現系統存在工作不正常的情況，此時伺服器上的資源非常緊張，中午進行了參數的調整；
7. 11月4日下午就到了我去現場開會了。

周五的情況，項目組有將情況知會部門經理，但是周六、周日以及周一的情況就沒有及時知會。我去抽查的會前，資訊只是到了周四的情況，所以從這個角度，資訊不對稱，讓我們面對項目風險無法及時做出反應，容易錯過協助救援的最佳時機。

會後，除了和專案經理L將工作協調安排外，做的第一件事情就是知會相關干係人，並且馬上通知Y，要求他馬上到現場解決問題。在這個方面，Y沒有最終解決問題，又並沒有及時上報，也是有責任的。

協調完資源後，經過昨晚和周二的處理，目前情況已經被控制，還需要觀察一段時間，才能認定是否完全解決問題。Y在周二給我發的郵件中，談及他的事後總結：

1. 解決一個故障，要從多個方面去最佳化，分工合作，打組合拳；
2. 做好最壞打算。

Y不是第一次處理這類事情，只是以往跟隨我們處理情況，知道這些道理和自己親自操刀，體會是很不一樣的！但是，留給我們的思考：

1. 一定需要這種血的代價才能讓人成長嗎？
2. 如果剛好不是我抽查到這個項目，那麼怎麼辦呢？

管理中心必須重視起這個問題了，CMMi過了級，是不是就應該著手馬上對這些流程、監控加大力度監管呢？現在，我算是瞭解gcd管理、治理國家的難度了，如果體制上、組織上養成報喜不報憂，一定是面對風險無法及時做出反應的！還好，我們的業主不可能會象那些收封口費的記者，至少他現在還肯在會上告訴我們，投訴我們就是是投資我們！