背景：

XX市房地產勘查測繪所（以下簡稱“房產所”或者“客戶”）新業務辦公系統（以下簡稱“FCOA”或“新系統”）經過一年多的開發和測試，現在到了需要準備新系統上線的時候，以取代原有的辦公系統（以下簡稱舊系統），但是，新系統在2007-7-4日和5日上線的時候，遇到了一系列問題，最後不得不停止新系統，仍然切換到舊系統執行。面對這些問題，如何看待現有開發的新系統，以及如果認為新系統可行，如何制訂切實可行的上線實施方案，為本文討論的主要問題。

Gis-ver2005 是現在執行在房產所的一套業務辦公系統，處理市各大房屋測繪公司

Gis-ver2005對資料的業務處理流程舉例：

預售登記測繪：包括 “售初始登記”，“預售變更登記”，由大廳業務人員負責材料的登記；

預售業務審件：由測繪管理科科員進行材料的初步審查；

決定：有房產所領導對初步審查的材料進行決定，是否正確；

成果匯入：對正確的材料，將資料匯入到系統資料庫中；

單據輸出；給客戶列印回執單和通知單等

建委成果匯出：將資料庫中的資料匯出然後上傳給建委；

歸檔：對最有正確的業務進行歸檔操作。

對於實測業務（產權登記測繪），流程跟預測業務處理流程類似，也分為初始登記和變更登記，只是資料和單據的格式內容有所不同。

另外還有成果資料變更，實預測對應等業務，業務流程比較簡單此處不做詳細說明。

整個舊系統從功能上說基本滿足現有業務執行狀況，但是中間也伴隨著大量的維護工作。從整體介面風格上來看比較簡單，顯得不夠專業。

新系統除了滿足上面所說的各種業務功能外，還加入了以下一些功能：

公共資訊管理：如公告通知，政策法規，行業動態等公共類資訊，這些分類和內容都是可管理的，可自行設定和調整；

個人辦公：集成了原有gis-ver2.5中該部分內容；增加了通訊錄和網路磁碟模組。

另外，業務管理，大廳接待等模組集成了原

從系統功能架構方面來說，新系統加入了以下兩個大的功能：

工作流：所有業務的流轉均由工作流控制，包括業務的受理，轉交，回退，完成等。在介面表現上，只有當前操作員接收到了上一步流轉下來的業務，才可進行當前操作，最後轉交給下一步。業務的流轉方向由工作流型別事先定義好了。業務流轉給誰由許可權系統或者工作流本身控制。

許可權控制：新系統的所有模組都由許可權子系統控制，包括業務資訊和非業務資訊，跟工作流的關聯也比較緊密。許可權系統可以方便的定義操作員，許可權，角色等資訊，每個程式模組根據事先設定好的權值程式碼來判斷當前操作員是否具有該操作許可權。該許可權子系統實現了細粒度的許可權控制（按鈕級別）。

另外從流程上來說，新系統在業務受理階段即進行了資料匯入，取消了舊系統的“成果匯入”步驟。

從介面風格方面來說，新系統重新進行了設計，顯得跟專業，更易於操作。

舊系統：

採用了比較簡單的單層架構/雙層架構，很多業務邏輯在後臺頁面程式碼中處理；有少量程式碼，比如資料訪問程式碼，放到了單獨的程式程式碼中處理。

新系統：

採用了多層架構方式，將部分業務程式碼抽取到了單獨的業務層中處理，但是做的很不徹底，有大部分業務程式碼仍然沿襲了舊系統的模式。另外將資料訪問層單獨抽取了出來，但這部分元件主要是為工作流和許可權子系統服務的。

新舊系統採用了不同的資料訪問模式，舊系統大量採用了Oracle資料庫的特性，對錶的主鍵列的值採用Oracle的“序列”方式，每次插入一條資料的時候改序列值加一；新系統為了遮蔽底層資料庫的具體型別，採用了抽象資料訪問方式，在執行時指定資料庫型別，儘量採用跟具體資料庫無關的查詢方式，因此對錶主鍵的處理方式採用單獨建立一個“種子”表，由程式決定對主鍵值加一。

理論上這兩種資料訪問模式都不會有問題，但是當新舊系統過渡的時候，這成了一個嚴重的問題（後面會分析到）。

