今天談下業務系統割接上線方案的內容，對於大專案來說，業務系統在建設完成並UAT測試通過後，最終的割接上線往往是一個系統工程，不能有絲毫的馬虎。

系統割接上線概述

臨近專案上線，最近週末都在加班處理上線前的資料初始化，系統環境部署，系統引數配置，服務部署，許可權設定等基礎工作。對於系統上線，最重要的還是要有詳細的上線和割接計劃，同時有完整的檢查單CheckList，否則就很容易遺漏關鍵事項。

對於ESB平臺來講，由於本身就不儲存資料，同時服務本身執行無狀態，因此對於平臺的上線並沒有太多的期初資料初始化問題。更多的是類似接入系統，服務元資料，服務授權和安全等基礎元資料匯入，系統配置設定等相關事宜。這比業務系統上線和割接本身要簡單的多。

一個大專案的上線，需要多方，多個業務系統配合，步調一致才能夠完成。而對於ESB平臺來說，更多要做的還是進行服務註冊和接入，釋出最終的服務目錄，同時對接入系統和服務授權資訊進行校驗，確保這些資訊在正式生產環境開始執行的時候不發現錯誤或問題。

如果對於業務系統的上線或割接，大家都比較清楚，需要有詳細的上線割接計劃和方案，方案中必須還包括出現問題後的回退方案。同時對於系統上線，需要考慮期初靜態資料的初始化，動態流程中資料的匯入，系統配置等各項工作，這些都是在生產環境部署完成後必須進行初始化和檢查的關鍵工作。

一個系統如果是進行版本更新或割接，那麼一定會強調在割接過程中的平滑性，即在系統上線或割接後不能對老的業務，已有的業務流程造成影響。同時在割接過程中希望的是能夠最短時間完成，建設停機消耗和等待時間。

如果能夠做到應用系統本身的熱部署，或者或灰度釋出往往更優。

系統割接上線，從自身系統需要考慮對已有功能的向下相容性，從外部系統協同角度，需要考慮在割接完成後自身提供介面服務的註冊，已經割接完成後自身業務系統消費的服務是否能夠正常提供。這些都必須步調一致來完成，否則就很容易出現由於各級時間差導致的各個業務系統基礎資料不一致，控制邏輯不同等問題。

對於系統割接上線完成後就是正式的生產環境，如果要在生產環境進行最終的系統功能驗證往往直接會影響到業務，也可能影響到基礎資料的不一致。而這個時候常見的做法主要有：

其一就是將生產環境的應用和資料再複製回測試環境，然後再測試環境進行模擬生產環境的進一步驗證；其次就是在割接完成後必須要提前對消費的服務進行連通性側設驗證，確保在生產環境割接和部署完成後能夠正確的消費到外部系統的服務。

對於已經上線的業務系統，在網際網路領域更加強調灰度釋出能力，而實際上可以看到對於ESB匯流排專案，仍然可借鑑灰度釋出的思想，先根據省份或服務提供方進行灰度釋出，在驗證來沒有問題在進行英語程式部署包的全面部署和釋出。

割接上線關鍵內容準備

下面再談下系統割接上線內容準備的一些關鍵點。

第一就是生產環境安裝和部署手冊

這裡面實際是包括兩個方面內容，一個是標準的資料庫和應用中介軟體的安裝，一個是應用程式的部署，服務的部署。對於資料庫和中介軟體的安裝和基礎配置，資料庫和應用中介軟體的引數調優等，往往應該提前就很早做完。而實際上線都是指的應用和服務部署。

對於應用和服務部署，最重要的就是基於持續整合的思路，應該是將UAT環境測試透過的部署包遷移到生產環境進行部署，整個部署包不再進行重新編譯構建，而只是應該修改相關的配置檔案和引數設定。這樣可以確保部署到生產環境的應用和程式是測試環境測試透過的版本。

而實際我們在做專案的時候，往往在交維前各個環境都是我們自己管理和部署，不一定形成了很完整的文件，導致這個環境部署工作很隨意，這也是導致後續生產環境部署後出現問題的一個原因。

