【1】需求調研

　　【2】遷移方案詳細設計

　　【3】技術(shù)驗證

　　【4】實(shí)施及切割

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

　　本篇我們將重點(diǎn)分享實(shí)施及切割及上線(xiàn)環(huán)節的注意事項。

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

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

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

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

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

　　

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

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

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

　　

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

　　1） 數據驗證，確認切割時(shí)與切割前數據保持一致。通常客戶(hù)的大部分服務(wù)器鏡像及數據會(huì )在切割前預先在云端復制完成。在切割窗口期開(kāi)啟后需要確保云端復制的數據與客戶(hù)數據中心下線(xiàn)前保持一致。

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

　　3） 遷移時(shí)間拖延問(wèn)題處理。如果切割時(shí)不夠順利，因為種種主客觀(guān)原因導致遷移切割時(shí)間長(cháng)于計劃時(shí)間，可以與客戶(hù)協(xié)調，一起決定是否可以延遲一些時(shí)間上線(xiàn)。基于經(jīng)驗，通常設計切割計劃時(shí)都會(huì )留出一些緩沖時(shí)間，如果需要延遲的時(shí)間過(guò)長(cháng)是客戶(hù)無(wú)法接受的，那就只能失望的遷移過(guò)程回退了。

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

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

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

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

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

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

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

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