【1】需求調(diào)研

　　【2】遷移方案詳細設(shè)計

　　【3】技術(shù)驗證

　　【4】實施及切割

　　【5】遷移結(jié)果驗證及驗收

　　本篇我們將重點分享實施及切割及上線環(huán)節(jié)的注意事項。

　　根據(jù)云遷移項目應(yīng)用復雜程度，上線切割過程通常會有一個或多個短暫的窗口期，如果客戶是擁有眾多核心關(guān)鍵業(yè)務(wù)的中大型企業(yè)，通常應(yīng)用切割上云（業(yè)務(wù)中斷）窗口期會在非業(yè)務(wù)繁忙期的8-24小時（借助工具，線上遷移方式時間會短一些）。一個遷移項目前期的需求調(diào)研、遷移設(shè)計、遷移驗證可能需要花費幾個月的時間，而完成遷移成功的結(jié)果就在這樣的幾個切割窗口期里體現(xiàn)，如果經(jīng)驗不足的遷移團隊在切割的環(huán)節(jié)出現(xiàn)問題，導致切割失敗，參與人（客戶、遷移服務(wù)商等）可能有嚴重的挫敗感。

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

　　在遷移設(shè)計環(huán)節(jié)會設(shè)計一個遷移實施切割計劃，這個計劃的嚴謹程度也許很大程度上決定了遷移成功率。優(yōu)秀的云遷移服務(wù)商會從之前的項目中不斷地總結(jié)成功的經(jīng)驗和失敗的教訓，沉淀出自己的一套體系化的遷移方法。以下給出幾個經(jīng)驗：

　　1） 切割前需要嚴格確認是否所有需要預先準備的工具、遷移環(huán)境（客戶本地數(shù)據(jù)中心端、網(wǎng)絡(luò)、云端）等已經(jīng)就緒。

　　2） 檢查和確認云環(huán)境著陸區(qū)（Landing Zone，云上使用的資源）已經(jīng)就緒，并且確認云環(huán)境中的規(guī)模，安全，控制，網(wǎng)絡(luò)以及身份驗證與設(shè)計保持一致。

　　

　　3） 切割上線時需多方人員參與，軟硬件廠商、集成商、用戶方、云廠商、網(wǎng)絡(luò)運營商等，確認這些相關(guān)人員是否已經(jīng)就緒。支持的方式是現(xiàn)場、遠程還是電話。

　　4） 風險預案是否就緒。切割過程好像在打一場大的戰(zhàn)役，很多的任務(wù)或子任務(wù)會分配半小時內(nèi)計劃執(zhí)行結(jié)束，整個過程可能會緊張到心臟要跳出來了。為降低壓力，退一步海闊天空，即使因為某個主客觀原因?qū)е逻w移無法成功進行，如果有補救措施會讓整個遷移團隊降低很多壓力。這個補救措施之一就是回退預案，也即是失敗后回退到客戶的原數(shù)據(jù)中心恢復業(yè)務(wù)應(yīng)用，需要在切割時預留回退執(zhí)行的時間�；赝藞�(zhí)行后，然后擁有充足的時間排查問題，以備下一個切割窗口期內(nèi)再次切割。

　　5） 向 Azure 遷移的項目，可以參考一些工具來設(shè)計一個檢查列表，比如：遷移評估及準備工具（SMART），Azure 遷移向?qū)В?Azure 實施向?qū)�。這個計劃表里面包含了遷移切割過程的全部任務(wù)、時間段、各方執(zhí)行人員、備崗支持人員等。“認真、謹慎、仔細”的按照這個切割計劃表執(zhí)行就好了。下圖給出一個示例模板，在具體的項目中可以根據(jù)項目需求來設(shè)計定制的遷移切割計劃。

　　

　　如之前提到，遷移項目是復雜的，大部分遷移切割的時候都會或多或少的遇到一些無法預料的問題。如何保證切割成功率，降低失敗的風險？從過去遇到的失敗案例說起，有主觀原因和客觀因素。主觀原因可能因為遷移調(diào)研問題、遷移方案設(shè)計缺陷、遷移驗證過程不夠全面等�？陀^因素通常是客戶 IDC、運營商網(wǎng)絡(luò)、云數(shù)據(jù)中心故障等。無論那種問題導致，都可能會對遷移切割造成失敗。以下分享一些切割經(jīng)驗，