對於IT管理和治理比較規範的企業而言，往往有嚴格的版本釋出和上線流程，即使是對於全新專案生產環境的上線也不能由乙方自己去操作，必須填寫上線申請單，提供安裝指令碼和部署包，部署詳細步驟說明，轉由交付IT運維人員進行操作。在這種情況下往往上線過程會更加嚴謹受控。

第二就是資料初始化指令碼

對於應用的資料初始化指令碼實際上包括兩個方面的內容，一個內容是應用本身的引數配置指令碼，一個是涉及到應用的靜態資料初始化和匯入指令碼。這兩部分指令碼都必須提前準備好，對於前者往往涉及到應用系統本身的元資料管理功能儲存到資料庫，也可能儲存在應用伺服器的作業系統，應用本身的配置檔案中，都必須考慮到。而對於靜態資料初始化指令碼，往往需要提供相應的初始化sql指令碼進行匯入，而不是簡單的提供Excel，這樣才能夠方便甲方的系統管理員進行批次匯入。

對於資料初始化指令碼，應該有完整的資料匯入和校驗邏輯，異常提升邏輯，以方面在資料初始化失敗的時候查詢問題。同時在資料匯入後，最好再提供相應的資料驗證指令碼，對匯入的資料的正確性進行驗證和確認。而不是完全依靠人工的方式去核查和比對。

第三就是應用上線和部署完成後的檢查單CheckList

這個清單相當重要，一定不要相信自己的腦袋能夠記住所有的檢查項而沒有遺漏，一個應用系統的上線涉及到資料庫，中介軟體，應用程式，資料，介面，應用功能多方面的內容，要確保上線功能沒有問題必須每個點都需要檢查到位，因此必須要有詳細的檢查清單，按照清單進行逐一的檢查才可以。

檢查單就是起到這個作用，我們只需要提前想清楚所有的檢查點，並給出具體的檢查方法，然後在系統部署和上線完成後，按檢查單裡面的檢查項進行逐一的檢查就可以了。這樣可以確保沒有任何的遺漏。

最後就是上線完成後的人工驗證

這個步驟也不能少，即我們的應用在上線完成後，往往會在生產環境部署完成的應用上進行一個初步的冒煙測試，確保所有功能都沒有問題。在這個過程中可能會產生垃圾資料，可以在測試完成後進行清除。整個測試過程為了不影響到實際的組織和使用者，我們也可以在系統裡面單獨建立一個臨時組織和使用者，用分配的臨時使用者進行相應的單據建立，流程審批，單據生效，介面和業務聯通流轉等方面的測試，確保整個端到端流程是完整的。

當然還有一種方法就是我們在生產環境正式部署和配置完成後，可以將生產環境的整個內容再完全克隆回UAT環境，在UAT環境進行相應的測試工作，這樣可以確保生產環境不進垃圾資料，同時又確保生產環境的配置沒有任何問題。在從生產環境克隆回來的時候，注意重點是克隆生產環境資料庫和引數配置內容，而對於測試環境的一些引數配置項仍然需要保留測試環境的。

系統割接上線方案模板

在這裡給出一個業務系統割接上線的方案模板，對於系統建設實施過程中，割接上線方案也是整體專案最終交付和驗收的一個重要文件。因此在這裡專門再談下割接上線方案應該包括哪些具體的內容點。

1-系統當前現狀分析

1.1 系統部署架構現狀

1.2 系統當前硬體資源詳細描述

1.3 系統技術架構現狀

1.4 核心資料庫，中介軟體，技術元件說明

第一部分重點說明當前應用部署架構現狀，硬體和儲存等IT硬體設施邏輯架構和詳細資源清單說明。同時說明業務系統的IT技術架構，使用到的核心資料庫，中介軟體，技術元件。

在邏輯架構中，應該能夠體現出具體各個中介軟體，技術元件，應用的邏輯部署關係。

如果是全新的業務系統部署上線，則不存在這部分內容的描述。

2-本期系統目標架構說明

2.1 系統目標部署架構

2.2 系統硬體資源列表

2.3 系統技術架構

2.4 核心資料庫，中介軟體，技術元件說明

2.4 目標架構和當前現狀差異分析

