云遷移項目實施流程通常為：
- 需求調(diào)研；
- 遷移方案詳細(xì)設(shè)計；
- 技術(shù)驗證；
- 實施及切割；
- 遷移結(jié)果驗證及驗收。
每個公有云廠商會沉淀出自己的遷移方法論，微軟的方法論云采用框架（CAF）看著的是理論聯(lián)系實際，同時結(jié)合優(yōu)化結(jié)構(gòu)框架（WAF），側(cè)重上云細(xì)節(jié)設(shè)計以及實際操作。詳情可以參考參考我們之前發(fā)布的內(nèi)容：云基礎(chǔ)架構(gòu)采用者避坑指南：擁抱“云”，更懂“云”。 本篇我們會重點介紹項目實施過程的前三步。
需求調(diào)研：明確遷移目標(biāo)
遷移項目始于客戶的遷移動機(jī)，根據(jù)客戶的遷移動機(jī)來指定遷移目標(biāo)，這個目標(biāo)是衡量遷移項目是否成功的基準(zhǔn)。所以風(fēng)險分析第一步就是明確客戶遷移目標(biāo)，結(jié)合客戶的現(xiàn)有 IT 環(huán)境來綜合評估客戶的目標(biāo)是否可以完成。
也許在客戶 IT 環(huán)境調(diào)研時發(fā)現(xiàn)各種復(fù)雜的技術(shù)問題，企業(yè)級客戶系統(tǒng)繁多，并且復(fù)雜，來自不同時期上線的，使用了異構(gòu)的技術(shù)架構(gòu)。這些需要進(jìn)行評估能否靠一些技術(shù)方案解決。如果是繞不過去的硬傷，要及時跟客戶提出來與客戶討論解決方法。
客戶調(diào)研階段，我們需要對客戶的IT信息盡量做細(xì)致的了解，以提早發(fā)現(xiàn)可能導(dǎo)致遷移失敗的風(fēng)險點。針對客戶每個系統(tǒng)，提出相關(guān)問題及拓?fù)鋱D邏輯圖信息。
遷移方案設(shè)計：風(fēng)險最小化
了解了客戶 IT 信息后，開始考慮遷移方案。通常遷移方法有很多種，比如下圖中看到的Rehost,Refactor,Rearchitect,Rebuild,Replace（重新托管，重構(gòu)，重新架構(gòu)，重建，替換）等。這些方法從左到右，遷移后對系統(tǒng)的革新程度（現(xiàn)代化或數(shù)字化轉(zhuǎn)型）越來越顯著，也越來越多利用到云的特性，但需要實施周期通常也會更長，且可能帶來更大的實施風(fēng)險。所以對于大型云遷移項目中，考慮最小的風(fēng)險，最適合的方式是 Rehost（即Lift & Shift）：通過鏡像遷移的方式將系統(tǒng)遷移上云，從云上的基礎(chǔ)架構(gòu)上看基本與客戶本地數(shù)據(jù)中心保持一致。這種遷移最簡單，花費的時間通常也是最短。如某些系統(tǒng)無法通過 Rehost 方式遷移的話，可以考慮 Refactor 等方式。
所以，總體來說，建議優(yōu)先考慮 Rehost。遷移實施結(jié)束后，客戶可以基于云的使用階段繼續(xù)按照下圖所示架構(gòu)，在云上進(jìn)行優(yōu)化。
確定了遷移方法，開始考慮使用的遷移工具，從下圖列出了一些相關(guān)工具種類，目前針對不同的遷移方法會有多種遷移工具來選擇，公有云第一方或第三方工具，功能上各有特色。選擇的原則是：使用適合自己的工具，無論第一方或第三方。
技術(shù)驗證：修正遷移方案
確定了遷移方案后，需要對遷移系統(tǒng)做一個遷移的技術(shù)驗證（PoC），建議使用客戶 IDC 的真實環(huán)境（或客戶測試環(huán)境），基于有代表性同時對業(yè)務(wù)影響小的系統(tǒng)環(huán)境做遷移測試，通常 Rehost 方式也可以基于技術(shù)類驗證，并非整個系統(tǒng)。在驗證中可以暴露出方案中沒有考慮到或著隱性的一些坑，通過驗證結(jié)果能及時修改遷移方案。
每一個批次的應(yīng)用切割切割通常需要 8-48 小時完成，關(guān)鍵注意事項可以在文末經(jīng)驗總結(jié)中查看。
云遷移項目經(jīng)驗總結(jié)
針對不同的客戶場景，遇到的技術(shù)問題不盡相同，最后，我們針對 Azure 實際遷移項目過程的實踐經(jīng)驗，總結(jié)云遷移關(guān)鍵點供大家參考：
OS 及遷移工具
- 確認(rèn)客戶使用的 OS 在 Azure 是否支持，精確到小版本，如有不支持的 OS，找到替代方案，升級或更換替代的 OS。
- 確認(rèn) OS 軟件許可授權(quán)，比如 Windows 及有軟件許可費用的 Linux 等，確認(rèn)合規(guī)性。
- 掌握遷移工具的遷移原理及遷移架構(gòu)，在遷移的兩端（客戶 IDC 及 Azure）上所需的資源比如計算資源、網(wǎng)絡(luò)、存儲空間等 。
- 遷移工具的使用限制，沒有萬能的工具。
- 評估哪些應(yīng)用可以鏡像遷移、哪些需要云上重構(gòu)、哪些需要架構(gòu)優(yōu)化。
網(wǎng)絡(luò)
- 確認(rèn)客戶現(xiàn)有的、遷移期間、遷移之后的網(wǎng)絡(luò)環(huán)境及帶寬。
- 計算數(shù)據(jù)傳輸時間和帶寬。
- 網(wǎng)絡(luò)切割方案，深入了解細(xì)節(jié)。
- 準(zhǔn)備客戶網(wǎng)絡(luò)環(huán)境與 Azure 網(wǎng)絡(luò)服務(wù)的差異，找到替代方案。
- 深入了解 Azure 網(wǎng)絡(luò)限制（ER，VPN，VNet，IP,NSG etc.）。
- 確保使用合規(guī)和安全的網(wǎng)絡(luò)協(xié)議，例如：SSH,SFTP,HTTPS 等。
- 不直接使用 internet 傳輸數(shù)據(jù)，數(shù)據(jù)傳輸使用 VPN over internet，或?qū)＞�。
存儲
- 調(diào)研客戶存儲細(xì)節(jié)信息：類型、容量、IOPS、業(yè)務(wù)場景、當(dāng)前問題、未來容量。
- Azure 存儲的 SLA 和限制。
- 存儲類型轉(zhuǎn)變及優(yōu)化（例如：IDC VM 上自建的文件共享服務(wù)器遷移到 Azure 文件存儲）。
- 提醒客戶為遷移實施過程準(zhǔn)備足夠的存儲空間供遷移工具使用。
切割過程
- 永遠(yuǎn)制定備選方案 Plan B。
- 網(wǎng)絡(luò)環(huán)境、Azure 資源狀況再次檢查。
- 提前安排多方相關(guān)的人員在切割窗口時間備崗。
安全及資源申流程
- 遷移過程需要用到多個賬戶及客戶現(xiàn)有系統(tǒng)的口令、密碼、證書等安全信息，以合規(guī)的方式申請、以合規(guī)的方式使用。
- 申請客戶的某些權(quán)限需要客戶內(nèi)部流程審批，為保證項目如期完成，提前了解審批周期，通常需要 2-7 天時間。
以上的一些基于風(fēng)險評估考慮的一些信息希望能夠給實施遷移項目的架構(gòu)師或工程師有所幫助，后續(xù)我會繼續(xù)從不同的一些方面總結(jié)遷移的方案和經(jīng)驗。
