背景：
XX市房地產勘查測繪所（以下簡稱“房產所”或者“客戶”）新業務辦公系統（以下簡稱“FCOA”或“新系統”）經過一年多的開發和測試，現在到了需要準備新系統上線的時候，以取代原有的辦公系統（以下簡稱舊系統），但是，新系統在2007-7-4日和5日上線的時候，遇到了一系列問題，最後不得不停止新系統，仍然切換到舊系統運行。面對這些問題，如何看待現有開發的新系統，以及如果認爲新系統可行，如何制訂切實可行的上線實施方案，爲本文討論的主要問題。
一、舊系統簡介：
Gis-ver2005 是現在運行在房產所的一套業務辦公系統，處理市各大房屋測繪公司/單位提交的房屋測繪檔案和數據，這些數據稱爲“匯交數據”，房產所負責這些材料的審查和備案。房產所是一個重要的行政審批單位，其管理裏的數據具有嚴格的經濟和社會意義，業務不允許中斷和出錯。
Gis-ver2005對數據的業務處理流程舉例：
預售登記測繪：包括 “售初始登記”，“預售變更登記”，由大廳業務人員負責材料的登記；
預售業務審件：由測繪管理科科員進行材料的初步審查；
決定：有房產所領導對初步審查的材料進行決定，是否正確；
成果導入：對正確的材料，將數據導入到系統數據庫中；
單據輸出；給客戶打印回執單和通知單等
建委成果導出：將數據庫中的數據導出然後上傳給建委；
歸檔：對最有正確的業務進行歸檔操作。
對於實測業務（產權登記測繪），流程跟預測業務處理流程類似，也分爲初始登記和變更登記，只是數據和單據的格式內容有所不同。
另外還有成果數據變更，實預測對應等業務，業務流程比較簡單此處不做詳細說明。
整個舊系統從功能上說基本滿足現有業務運行狀況，但是中間也伴隨着大量的維護工作。從整體界面風格上來看比較簡單，顯得不夠專業。
二、新系統簡介：
新系統除了滿足上面所說的各種業務功能外，還加入了以下一些功能：
公共信息管理：如公告通知，政策法規，行業動態等公共類信息，這些分類和內容都是可管理的，可自行設置和調整；
個人辦公：集成了原有gis-ver2.5中該部分內容；增加了通訊錄和網絡磁盤模塊。
另外，業務管理，大廳接待等模塊集成了原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) 的數即不會導致衝突。
總結：
所以，一個良好的系統，設計是關鍵。如果在設計的時候就考慮到了上面的問題，那麼此次升級中遇到的該類問題根本就不應該發生。
（全文完）