風險意識，決定了是事半功倍，還是事倍功半，甚至決定了…

序：

昨日吃飯，路上遇到了同事L，談起他以及他所在項目小組工作，L告訴我他的一個真實的、新鮮出爐的故事，雖然L以前也聽過我有關於部署實施的培訓課，但是他說在工作中真正在吃了虧之後，才能更好地體會到其中的問題。
情境：

故事實際發生在上周四周五。計劃的事情如下：

1. 同事L的項目組服務於業主Z，業主Z計劃在周四晚上開始停機，對IT基礎支援環境的Oracle資料庫進行升級，計劃從9i升級到10g。IT基礎環境的維護工作，做為長期的外包服務，業主Z是交給了第三方服務商J負責進行。
2. 同事L的項目組根據計劃，藉著此次IT系統升級停機，順便進行應用系統O的模組S升級。L之前已經和服務商J的同事交流過。
3. 按照商定的計劃，周四晚上進行升級，服務商J在周五淩晨2點完成DB升級，之後由我們進行應用系統O的功能性驗證和模組S的升級。

真正的結果，實際情況如下：

1. 到了淩晨2點，當同事L詢問服務商J是否已經完成升級時，答案是還沒有完成。
2. 到了淩晨3點，回答還是沒有完成。
3. 到了淩晨4點，回答依然。
4. 直到淩晨6點半，DB終於升級成功。
5. 離8點業主人員開始上班，只剩下1個半小時，測試應用系統O，發現運行不正常，經過同事的排查，最終發現是應用的驅動程式不匹配，但是此時已經到了9點半。
6. 周五早上大家都很累了，沒有進行模組S升級，本身沒有正常運行，周五中午團隊就回家休息了，直到周六大家休息回來後才接著再幹，最終完成了任務。

分析：

我相信很多同事對這個案例的分析也不會特別複雜。不外乎就象我的評論如下：

1. 象這種IT基礎架構的調整，從以往實踐工作來看，是屬於風險是比較高的工作。一般都會安排在周六、日進行。想起10年前，當年我還在做學徒的年代，跟者DBA周六、日對Sybase資料庫進行升級，資料量的大小現在看來當然不算什麼了不起，不就是幾個G，但是在當年一台機器才只有16M記憶體來看，那可是一個大型的資料庫。
2. 我不會在制定計劃的時候，將自己的任務可行性建立在他人一個風險度很高的任務上，而不存懷疑，這是非常危險的。在此情境下，我不會安排我的工作計劃在淩晨2點開始。
3. 退一萬步，即便是我也象L一樣，將任務安排在淩晨2點開始，那我在計劃的時候一定也會定義好失敗條件（部署終止條件）。而不會讓事情發展為2點，delay到6點半。根據以往的部署培訓，定義好系統部署的終止條件是非常有必要的。
4. 退一萬步，即便是我也象L一樣，將任務安排在淩晨2點開始，我一定不會讓同事都在現場一直苦等，我會讓同事先回家休息，淩晨才根據情況到現場集中。
5. 根據以往部署經驗，特別是越大、越重要的系統，越是需要進行演練。當然同事會告訴我，資料庫資料很大的，好幾個T。呵呵，越是VLDB，你都不演練一下，哪能準確進行耗時估計，不要連周六、日都無法升級完畢？！我希望同事養成習慣，不要管系統的規模的大小，進行事前演練，會讓你成為老手。

L君經曆了這樣的事情後，當然對以上原則的認識是加深了很多。他告訴我，哎喲，很多工作還是太相信人了。我告訴他，風險意識不是要告訴你不相信人、不能信任人，如果是這樣是和和諧社會的建設相抵觸的！也沒有一本書這麼說。風險意識是要讓我們認清自己/團隊的處境，對全域有基本的把握，風險意識的出發點是懷疑自己、不是懷疑別人，才能看到自己沒有盲點，存在懷疑是為了保證團隊的利益，希望他能夠從職業的角度去思考。

體會：

但願L以後能不再犯同樣的錯誤決定，但是人真的能夠從自己以往的錯誤中吸取教訓嗎？很多事情就是說容易，做起來難，俺嶽父告誡我：“說易行難”是這個道理。金融風暴之前，身邊有的人，把公司關了，把房子押了，拿了錢投到股市；也有人，拿著股票去抵押，再套現接著投入股市。現在事後看來，真的很瘋狂。但是理智告訴我，這絕對不是人類第一次，也不是最後一次。