新舊系統雖然處理的業務型別沒有發生改變，但是兩者的功能無論從使用者方面還是設計者方面均發生了重大變化，主要表現為“工作流”是舊系統根本沒有東西，而且“許可權”管理也採用了全新的方式。

根據新舊系統的上述差異，為了確保系統順利“交割”，需要制定幾套升級方案：

新舊系統程式同時執行，共同使用一個數據庫

房產所的業務從受理到最後歸檔，一般都在5個工作日內，但有的也可能5個工作日以上，而且在正常工作日內，是不能停止接收新件的。因為新系統使用的資料庫是在舊系統的資料庫基礎上作了一些擴充套件，但是並沒有刪除過任何老系統表的欄位，所以從表結構上來說是向後相容的。為了讓舊系統中沒有處理完的業務繼續處理，可以把當前正在使用的業務資料完全複製到新系統的資料庫中，這樣理論上舊系統的程式就可以使用新系統的資料庫了。

在業務上，該方案的主要背景在於三點：

延續舊系統中沒有處理完的業務；

在舊系統中如果業務還沒有做完，需要變更業務資料；

新系統可以使用舊系統沒有處理完的資料。

方便查詢舊系統中正在處理的業務。

舊系統使用的老資料庫（以下簡稱 GIS庫）在新系統上線日停止使用，作為備份封存；

複製GIS 庫的資料到新系統的資料庫中（以下簡稱FCOA庫）；

修改舊系統程式所使用的資料庫為FCOA庫，使新舊系統使用同一個庫；

部署FCOA程式，使用FCOA庫；

新舊系統同時執行，舊系統中沒有完成的業務繼續在舊系統中處理，直到最後歸檔為止；新接收的業務從收件開始，完全在新系統中處理。

方案評價：

優點：

該方案可以使新舊系統的業務順利交接，對各種業務的處理不會造成影響，且不需要手工維護資料的一致性。

缺點：

新舊系統同時使用一個數據庫風險比較大，有可能發生兩個系統的資料互相干擾的情況。而且，不能保證業務人員不熟悉新系統操作的情況下出現業務無法辦理的情況。

新舊系統漸進式執行，分別各自使用自己的資料庫

該方案主要是基於確保資料的安全性，從物理上隔絕兩個系統對資料的相互干擾。而且，也不希望在舊系統中做過的業務重新在新系統中再做一次。

舊系統使用的GIS庫 新系統上線日繼續使用，但做一個備份儲存；

複製GIS 庫的資料到新系統的資料庫中（以下簡稱FCOA庫）；

部署FCOA程式，使用FCOA庫；

舊系統沒有做完的業務繼續在舊系統中處理，直到歸檔為止；

新接的業務完全在新系統中執行；

舊系統中原來沒有做完的業務做完以後，採用程式/手工方式將資料匯入到FCOA中；

舊系統中沒有做完的業務全部做完以後，封存GIS庫並作備份。

完成過渡，以後的業務全部在新系統中做。

方案評價：

優點：

可以確保老資料的安全性和準確性；

缺點：

首先，如果在舊系統的業務還沒有做完的情況下，業務發生變更，這時候只有等到該業務在舊系統中做完以後，繼續在舊系統中做變更業務；同時，在業務需要查詢的時候，不能方便的確定要查詢的資料再哪個庫中；

然後，在舊系統中後來做完的業務需要用程式/手工匯入到FCOA庫中，這一過程可能比較複雜而且易於出錯，需要再製定一個比較好的處理方案；

最後，同樣不能保證業務人員不熟悉新系統操作的情況下出現業務無法辦理的情況。

新舊系統同時執行，但新系統在最後上線前始終處於“試執行”階段。兩個系統分別各自使用自己的資料庫

該方案主要基於確保新舊系統的資料的穩定安全，克服因新系統在操作方式上的重大改變引起的可能的操作問題。同時，在新系統的試執行中，也能及早的發現問題而不至於業務的中斷處理。

複製GIS 庫的資料到新系統的資料庫中（以下簡稱FCOA庫）；

部署FCOA程式，使用FCOA庫；

舊系統程式正常使用，在過渡期繼續辦理業務；

