容災漸進式雲遷移

2021年8月27日，天津“國資雲"的一紙政令一下子成為整個雲計算市場的熱搜。同時，相同措辭的的政令，在各地國資委都已經出現。

上雲遷移已經成為全社會各行業普遍的共識，“上不上雲”已經無須讨論，“怎麼上雲”成為企業使用者關注的重點。縱觀整個雲遷移市場，”上雲方法論“幾乎無異，但是在雲平台建設初期，往往疏于雲遷移成本的預算，等雲平台建設完成後，才意識到問題的嚴重性。此時，隻能從現有的資金中擠占出非常有限的預算進行雲遷移，卻又面臨着用于上雲資金投入與使用者預期不符的情況。最終導緻的結果就是，雲平台資源的巨大浪費，平台長時間處于閑置狀态。對于雲平台廠商，在初期項目中往往“虧本賺吆喝”，一切指望後期項目中磨刀霍霍，由于始終無法用于生産，雲平台規模也無法擴大，導緻一期的投入血本無歸。

雲遷移是一個複雜的系統工程，并不是一個工具就解決的。要秉承一套科學的方法論，在使用者、雲平台和遷移方的三方協作下，才能順利完成。目前在雲遷移過程中，最大痛點來自于前期調研階段，這是後續過程的基礎，但是在實踐中又面臨諸多阻力，例如：使用者不配合、系統陳舊、業務系統無人運維方等諸多問題，導緻無法開展後續流程。本文主要介紹基于容災演練的理念，利用漸進式雲遷移的思路和方法，将一部分調研工作後置，解決在上雲前調研中的難點，通過建構”仿真“環境，在實踐中完成調研中最困難的部分，加速雲遷移的過程。

雲遷移之調研痛點分析

調研是雲遷移實施前非常重要的一個環節，調研也決定了後續整個項目落地的進度和最終的效果。調研基本分為兩個部分：

技術調研

技術調研核心目的是通過對源端主機和綜合環境資訊進行采集，找出适當的遷移方法，也就是AWS倡導的"6R"遷移政策。技術調研部分最重要的一個環節就是以單台主機為機關，通過收集計算、存儲、網絡等基礎資源，合理對上雲後的架構進行規劃，以便來判斷使用何種工具進行遷移。技術調研非常重要，因為這是決定是否可以遷移以及成本非常重要的一環。

業務調研

業務調研是以使用者為主導，以技術調研的基礎，對業務系統歸屬、關聯性等進行分析，明确業務系統運維負責人和使用方，對于上雲後發生的變更，還要明确變更的内容及執行人等資訊。業務系統調研本身并不涉及過多技術内容，更多的是以現有的業務系統統計資訊為基礎，就可以很快得出結論，但是在實際的項目執行過程中，這部分往往是阻力最大的部分。

痛點分析

首先，責任歸屬問題。負責雲平台建設和遷移的部門往往是底層基礎支撐部門，例如：在傳統的政企中的資訊部、系統部等，而受影響的部門卻是業務部門。而由于遷移過程中觸發的上層業務系統變更，無疑給這些業務部門增加了額外工作。是以在實際走訪調研過程中，不配合基本是常态，問題超過三個，就會出現了不耐煩、推三阻四或顧左右而言他的情況。稍微配合一點的，就是登陸系統後告訴你，雙手一攤，”你自己看吧“。上雲是一個自頂向下的過程，使用者上司層的決心和執行力是項目成敗的關鍵。

第二，資料安全。由于不清楚雲遷移的風險，使用者過分擔心遷移過程後的資料安全性和業務連續性，要求遷移前進行大量前期的方案整理和調研工作。前期”空想“的内容太多，最終導緻項目遲遲無法啟動。

第三，業務無運維。使用者的業務系統并不是一天建成的，這其中的跨度可能曆經數十年的時間。從實際項目情況看，能夠将自己業務系統梳理清晰的客戶并不是很多，更别說是上雲後要變更哪些内容，甚至一些陳舊的業務系統，連原廠商都找不到，而且這樣的情況還不在少數（背後的原因大家可以自行腦補）。這也間接導緻了第一點問題，沒有人敢為此承擔責任。在實際項目中，經常有些業務系統沒有人敢重新開機，因為誰也不知道系統重新開機後業務還能不能用，是以沒人願意承擔由此産生的後果。

第四，調研對人員專業性要求高。通常認為調研的難度往往與咨詢劃等号，天然認為調研人員往往需要具備較高的技術寬度，見多識廣，接觸過不同類型的業務系統架構，這樣的門檻往往讓許多傳統內建商在轉型雲MSP時望而卻步，根本不知道該從哪裡開始。在實際項目中，調研工作往往依靠Excel統計，事實證明，填表人的想象力和創造力超乎你的想象，填回來的資訊五花八門。如果靠人力去完成，使用者的資金投入根本無法覆寫調研過程的成本，而且耗時耗力、周期長，很難避免錯誤的産生。

用容災思路解決上雲遷移痛點

與傳統實體環境下的遷移不同，雲的“軟體定義一切”的特性，決定了雲資源的可編排性和最終一緻性。在之前《雲原生趨勢下的遷移與容災思考》我曾經提到過，雲計算平台解決了雲上資源的可編排性，而雲遷移與雲容災則是将雲的編排性和資料結合在一起，形成了雲上資料的管理平台。正因為如此，雲間資料流轉成為常态化需求，業務系統在不同雲間運作成為可能，同時也進一步模糊了雲上遷移與容災的邊界。

