經歷了三個來月的忙碌工作，我們團隊的問題，終於在這次客戶現場實施過程中暴漏了出來。

    2013年7月15日晚坐臥鋪第二天(16日)到達DEF城市，直接來到客戶現場做系統現場實施工作(稱呼為A系統)。第一天倒還相對的平靜，可後續的事情一件接一件，讓我又一次感受到天底下沒有任何兩次出差經歷是相同的。

    由於客戶沒有提供單獨的伺服器，與我們公司另外一個軟體系統(稱呼為B系統)部署在同一臺伺服器上。由於我部署期間該臺伺服器上的sql server伺服器突然異常終止服務了，而且出現了三次，客戶直接找到我，問我是不是因為我部署系統導致B系統不能正常工作了，一聽這話，我就猜到了接下來的工作不會好開展，顯然公司商務上跟客戶談的不是很融洽。後來我跟客戶的解釋了好一通，並告知他們以後B系統再遇到類似問題，可以先從排查伺服器上sql server服務是否異常終止服務進行排查。初步定為為sql server2005沒有安裝好，導致不定時的會終止服務。計劃重灌資料庫。這一關勉強還算簡單的過了，可下一件事情就比較曲折了。

   客戶的資料庫伺服器是sql server2000的版本，而且電腦硬體也稍微的差一些。由於我們針對的這個行業每年都是6月1日至10月1日是軟體使用的高峰期。我剛把A系統涉及到的三個iis應用加一個gis服務部署完成後，客戶又找了過來，問是不是我們架設A系統影響到了資料庫伺服器，他們以前的舊軟體執行一段時間就卡死了。面對這個問題，我做了如下幾點分析：第一：sql伺服器上是僅僅是對應的庫訪問卡還是所有的庫都卡(因為有一個主庫是幾乎所有行業軟體都要訪問的)，後來經過與客戶一起證實是單庫造成的卡死現象。第二：打開了sql server自帶的事件檢視器，把需要監視的專案勾選上做實時監視分析，後來發現我們系統A確實存在一些空的資料庫操作行為，而且一秒內就有多條請求，由於A系統底層使用是spring.net原因在客戶現場也沒顧上細找。由於考慮是在客戶現場處理問題拖太久對公司影響不好，我果斷的採用了我們公司另外一個產品C(標準業務資料庫庫資料實時同步軟體)在應用程式伺服器上把資料庫伺服器上的業務資料庫實時的交換到這新建的一個數據庫服務上。把A系統對原來業務資料庫的影響幾乎降為了零，在用資料庫事件監視器看A系統沒有再向2000庫發起過任何請求。但是2000庫還是會造成他們業務系統頓的現場，但是現在他們舊系統還勉強能執行。我把sql server事件檢視器的使用辦法也交教會了客戶，好讓他們自己學會分析造成卡頓的原因，而且客戶因此也認可了即使沒有A系統執行，他們的庫也會消耗記憶體不斷增加，導致他們的舊軟體出現卡頓的現象。  由此現象推斷出，即使sql server耗掉記憶體相同的情況下，對應用程式的影響也會有不同的。至於現有A系統的優化調整，在後續分享。

    隨後A系統的部署過程更是“噁心他媽看到噁心回家，噁心到家了”，暴漏了我們團隊一件又一件的問題，現在20來人的團隊一團亂。團隊管理上的問題是導致這次失敗經歷的最直接原因，釋出版本回歸測試嚴重不足；測試過程專案負責人沒有參與；形成的成果物也是不忍心看。成果物管理混亂，根本達不到成果物管理的最低要求；文件缺乏，給團隊造成巨大的成本隱患，東西都在程式設計師腦子裡，是件巨可怕的事情；程式碼走查做的嚴重不到位，三令五申的編碼要求都無法得到落實；日誌的記錄更是有一搭沒一搭的，零零散散，導致出錯後沒有日誌輸出，對問題的排查造成了巨大的影響；等等問題都暴漏的那麼的明顯。造成了原本應該在1到2日就可以完成的系統部署及與客戶交流工作，現在經過四天的持續加班還是沒能拿出理想的釋出版本。

   通過此次現場實施系統經歷，遇到了一些問題，暴漏了一些問題。遇到問題、暴漏問題都不可怕。關鍵是後續的總結與團隊調整一定要跟進。後續的跟進等出差回到單位後陸續的進行，有成果了我會分享出來，望有相似發展經歷的軟體團隊引以為戒。

     希望能與更多的軟體同行進行交流，交換想法，共同進步。