第二部分應該重點描述目標架構，其中目標架構仍然包括了硬體基礎設施架構，也包括了軟體技術架構。同時需要分析目標架構和現狀差異。

3-割接方案說明

3.1 硬體割接方案說明

3.2 軟體割接方案說明

3.3 資料割接方案說明

對於系統的割接可以理解為硬體和兩個不同的層面。

有些割接可能只涉及到硬體的增加，比如資料庫增加一個RAC節點，原來用的HaProxy需要割接到硬體的F5硬體均衡裝置，資料庫儲存容量需要進行擴容等。

還有一些割接只涉及到軟體層面，比如軟體重大版本的部署。

也存在同時涉及到軟體和硬體層面的割接，比如傳統的軟體架構當前升級為微服務架構，你可以看到軟體層面，硬體層面都存在重大變化和修改。

同時在割接方案中也存在僅僅進行資料割接的情況，比如硬體部署環境和軟體當前部署版本均沒有發生變化，但是需要對資料庫中資料進行割接。比如對於資料庫中的物料資訊進行新舊程式碼切換等操作。

割接方案簡單來說就是要說清楚從現狀到目標的具體變化點。因此在進行割接方案闡述的時候也可以進一步的配合系統物理部署架構和邏輯部署架構圖進一步進行對比闡述。以方面閱讀人能夠更加明顯的看到割接前後的差異點和變化點。

4-割接影響分析和割接準備

4.1 割接原則說明

4.2 割接影響分析(硬體，軟體，資料，使用者）

4.3 割接前的準備工作

4.3.1 需要提前準備和安裝的硬體和中介軟體

4.3.2 資料備份工作

割接影響分析是割接方案裡面最重要的一個內容，即需要分析割接對整體業務系統執行的影響情況，在整個影響分析中識別和分析關鍵的風險點。

影響分析包括了硬體，軟體，資料各個層面的分析。同時也包括以使用者視角的影響分析和評估。有些割接屬於底層割接對使用者沒有影響，但是有些應用層面的割接往往割接完成後對使用者訪問方式操作入口，以及具體功能都會有影響，這些也需要進一步分析說明。

割接前的準備工作需要詳細描述的內容包括了：

需要提前準備的硬體和網路環境

需要提前準備和安裝的資料庫和中介軟體，技術元件等

需要進行的環境配置檔案，資料庫備份工作

5-詳細割接計劃

5.1 割接組織和人員

5.2 割接時間

5.3 割接詳細的步驟和參與人員

5.4 割接詳細內容說明

5.4.1 當前環境備份操作

5.4.2 環境準備和中介軟體安裝

5.4.3 應用安裝部署

5.4.4 資料割接和切換

5.4.5 環境配置等

5.5 割接完成後的驗證和確認

在割接計劃部分需要說明割接組織人員，割接的詳細步驟，每個步驟的時間和參與人員，對於每個割接步驟又需要在割接詳細內容部分給出詳細的割接過程說明。

在割接完成後還需要有專門的割接驗證步驟說明，以確保割接成功。

6-割接風險分析和應對

6.1 割接風險分析

6.2 割接回退和恢復方案詳細說明

6.3 割接應急方案說明

對於割接風險實際上包括兩個層面，一個是在割接過程中就發生了問題這個時候直接進行回退操作即可。也可能是割接本身沒有問題，但是系統上線後出現問題，這個時候可能已經產生了新的資料到資料庫，因此不能簡單的採用回退操作，必須有詳細的應急處理方案和回退方案。

如果是簡單的回退那麼就會造成資料丟失，需要業務人員重新進行補錄。因此在這種情況下往往需要考慮的是各種部分回退的策略，或者準備新資料自動簽約回老架構和資料庫的指令碼等。

在當前業務系統間本身存在關聯依賴和整合，因此割接影響分析不僅僅是分析對自己系統的影響，還需要分析割接上線後如此係統出現重大問題，對其它外部依賴系統造成的影響。比如上線後，新的資料已經傳輸給其它業務系統，那麼這個時候回退就還涉及到其它業務系統也存在相應的資料回退操作，其複雜度遠超過對單個系統的回退處理。