　　1） 數(shù)據(jù)驗證，確認切割時與切割前數(shù)據(jù)保持一致。通�？蛻舻拇蟛糠址�務(wù)器鏡像及數(shù)據(jù)會在切割前預先在云端復制完成。在切割窗口期開啟后需要確保云端復制的數(shù)據(jù)與客戶數(shù)據(jù)中心下線前保持一致。

　　2） 并非所有問題都會導致遷移失敗。遇到問題的時候，先不用荒，首先評估問題的嚴重程度，如果不是關(guān)鍵業(yè)務(wù)應(yīng)用的重要的問題，可以將切割流程繼續(xù)進行，同時該問題繼續(xù)解決。與客戶協(xié)商，該問題是否會會對業(yè)務(wù)有很大影響，如果客戶可以接受的話，可以先上線，然后盡快解決該問題。

　　3） 遷移時間拖延問題處理。如果切割時不夠順利，因為種種主客觀原因?qū)е逻w移切割時間長于計劃時間，可以與客戶協(xié)調(diào)，一起決定是否可以延遲一些時間上線�；�于經(jīng)驗，通常設(shè)計切割計劃時都會留出一些緩沖時間，如果需要延遲的時間過長是客戶無法接受的，那就只能失望的遷移過程回退了。

　　4） 網(wǎng)絡(luò)切換問題處理。比如 IP，端口，網(wǎng)絡(luò)配置，DNS 等問題，在之前的調(diào)研和檢查中出現(xiàn)遺漏（這個信息提供方可能由客戶的 IT 部門，第三方 IT 運維公司，應(yīng)用系統(tǒng)集成商以及自動工具提供）。這種問題在切割時經(jīng)常會遇到，出現(xiàn)這種問題緊急聯(lián)系相關(guān)負責方盡快解決，但并不一定會影響切割整體進行。

　　5） 遷移的不僅是服務(wù)器或數(shù)據(jù)。而是整個企業(yè)的 IT 應(yīng)用及環(huán)境，客戶應(yīng)用需要的身份管理、安全配置、數(shù)據(jù)及系統(tǒng)備份、高可用性架構(gòu)配置，容災(zāi)方案等都需要完成。

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

　　7） 遷移過程確保安全合規(guī)。數(shù)據(jù)遷移嚴格使用加密數(shù)據(jù)傳輸，加密數(shù)據(jù)存儲。證書、密碼、權(quán)限按照合規(guī)的方式申請和使用，杜絕泄露隱患。避免因安全合規(guī)性問題帶給客戶嚴重損失。

　　切割后對遷移的結(jié)果進行驗證，通常有先后兩個部分，即遷移服務(wù)商驗證和客戶驗證。分享以下一些經(jīng)驗：

　　1） 衡量遷移是否成功需要按照遷移之前定義的參考指標進行。通常遷移服務(wù)商會在遷移切割時確定遷移的服務(wù)器、數(shù)據(jù)、網(wǎng)絡(luò)等IT服務(wù)資源是否已經(jīng)能夠在新的云環(huán)境下運行起來。這種技術(shù)驗證只是一個最初級的，在這基礎(chǔ)之上還要驗證數(shù)據(jù)一致性、性能指標、安全標準、成本狀況等，這些驗證信息的定義都會在遷移設(shè)計時定義清楚。當滿足了整個應(yīng)用的全面運維指標時才能算驗證成功。

　　2） 當遷移服務(wù)商驗證遷移結(jié)果后，會由客戶進行驗證，這時客戶會對應(yīng)用 IT 環(huán)境及業(yè)務(wù)功能進行驗證，驗證過程會更加權(quán)威，當遇到一些問題的時候需要運維服務(wù)商和客戶一起討論，此環(huán)節(jié)可能因為客戶期望與遷移結(jié)果的差異對遷移后的環(huán)境做局部的調(diào)整，這時需要評估工作量和實現(xiàn)時間，盡量避免不明確的問題產(chǎn)生，導致驗收結(jié)果拖延。

　　云遷移需要一個體系化的流程來實施上線，它不僅需要依靠工具還需要正確的流程、完備的支持人員以及解決緊急問題經(jīng)驗來支撐，希望以上的經(jīng)驗分享能夠?qū)τ性七w移訴求的技術(shù)人員有所幫助。