新系統在“過渡期”內，每天/隔天隨機抽取舊系統中辦理過的業務，到新系統中重新辦理，作為測試對照；

在新系統試執行一段時間以後，根據新系統對業務處理的穩定性/正確性，何業務人員對新系統操作的熟練程度，決定何時結束“過渡期”；

過渡期結束，再採用方案一或者方案二，處理舊系統中沒有做完的業務。

方案評價：

優點：

採用試執行方案，可以在試執行中及早發現新系統中的問題，保證原有業務的正常執行；同時，系統經過一段時間的試執行，業務人員也能夠熟悉新系統，避免因為操作問題引起資料的丟失或錯誤。

缺點：

在試執行期間，業務人員可能會提出更多的改進需求，修改和實現需求的時間可能會影響上線的時間；在過渡期結束以後，同樣不可避免的會遇到方案一和方案二中的問題。

選擇一個業務相對較少的日期（根據房產所辦理業務的經驗推測一個合適的日期），在週末前只剩下少量未辦理完的業務，最後還是未辦理完的業務利用週末加班辦理完成，然後在下週一新系統正式上線。

新舊系統業務的延續是本方案提出的最主要動機，上述三套方案都不可避免的會遇到這個問題，但解決起來都不是很容易。採用“擇機上線”的方案，選擇一個業務量相對較少的日期作為新系統升級上線的日期可以避免前面的問題。這樣後續的業務全部在新系統中辦理，不會出現業務是否連貫的問題。

根據以往辦理業務的經驗，統計出一個比較合適的時間，選擇那天上線，或者根據當前所在周的星期五看沒有辦理完成的業務數量，決定下個週一新系統是否上線。

如果決定在下個週一新系統上線，舊系統使用的老資料庫（以下簡稱 GIS庫）在新系統上線日停止使用，作為備份封存；

複製GIS 庫的資料到新系統的資料庫中（以下簡稱FCOA庫）；

部署FCOA程式，使用FCOA庫；

在週一，業務人員完全使用新系統辦理各種業務。

方案評價：

優點：

由於業務事先已經全部在舊系統中辦理完成，避免了上述方案業務難以延續的缺點；

缺點：

需要預計和選擇業務比較少的日期，這個合適的日期可能比較難以選擇；

因為需要加班做完舊系統中沒有做完的業務，需要房產所領導的全力支援和房產所所有員工的理解和支援；

新系統上線以後，同樣有業務人員不熟悉新系統操作的情況，但可以採取上面的“試執行”方案來做好培訓。

對現有的舊系統程式進行“改良”，比如首先修改舊系統的介面風格，然後再逐步優化和完善程式碼，增加新的功能。

由於新系統使用工作流驅動業務，產生了業務無法正常延續的問題，而上述四套方案都難以實現，那麼只有對現有的舊系統進行逐步“改良”的方案了。

繼續使用舊系統辦理日常業務；

逐步修改介面風格，改善操作體驗；

優化程式碼結構和效率，逐步增加新功能。

方案評價：

優點：

本方案不涉及新舊系統升級的問題，是對原有系統的逐步“改良”過程，所以不會造成業務的延續問題。

缺點：

由於舊系統的介面沒有完全按照CSS風格理念來設計，所以要完全改變系統風格工作量還是比較大；

由於原來採用的是單層/雙層架構，所以程式碼的逐步分離和優化也是不小的工作，相當於重新設計一個系統；

在改良過程中，由於有“FCOA”的體驗，客戶也可能要求加入一些FCOA的操作方式，從而影響到原有系統的設計；

改良過程也有可能花費不少的時間；

放棄現有的FCOA，從開發時間和成本上來說也是一個不小的損失。

下面對五套方案的各項指標進行分析，最後總結出方案的可行性和綜合評價指數。

從上面幾套方案的對比分析，方案三具有最高的可行性；方案一和方案四都有較高的綜合評價指數，因為方案一已經具有實際的實施經驗，這是其他方案都不具備的優勢，方案四具有較大的操作空間，如果能夠得到客戶方的全力支援是一個不錯的選擇。方案五可能難以得到客戶的支援，故可行性比較低。

