【1】需求調(diào)研
【2】遷移方案詳細設計
【3】技術驗證
【4】實施及切割
【5】遷移結果驗證及驗收
本篇我們將重點分享實施及切割及上線環(huán)節(jié)的注意事項。
根據(jù)云遷移項目應用復雜程度，上線切割過程通常會有一個或多個短暫的窗口期，如果客戶是擁有眾多核心關鍵業(yè)務的中大型企業(yè)，通常應用切割上云（業(yè)務中斷）窗口期會在非業(yè)務繁忙期的8-24小時（借助工具，線上遷移方式時間會短一些）。一個遷移項目前期的需求調(diào)研、遷移設計、遷移驗證可能需要花費幾個月的時間，而完成遷移成功的結果就在這樣的幾個切割窗口期里體現(xiàn)，如果經(jīng)驗不足的遷移團隊在切割的環(huán)節(jié)出現(xiàn)問題，導致切割失敗，參與人（客戶、遷移服務商等）可能有嚴重的挫敗感。
切割上線前的準備
針對切割上線的重要性，也許各方領導都會叮囑：“認真、謹慎、仔細”，具體在實施切割上線的時候如何執(zhí)行這樣主觀空洞但“正確”的指示呢。
在遷移設計環(huán)節(jié)會設計一個遷移實施切割計劃，這個計劃的嚴謹程度也許很大程度上決定了遷移成功率。優(yōu)秀的云遷移服務商會從之前的項目中不斷地總結成功的經(jīng)驗和失敗的教訓，沉淀出自己的一套體系化的遷移方法。以下給出幾個經(jīng)驗：
1） 切割前需要嚴格確認是否所有需要預先準備的工具、遷移環(huán)境（客戶本地數(shù)據(jù)中心端、網(wǎng)絡、云端）等已經(jīng)就緒。
2） 檢查和確認云環(huán)境著陸區(qū)（Landing Zone，云上使用的資源）已經(jīng)就緒，并且確認云環(huán)境中的規(guī)模，安全，控制，網(wǎng)絡以及身份驗證與設計保持一致。
3） 切割上線時需多方人員參與，軟硬件廠商、集成商、用戶方、云廠商、網(wǎng)絡運營商等，確認這些相關人員是否已經(jīng)就緒。支持的方式是現(xiàn)場、遠程還是電話。
4） 風險預案是否就緒。切割過程好像在打一場大的戰(zhàn)役，很多的任務或子任務會分配半小時內(nèi)計劃執(zhí)行結束，整個過程可能會緊張到心臟要跳出來了。為降低壓力，退一步海闊天空，即使因為某個主客觀原因?qū)е逻w移無法成功進行，如果有補救措施會讓整個遷移團隊降低很多壓力。這個補救措施之一就是回退預案，也即是失敗后回退到客戶的原數(shù)據(jù)中心恢復業(yè)務應用，需要在切割時預留回退執(zhí)行的時間�；赝藞�(zhí)行后，然后擁有充足的時間排查問題，以備下一個切割窗口期內(nèi)再次切割。
5） 向 Azure 遷移的項目，可以參考一些工具來設計一個檢查列表，比如：遷移評估及準備工具（SMART），Azure 遷移向?qū)В?Azure 實施向?qū)�。這個計劃表里面包含了遷移切割過程的全部任務、時間段、各方執(zhí)行人員、備崗支持人員等。“認真、謹慎、仔細”的按照這個切割計劃表執(zhí)行就好了。下圖給出一個示例模板，在具體的項目中可以根據(jù)項目需求來設計定制的遷移切割計劃。
云遷移切割計劃
如之前提到，遷移項目是復雜的，大部分遷移切割的時候都會或多或少的遇到一些無法預料的問題。如何保證切割成功率，降低失敗的風險？從過去遇到的失敗案例說起，有主觀原因和客觀因素。主觀原因可能因為遷移調(diào)研問題、遷移方案設計缺陷、遷移驗證過程不夠全面等�？陀^因素通常是客戶 IDC、運營商網(wǎng)絡、云數(shù)據(jù)中心故障等。無論那種問題導致，都可能會對遷移切割造成失敗。以下分享一些切割經(jīng)驗，
1） 數(shù)據(jù)驗證，確認切割時與切割前數(shù)據(jù)保持一致。通�？蛻舻拇蟛糠址⻊掌麋R像及數(shù)據(jù)會在切割前預先在云端復制完成。在切割窗口期開啟后需要確保云端復制的數(shù)據(jù)與客戶數(shù)據(jù)中心下線前保持一致。
2） 并非所有問題都會導致遷移失敗。遇到問題的時候，先不用荒，首先評估問題的嚴重程度，如果不是關鍵業(yè)務應用的重要的問題，可以將切割流程繼續(xù)進行，同時該問題繼續(xù)解決。與客戶協(xié)商，該問題是否會會對業(yè)務有很大影響，如果客戶可以接受的話，可以先上線，然后盡快解決該問題。
3） 遷移時間拖延問題處理。如果切割時不夠順利，因為種種主客觀原因?qū)е逻w移切割時間長于計劃時間，可以與客戶協(xié)調(diào)，一起決定是否可以延遲一些時間上線�；诮�(jīng)驗，通常設計切割計劃時都會留出一些緩沖時間，如果需要延遲的時間過長是客戶無法接受的，那就只能失望的遷移過程回退了。
4） 網(wǎng)絡切換問題處理。比如 IP，端口，網(wǎng)絡配置，DNS 等問題，在之前的調(diào)研和檢查中出現(xiàn)遺漏（這個信息提供方可能由客戶的 IT 部門，第三方 IT 運維公司，應用系統(tǒng)集成商以及自動工具提供）。這種問題在切割時經(jīng)常會遇到，出現(xiàn)這種問題緊急聯(lián)系相關負責方盡快解決，但并不一定會影響切割整體進行。
5） 遷移的不僅是服務器或數(shù)據(jù)。而是整個企業(yè)的 IT 應用及環(huán)境，客戶應用需要的身份管理、安全配置、數(shù)據(jù)及系統(tǒng)備份、高可用性架構配置，容災方案等都需要完成。
6） 嚴格按照遷移設計方案中指定的云服務型號（SKU）匹配云上資源。拿 VM 舉例，通常云上會提供十幾個系列，數(shù)百種 VM 型號，使用錯誤的 VM 即使能夠?qū)⒎⻊諉悠饋恚珪䦷硇阅�、功能以及成本的問題。當使用了錯誤的 VM 型號后，可以通過云上提供的型號切換功能切換到正確的 VM 型號，無需刪除 VM。
7） 遷移過程確保安全合規(guī)。數(shù)據(jù)遷移嚴格使用加密數(shù)據(jù)傳輸，加密數(shù)據(jù)存儲。證書、密碼、權限按照合規(guī)的方式申請和使用，杜絕泄露隱患。避免因安全合規(guī)性問題帶給客戶嚴重損失。
切割上線后驗證和結果討論
切割后對遷移的結果進行驗證，通常有先后兩個部分，即遷移服務商驗證和客戶驗證。分享以下一些經(jīng)驗：
1） 衡量遷移是否成功需要按照遷移之前定義的參考指標進行。通常遷移服務商會在遷移切割時確定遷移的服務器、數(shù)據(jù)、網(wǎng)絡等IT服務資源是否已經(jīng)能夠在新的云環(huán)境下運行起來。這種技術驗證只是一個最初級的，在這基礎之上還要驗證數(shù)據(jù)一致性、性能指標、安全標準、成本狀況等，這些驗證信息的定義都會在遷移設計時定義清楚。當滿足了整個應用的全面運維指標時才能算驗證成功。
2） 當遷移服務商驗證遷移結果后，會由客戶進行驗證，這時客戶會對應用 IT 環(huán)境及業(yè)務功能進行驗證，驗證過程會更加權威，當遇到一些問題的時候需要運維服務商和客戶一起討論，此環(huán)節(jié)可能因為客戶期望與遷移結果的差異對遷移后的環(huán)境做局部的調(diào)整，這時需要評估工作量和實現(xiàn)時間，盡量避免不明確的問題產(chǎn)生，導致驗收結果拖延。
總結
云遷移需要一個體系化的流程來實施上線，它不僅需要依靠工具還需要正確的流程、完備的支持人員以及解決緊急問題經(jīng)驗來支撐，希望以上的經(jīng)驗分享能夠?qū)τ性七w移訴求的技術人員有所幫助。