針對上述出現的痛點，我們在項目實踐中通過容災漸進式雲遷移方式建構”仿真“環境，将一部分前期調研工作後置，通過容災演練來解決前期調研中需要業務人員“空想”和“煩躁”的局面。使用技術調研标準化和工具化來保證調研結果的準确性，讓遷移項目能夠快速和順利的推進。

容災漸進式遷移

前面提到，業務調研中最大的阻力其實來自于”人“，技術手段解決不了”人“的問題，但是可以将工作難度降低，間接清除阻力。是以在最佳實踐中，我們決定将部分調研工作後置，具體的做法如下：

業務調研階段，需要明确業務系統組成範圍，即哪些主機構成了一個完整的業務系統，因為這決定了遷移的順序和方案的規劃，這個環節還是必不可少的，而且基本上對于使用者沒有太大的難度。接下來，需要明确業務運維負責人（業務變更）和業務負責人（業務驗證），對于沒有業務運維負責人的老舊系統，可以考慮不遷移或者淘汰，如果使用者執意遷移，則要明确運維邊界（通常涉及商務問題）。而對于業務關聯性、系統變更等複雜的業務問題，則後置在遷移驗證階段完成，在仿真環境完成。

目前，國内大部分政企客戶的遷移中，主機級别遷移占絕大多數，基本上都會采用塊級别整機遷移的方案來保持遷移的一緻性。上面提到，雲的可編排性讓我們可以利用容災演練的方式在雲端重複仿真一個真實的”生産“環境，解決業務調研中，”受制于人“的部分。讓業務運維人員和使用方都有充足的時間對系統的變更及穩定性做出驗證，一方面杜絕了在調研前期的空想，另外一方面也能夠将責任劃厘清晰。要實作這樣的目标，在選擇遷移工具時，要具備以下特征：

首先，遷移工具自身與雲平台要進行過充分的對接，不能隻是簡單的對接一兩個啟動主機的接口，要充分利用雲平台的卷快照、主機啟動時的存儲類型、網絡等接口特性，例如：租戶級别的卷轉移、密碼、密鑰管理、指定IP、卷啟動等特性，即實作利用資料副本還原生産環境的效果。這樣原有增量同步仍然能夠繼續，保證後續割接順利進行。當業務系統達到一定數量時，沒有高度自動化的雲上資料編排能力，是無法完成仿真環境的建立的，手動建立的工作量超出你的想象，而且極其容易造成錯誤，隻有高度自動化的能力才能保證仿真環境建構的準确性和一緻性。

第二，充分利用雲上虛拟網絡隔離的特性，建構近似真實的仿真環境，而不影響正常的業務系統運作。最好的方式，就是通過建構與真實環境相同的網絡位址段（與原有網絡隔離，避免造成資料污染），将業務系統按照原有IP位址恢複至該網段内，這樣仿真環境就真正的建立好了。遷移工具在演練階段要保證每台主機資料的完整性、系統的正常運作，而此後就可以讓業務系統的運維方在仿真環境中進行業務變更驗證，并将步驟記錄，而業務系統負責人在仿真環境從業務次元進一步驗證。解決之前空想狀态下的調研工作，也讓業務方能夠安心進行驗證後遷移。

最後，實作最終的遷移實施報告，在規定的時間視窗内，完成最終的業務割接上雲。

技術調研标準化與工具化

技術調研是調研工作中技術要求最強的部分，也是最重要的部分，這部分并不是依靠經驗，而是通過标準化的技術方案，形成流程的标準化。

在最早從事一家銀行雲遷移項目中，我們主要采用人工統計方式進行調研。使用Excel模闆形式，發送給業務方進行填寫，但是随着調研的推進，無論我們的模闆做了多少種樣例，填寫回來的資料總是千奇百怪，有一半的資料是不可用的。後來我們成立專門的調研專家組，由我方（一人）和使用者業務專家（兩人）共同組建，由我方技術人員負責技術部分調研，由業務專家組負責調研關聯性、停機視窗、遷移後變更資訊等與使用者業務相關的部分。在這種情況下，調研20套業務系統（主機數量在50台以上），大約在三天左右時間。雖然這樣能有效提高調研結果的準确性，但是仍然有技術調研結果不準确，導緻在遷移過程中臨時變更方案的情況出現。

通過項目磨煉，我們經過對調研過程的總結，形成了标準化的技術調研方案，進而将該方案形成研發需求，開發出調研及分析工具。調研工具的原理非常簡單，主要分為三個主要功能：

功能一，通過網絡掃描所有存活的主機，通過對nmap的封裝，能夠對使用者區域網路記憶體活的所有主機進行針對性掃描，同時掃描出開放的端口等資訊。該步驟作為詳細采集前的準備資料。

功能二，基于第一步掃描的結果，由使用者業務方提供主機和密碼等資訊，如果是VMWare，則隻需要提供vCenter或ESXi的使用者名和密碼，程式執行後将自動擷取必要的主機詳細資訊，為進一步分析提供依據。

功能三，基于功能二的詳細輸出，根據遷移工具的特點進行詳細分析，最終得出準确的技術調研報告，其中包含遷移方法及預估的資料同步時間。

通過以上方式，在技術調研部分我們逐漸形成了标準化和工具化，而上述調研工具我們也将逐漸開源(github.com/hostminer)。

總結

相較于傳統環境，雲上環境更能模拟出”仿真“環境，而雲的可編排性又為資料統一的管理提供了保障，充分利用雲原生接口及資源的特性，能夠讓我們通過技術手段間接的解決業務上的問題，進而加速項目的推進和實施工作。以上就是我們在實踐中總結出對遷移中業務調研難點的解決方案，這種方式特别适合于加速傳統的政企客戶上雲，解決使用者的後顧之憂。