【1】需求調研

【2】遷移方案詳細設計

【3】技術驗證

【4】實施及切割

【5】遷移結果驗證及驗收

本篇我們將重點分享實施及切割及上線環節的注意事項。

根據雲遷移專案應用複雜程度，上線切割過程通常會有一個或多個短暫的視窗期，如果客戶是擁有眾多核心關鍵業務的中大型企業，通常應用切割上雲（業務中斷）視窗期會在非業務繁忙期的8-24小時（藉助工具，線上遷移方式時間會短一些）。一個遷移專案前期的需求調研、遷移設計、遷移驗證可能需要花費幾個月的時間，而完成遷移成功的結果就在這樣的幾個切割視窗期裡體現，如果經驗不足的遷移團隊在切割的環節出現問題，導致切割失敗，參與人（客戶、遷移服務商等）可能有嚴重的挫敗感。

切割上線前的準備

針對切割上線的重要性，也許各方領導都會叮囑：“認真、謹慎、仔細”，具體在實施切割上線的時候如何執行這樣主觀空洞但“正確”的指示呢。

在遷移設計環節會設計一個遷移實施切割計劃，這個計劃的嚴謹程度也許很大程度上決定了遷移成功率。優秀的雲遷移服務商會從之前的專案中不斷地總結成功的經驗和失敗的教訓，沉澱出自己的一套體系化的遷移方法。以下給出幾個經驗：

1) 切割前需要嚴格確認是否所有需要預先準備的工具、遷移環境（客戶本地資料中心端、網路、雲端）等已經就緒。

2) 檢查和確認雲環境著陸區（Landing Zone，雲上使用的資源）已經就緒，並且確認雲環境中的規模，安全，控制，網路以及身份驗證與設計保持一致。

3) 切割上線時需多方人員參與，軟硬體廠商、整合商、使用者方、雲廠商、網路運營商等，確認這些相關人員是否已經就緒。支援的方式是現場、遠端還是電話。

4) 風險預案是否就緒。切割過程好像在打一場大的戰役，很多的任務或子任務會分配半小時內計劃執行結束，整個過程可能會緊張到心臟要跳出來了。為降低壓力，退一步海闊天空，即使因為某個主客觀原因導致遷移無法成功進行，如果有補救措施會讓整個遷移團隊降低很多壓力。這個補救措施之一就是回退預案，也即是失敗後回退到客戶的原資料中心恢復業務應用，需要在切割時預留回退執行的時間。回退執行後，然後擁有充足的時間排查問題，以備下一個切割視窗期內再次切割。

5) 向 Azure 遷移的專案，可以參考一些工具來設計一個檢查列表，比如：遷移評估及準備工具（SMART），Azure 遷移向導, Azure 實施嚮導。這個計劃表裡麵包含了遷移切割過程的全部任務、時間段、各方執行人員、備崗支援人員等。“認真、謹慎、仔細”的按照這個切割計劃表執行就好了。下圖給出一個示例模板，在具體的專案中可以根據專案需求來設計定製的遷移切割計劃。

雲遷移切割計劃

切割上線

如之前提到，遷移專案是複雜的，大部分遷移切割的時候都會或多或少的遇到一些無法預料的問題。如何保證切割成功率，降低失敗的風險？從過去遇到的失敗案例說起，有主觀原因和客觀因素。主觀原因可能因為遷移調研問題、遷移方案設計缺陷、遷移驗證過程不夠全面等。客觀因素通常是客戶 IDC、運營商網路、雲資料中心故障等。無論那種問題導致，都可能會對遷移切割造成失敗。以下分享一些切割經驗，

1) 資料驗證，確認切割時與切割前資料保持一致。通常客戶的大部分伺服器映象及資料會在切割前預先在雲端複製完成。在切割視窗期開啟後需要確保雲端複製的資料與客戶資料中心下線前保持一致。

2) 並非所有問題都會導致遷移失敗。遇到問題的時候，先不用荒，首先評估問題的嚴重程度，如果不是關鍵業務應用的重要的問題，可以將切割流程繼續進行，同時該問題繼續解決。與客戶協商，該問題是否會會對業務有很大影響，如果客戶可以接受的話，可以先上線，然後儘快解決該問題。

3) 遷移時間拖延問題處理。如果切割時不夠順利，因為種種主客觀原因導致遷移切割時間長於計劃時間，可以與客戶協調，一起決定是否可以延遲一些時間上線。基於經驗，通常設計切割計劃時都會留出一些緩衝時間，如果需要延遲的時間過長是客戶無法接受的，那就只能失望的遷移過程回退了。

4) 網路切換問題處理。比如 IP，埠，網路配置，DNS 等問題，在之前的調研和檢查中出現遺漏（這個資訊提供方可能由客戶的 IT 部門，第三方 IT 運維公司，應用系統整合商以及自動工具提供）。這種問題在切割時經常會遇到，出現這種問題緊急聯絡相關負責方儘快解決，但並不一定會影響切割整體進行。

5) 遷移的不僅是伺服器或資料。而是整個企業的 IT 應用及環境，客戶應用需要的身份管理、安全配置、資料及系統備份、高可用性架構配置，容災方案等都需要完成。

6) 嚴格按照遷移設計方案中指定的雲服務型號（SKU）匹配雲上資源。拿 VM 舉例，通常雲上會提供十幾個系列，數百種 VM 型號，使用錯誤的 VM 即使能夠將服務啟動起來，但會帶來效能、功能以及成本的問題。當使用了錯誤的 VM 型號後，可以透過雲上提供的型號切換功能切換到正確的 VM 型號，無需刪除 VM。

7) 遷移過程確保安全合規。資料遷移嚴格使用加密資料傳輸，加密資料儲存。證書、密碼、許可權按照合規的方式申請和使用，杜絕洩露隱患。避免因安全合規性問題帶給客戶嚴重損失。

切割後對遷移的結果進行驗證，通常有先後兩個部分，即遷移服務商驗證和客戶驗證。分享以下一些經驗：

1) 衡量遷移是否成功需要按照遷移之前定義的參考指標進行。通常遷移服務商會在遷移切割時確定遷移的伺服器、資料、網路等IT服務資源是否已經能夠在新的雲環境下執行起來。這種技術驗證只是一個最初級的，在這基礎之上還要驗證資料一致性、效能指標、安全標準、成本狀況等，這些驗證資訊的定義都會在遷移設計時定義清楚。當滿足了整個應用的全面運維指標時才能算驗證成功。

2) 當遷移服務商驗證遷移結果後，會由客戶進行驗證，這時客戶會對應用 IT 環境及業務功能進行驗證，驗證過程會更加權威，當遇到一些問題的時候需要運維服務商和客戶一起討論，此環節可能因為客戶期望與遷移結果的差異對遷移後的環境做區域性的調整，這時需要評估工作量和實現時間，儘量避免不明確的問題產生，導致驗收結果拖延。