2007年7月4日（週三）和5日，主要考慮到避免業務前後延續的問題，我們實施了一號方案，新舊系統同時執行，舊系統繼續處理原來沒有做完的業務，而新的業務則完全在新系統中執行。開始執行後，主要發生了以下幾個問題和情況：

1老系統中實測/預測資料匯入不進去，經檢查，發現是新建立的舊系統跟新系統使用的同一個資料庫沒有建立Oracle的序列。把原來GIS庫的序列匯入到新庫（FCOA庫）中解決；

2新系統中看不到剛做的一個預測業務。經過檢查發現業務表等有記錄，但是工作流表沒有相關資料，懷疑可能是使用者不熟悉新系統，在收件過程完成的時候，沒有單擊系統的“完成”按鈕。但是客戶說這個功能已經培訓過，不可能犯這樣的錯誤；

3舊系統的建委資料包上穿不上去，經過檢查，發現新舊系統的兩筆業務使用了同一個樓棟序號。將舊系統的這筆業務回退到成果匯入，然後重新匯出建委包解決；

4在舊系統發現數筆業務根實際的材料不一致，初步判斷是上午資料庫沒有建立序列有關。這些發現的問題通過手工逐個解決。

5在排除問題的過程中，發現舊系統中成果匯入程式裡面一處致命的資料寫入方式，有可能嚴重干擾新系統的執行。

6在系統上線的第二日決定停止新系統的執行，新業務仍然有舊系統程式做，但是仍然發生了很多問題。

7在第二日晚上，決定全面停止新系統和舊系統的執行，將舊系統的資料恢復到兩天前正常的資料庫中去。

8在過後的兩天時間裡面，我們和客戶一起恢復資料，客戶在舊系統中重新錄入了4日和5日新做的業務。

問題根源：

經過反覆查詢錯誤原因，最後發現舊系統寫入資料獲取主鍵欄位值的時候採用了Oracle序列物件的特性；而新系統寫入資料採取的是單獨一個表存放主鍵種子的方式。有些重要的主鍵欄位，新系統沒有使用足夠大的主鍵種子數，導致獲取的值和舊系統的序列物件值相沖突。

另外，在舊系統的匯入程式中，存在下面一個致命的資料寫入方式：

//匯入樓盤表

Ssql="insert into Tb_houses(houseID,archID,houseNo,CellLinkSymbol,survey_SDate,survey_EDate,";

Ssql+="FinYear,struct,remarks,type,plan_BArea,plan_SArea,outWallApportType,SUBMITCOMPANY) values(seq_houses_id.nextval,";

。。。 。。。（此略）

//採用seq_houses_id.nextval獲取下一個樓盤序號

。。。 。。。（此略）

//取得新匯入資料的maxID

Ssql = "select max(houseID) as maxHOUSEID from Tb_houses";

DataSet dsmax = db.TransactionQuery(Ssql);

string maxHouseid = dsmax.Tables[0].Rows[0]["maxHOUSEID"].ToString();

。。。 。。。（此略）

上面的程式碼存在以下一些隱患：

如果幾個使用者同時匯入資料，houseID 將有可能產生併發衝突，如果houseID啟用了約束，那麼寫入將失敗；如果沒有啟用約束，那麼將有可能出現相同的houseID。（事實證明，沒有啟用約束）。

如果新系統也匯入了一筆業務（注：新系統在收件的時候就已經將業務資料全部匯入了），假設新系統對houseID 啟用了一個大得多的新種子數，那麼將發生上面的maxHouseid 根本不是前面剛剛寫入的那個seq_houses_id.nextval 值。這樣，該筆業務專案下的幾個樓棟都將有可能使用同一個HouseID 。最糟糕的是Tb_houses 表的主鍵houseID 沒有啟用唯一性約束，最終導致很多業務資料匯入出錯但沒有及時發現問題。

解決方案：

在插入資料之前，先執行select max(houseID) as maxHOUSEID from Tb_houses 命令，獲取當前表中最大的一個houseid值即可。同時，新系統該表的主鍵種子數預估一個遠大於當前max(houseID) 的數即不會導致衝突。

總結：

所以，一個良好的系統，設計是關鍵。如果在設計的時候就考慮到了上面的問題，那麼此次升級中遇到的該類問題根本就不應該發生。

（全文完）