簡介一份覆蓋信息系統(tǒng)云華遷移全流程的設(shè)計方案面向企業(yè)IT規(guī)劃人員、遷移實施團隊及解決方案顧問幫助建立從現(xiàn)狀調(diào)研到遷移上云再到確認交割的規(guī)范化路徑。內(nèi)容以服務(wù)流程圖統(tǒng)領(lǐng)全局詳細拆解四個關(guān)鍵階段系統(tǒng)調(diào)研與評估含物理基礎(chǔ)架構(gòu)、應(yīng)用系統(tǒng)、業(yè)務(wù)重要性及生命周期評估、需求分析及匯總區(qū)分基礎(chǔ)架構(gòu)與應(yīng)用系統(tǒng)兩條脈絡(luò)、遷移實施涉及遷移范圍確定、環(huán)境準(zhǔn)備、人員準(zhǔn)備、網(wǎng)絡(luò)環(huán)境準(zhǔn)備、計算資源準(zhǔn)備與遷移執(zhí)行、測試驗證與確認交割。文檔還針對遷移失敗分析、云主機優(yōu)化等實操細節(jié)給出方法框架目錄結(jié)構(gòu)完整可直接作為云遷移項目方案模板或投標(biāo)支撐材料使用。資源包為1個PDF文件大小333KB已有76人學(xué)習(xí)/下載適合需要快速掌握遷移服務(wù)流程設(shè)計與交付要點的中高級實施和管理人員。1. 信息系統(tǒng)云化遷移先設(shè)計服務(wù)流程再談遷移工具信息化團隊接到云化遷移任務(wù)的第一反應(yīng)通常是找遷移工具鏡像導(dǎo)出、數(shù)據(jù)同步、批量導(dǎo)入。工具鏈越拉越長真到切換那天業(yè)務(wù)方一句“系統(tǒng)連不上”現(xiàn)場就亂了。問題不在工具而在流程?！缎畔⑾到y(tǒng)云華遷移服務(wù)流程設(shè)計方案》這個標(biāo)題點破的關(guān)鍵是把云化遷移當(dāng)成一條有入口、有出口、有質(zhì)量門禁的服務(wù)流水線來設(shè)計而不是一堆服務(wù)器的搬運。這套流程拆開看是四段現(xiàn)狀評估、方案設(shè)計、遷移實施、切換驗證。前兩段做不扎實后兩段必然還債。這篇文章就把每段的交付物、檢查項和常見坑攤開講適合正要帶隊做遷移的架構(gòu)師、項目經(jīng)理和運維負責(zé)人也適合備考信息系統(tǒng)項目管理師的從業(yè)者拿來做案例拆解。2. 遷移前的現(xiàn)狀盤點把應(yīng)用依賴和資源賬單攤開再動手任何遷移方案的第一步都不是畫目標(biāo)架構(gòu)圖而是盤點。盤點不徹底后面所有環(huán)節(jié)都要還債。這一章聚焦三件事資產(chǎn)清單怎么建、哪些系統(tǒng)能搬哪些不能搬、第一批先搬什么。2.1 應(yīng)用資產(chǎn)清單別只數(shù)服務(wù)器要把依賴關(guān)系畫出來大多數(shù)團隊做資產(chǎn)盤點最后交付的是一張 Excel列了主機名、IP、操作系統(tǒng)、CPU 內(nèi)存。這張表對云化遷移來說遠遠不夠。云化遷移要回答的是“這個系統(tǒng)由哪些部分組成、彼此怎么連接”所以清單至少要覆蓋五類對象。對象類型必填字段常見遺漏服務(wù)器主機名、IP、操作系統(tǒng)版本、CPU/內(nèi)存/磁盤數(shù)據(jù)盤掛載點、系統(tǒng)盤數(shù)據(jù)盤劃分數(shù)據(jù)庫引擎、版本、端口、實例數(shù)、庫表規(guī)模、字符集只讀實例、定時任務(wù)依賴、慢日志保留策略中間件類型、版本、部署模式單機/集群配置文件里的絕對路徑、環(huán)境變量網(wǎng)絡(luò)依賴源 IP、目標(biāo) IP、端口、協(xié)議防火墻對端、負載均衡后端 RS 列表任務(wù)與備份定時任務(wù)、備份策略、保留周期依賴外部調(diào)度的系統(tǒng)如代扣、對賬清單建完后還要畫一張依賴圖。做法很樸素從入口域名或 Nginx 開始追蹤到應(yīng)用、中間件再到數(shù)據(jù)庫把每一條鏈路標(biāo)出來。不用一次畫全先挑核心鏈路畫再逐步補外圍。很多人在這一步偷懶結(jié)果遷移到第三批時發(fā)現(xiàn)一個邊緣系統(tǒng)連著生產(chǎn)庫安全組沒放行切換不了。2.2 遷移可行性評估三類系統(tǒng)直接決定你的方案走向盤點完以后要對每個系統(tǒng)做可行性評估判斷能不能遷、怎么遷。常見做法是分三類可直接遷移、需改造后遷移、不建議遷移。類別判斷標(biāo)準(zhǔn)處理方式可直接遷移操作系統(tǒng)可通過鏡像或?qū)С鰧?dǎo)入到云主機未深度綁定物理機特性保留原 OS 做“搬家”式遷移需改造后遷移數(shù)據(jù)庫版本過老、有集群依賴、綁定服務(wù)器序列號、中間件版本停止維護先做兼容性測試必要時升級組件再遷不建議遷移強綁定特定硬件加密機、老式 PCIE 板卡、有嚴格屬地要求留在本地走專線打通云上只放延伸應(yīng)用版本問題是評估時最易翻車的點。比如存量 CentOS 6 系統(tǒng)云上新公共鏡像基本不再提供配套必須先確認源規(guī)格和內(nèi)核版本。數(shù)據(jù)庫也是重災(zāi)區(qū)MySQL 5.5 的庫遷到云上 MySQL 8.0語法兼容性問題會在切換后集中爆發(fā)。評估階段必須把這些版本差異寫成一張風(fēng)險清單而不是等到實施時再發(fā)現(xiàn)。2.3 遷移優(yōu)先級矩陣先搬什么、后搬什么按這個規(guī)則排遷移順序不能靠領(lǐng)導(dǎo)拍板建議按兩個維度打分業(yè)務(wù)影響度停了損失多大和遷移難度技術(shù)復(fù)雜度、依賴數(shù)量。兩個維度交叉成四象限排序規(guī)則是固定的。業(yè)務(wù)影響遷移難度批次建議高低第一批快速見效建立信心高高第二批給足時間單獨排窗口低低第三批批量并行作業(yè)低高最后評估能拖就拖或并入改造計劃這里有一個經(jīng)驗先搬外圍系統(tǒng)驗證一遍流程再碰核心系統(tǒng)。外圍系統(tǒng)體量小、影響面窄哪怕退火也能兜住。核心系統(tǒng)的切換窗口必須與業(yè)務(wù)方書面確認不能只口頭打個招呼。備考信息系統(tǒng)項目管理師的讀者應(yīng)該能看出來這個四象限就是范圍管理和進度管理在實操里的變體案例題?？?。3. 上云方案設(shè)計架構(gòu)選型、網(wǎng)絡(luò)規(guī)劃與批次劃分盤點結(jié)束進入設(shè)計階段。這一階段的核心交付物有四樣目標(biāo)架構(gòu)圖、網(wǎng)絡(luò)規(guī)劃表、批次計劃表、回退預(yù)案。前三樣直接決定實施階段的順暢程度。3.1 同構(gòu)遷移還是異構(gòu)改造先回答這四個問題很多項目在架構(gòu)選型上翻車是因為默認“原樣搬”。實際上遷移分兩種路線同構(gòu)遷移保持原有操作系統(tǒng)、中間件和數(shù)據(jù)庫引擎版本整體搬到云上異構(gòu)改造利用云的能力做升級比如物理機換容器、自建數(shù)據(jù)庫換云數(shù)據(jù)庫。選哪條路回答四個問題就夠。問題同構(gòu)遷移異構(gòu)改造業(yè)務(wù)能接受的最長停機時間分鐘級即可接受需要接近零停機才會考慮團隊有沒有能力維護中間件和數(shù)據(jù)庫有繼續(xù)自建沒有上托管服務(wù)是否存在必須靠改造解決的性能瓶頸無有比如數(shù)據(jù)庫 IO 吞吐長期打滿成本預(yù)算是單次還是持續(xù)單次遷移預(yù)算允許持續(xù)投入改造優(yōu)化我一般會建議“外圍同構(gòu)、核心改造”的混合路線。外圍系統(tǒng)量大、邏輯簡單同構(gòu)遷移最快一個月能推三批核心系統(tǒng)數(shù)據(jù)量大、停機窗口短值得做異構(gòu)改造收益體現(xiàn)在后續(xù)運維成本上。如果四個問題里有兩個以上偏向異構(gòu)就不要為了省事強行同構(gòu)后續(xù)性能問題會讓你花更多時間還債。3.2 網(wǎng)絡(luò)與安全設(shè)計VPC 規(guī)劃、安全組與遷移期雙通道網(wǎng)絡(luò)規(guī)劃是遷移方案里出問題最多的地方。很多人只畫了目標(biāo)環(huán)境的結(jié)構(gòu)漏掉了遷移期間兩邊要互通這個臨時需求。我一般會至少做一張網(wǎng)絡(luò)規(guī)劃表把四件事定下來。規(guī)劃項原則VPC 與子網(wǎng)按業(yè)務(wù)板塊劃分生產(chǎn)和開發(fā)強制隔離網(wǎng)段安全組按業(yè)務(wù)鏈路維度放行規(guī)則備注來源、用途、創(chuàng)建人長距離數(shù)據(jù)通道數(shù)據(jù)量大走專線數(shù)據(jù)量小走公網(wǎng)加密通道不推薦用共享文件直接拉數(shù)據(jù)域名與證書提前規(guī)劃域名解析切到新環(huán)境的時點證書按新環(huán)境重新簽發(fā)遷移期間有個必踩點兩邊業(yè)務(wù)并發(fā)存在安全組至少要放行兩個方向的規(guī)則——新環(huán)境到舊庫、舊環(huán)境到新庫。只開單向通道數(shù)據(jù)同步腳本跑著跑著就斷了而且報錯信息不直觀。另外等保合規(guī)方面記得保留遷移期間的訪問日志和操作審計安全組規(guī)則變更要有記錄這些在項目驗收時會用到。3.3 批次劃分的粒度L1/L2/L3 三層批次與時間窗口批次劃分不能拍腦袋給個“先小后大”要落到具體的批次粒度。常見的做法是分成 L1、L2、L3 三層。L1 批外圍應(yīng)用5 到 8 個系統(tǒng)一批集中在一個周末窗口凌晨啟動天亮前清場。L2 批核心業(yè)務(wù)前后端單個系統(tǒng)一個窗口寧可一天只切一個也不要湊批。L3 批數(shù)據(jù)庫與消息集群放最后單獨給 4 小時以上窗口包含完整的數(shù)據(jù)校驗動作。窗口時長要按數(shù)據(jù)量給參考值而不是統(tǒng)一拍一個數(shù)字。數(shù)據(jù)量建議窗口說明小于 100G2 小時全量遷移加簡單校驗100G 到 1T6 到 8 小時全量加增量加校驗必須完整跑完超過 1T單獨評估與業(yè)務(wù)確認停機底線必要時分庫分片遷移提示窗口時長里必須預(yù)留 30% 緩沖排程不要排滿。另外每次切換的動作不只“切一遍”還包含預(yù)演、正式切換、回退演練三個動作這三者要寫進同一個批次計劃不能只排正式切換。4. 遷移實施流程數(shù)據(jù)同步、應(yīng)用搬遷與切換驗證方案定下來后進入實施。實施階段是所有環(huán)節(jié)里最容易變形的地方因為在窗口內(nèi)做任何決策都帶著時間壓力。按流程走但每一類對象分別對待。4.1 數(shù)據(jù)層遷移全量加增量加校驗三步走數(shù)據(jù)層遷移是流程里最嚴肅的環(huán)節(jié)標(biāo)準(zhǔn)做法是“全量備份恢復(fù)、增量追平、一致性校驗”。以 MySQL 為例常見執(zhí)行順序是先在備份前把源庫設(shè)為只讀或停寫用 mysqldump 導(dǎo)出再把備份恢復(fù)到目標(biāo)庫隨后開啟增量同步追平時段的數(shù)據(jù)最后校驗一致。# 在源庫執(zhí)行全量導(dǎo)出壓縮后傳輸?shù)皆贫?mysqldump -h 源庫IP -u遷移賬號 -p \ --single-transaction --master-data2 \ --routines --triggers \ --default-character-setutf8mb4 \ 業(yè)務(wù)庫名 | gzip /data/migration/db_full.sql.gz # 導(dǎo)入目標(biāo)庫后立刻核對轉(zhuǎn)儲文件頭部的 binlog 位點 # 增量同步就從這個位點開始追參數(shù)說明--single-transaction 保證 InnoDB 導(dǎo)出時數(shù)據(jù)一致且不鎖業(yè)務(wù)表但前提是表引擎是 InnoDBMyISAM 不受保護--master-data2 會在導(dǎo)出文件頭寫入 binlog 位點這是后續(xù)增量同步的起點漏了它就只能重新導(dǎo)出--routines 和 --triggers 把存儲過程、觸發(fā)器一并導(dǎo)出這兩個參數(shù)經(jīng)常被漏掉導(dǎo)致切換后應(yīng)用報“找不到存儲過程”。文件型數(shù)據(jù)的同步用 rsync 更實用。比如靜態(tài)資源、上傳目錄的搬遷# 用 rsync 做數(shù)據(jù)目錄同步限速避免擠占業(yè)務(wù)帶寬 rsync -av --delete --bwlimit50000 \ -e ssh -i /path/遷移密鑰 \ /data/app_resources/ root目標(biāo)IP:/data/app_resources/參數(shù)說明--delete 表示以源端為準(zhǔn)把目標(biāo)端多余文件清掉第一次同步時建議不加這個參數(shù)先跑一遍對比差異--bwlimit 單位是 KB/s50000 即 50MB/s具體數(shù)值要先打一次壓測否則可能把業(yè)務(wù)帶寬占滿。同步完成后不要急著做下一步先跑一遍文件數(shù)和總大小的對比確認沒有偏差。4.2 應(yīng)用層搬遷從冷遷移到熱遷移的選型應(yīng)用層搬遷的核心不是“怎么搬”而是“能不能快速回滾”。常見做法有三種適用場景完全不同。第一冷遷移停機搬遷。適用于外圍系統(tǒng)把服務(wù)器做成鏡像導(dǎo)入云主機或者在新環(huán)境重新部署一遍再同步配置。停機時間長但流程簡單可靠適合 L1 批。第二熱遷移在線遷移。對網(wǎng)絡(luò)條件苛刻需要持續(xù)的大帶寬遷移期間對業(yè)務(wù)性能有擠壓排障難度高。整機熱遷遇到驅(qū)動不兼容或磁盤 UUID 沖突時恢復(fù)時間不可控。第三容器化改造。應(yīng)用做了解耦和配置外置的話直接打成鏡像用編排拉起這是最干凈的方案但要求前期改造足夠充分。我一般不會推薦沒有做過容器化的系統(tǒng)臨時趕容器化那會把一次遷移變成一次重構(gòu)。沒有容器化基礎(chǔ)的系統(tǒng)寧可選擇重新部署加配置同步也不要整機熱遷。整機熱遷出問題時排障窗口不可控最容易造成切換超時。4.3 切換前驗證五類檢查項不能省切換前要按清單驗收不能只看“能打開首頁”就算完。五類檢查項缺一不可。檢查類具體動作失敗標(biāo)準(zhǔn)連通性新環(huán)境到數(shù)據(jù)庫、到對象存儲、到舊環(huán)境白名單任一不通即失敗配置核對配置文件的 IP、端口、路徑、密鑰有殘留舊 IP 即失敗數(shù)據(jù)對比源與目標(biāo)的行數(shù)、最大 ID抽樣核驗記錄不一致即失敗任務(wù)檢查定時任務(wù)是否拉起、消息隊列是否有堆積有堆積即失敗業(yè)務(wù)用測試賬號走一遍核心交易鏈路任一環(huán)節(jié)報錯即失敗提示驗證清單要在切換前打印成紙質(zhì)或在線表格逐項勾選不要靠現(xiàn)場記憶。切換當(dāng)天的操作人是頂不住壓力的清單是唯一的保險。5. 云遷移排障避坑多次實操里最痛的四個翻車現(xiàn)場這一章是血淚經(jīng)驗總結(jié)。云遷移的坑大多相似而且重復(fù)出現(xiàn)在不同的項目里。下面四條都有典型的“現(xiàn)象、原因、解決”三步結(jié)構(gòu)。5.1 現(xiàn)象數(shù)據(jù)遷移完成后業(yè)務(wù)連不上數(shù)據(jù)庫現(xiàn)象數(shù)據(jù)導(dǎo)入完成新環(huán)境應(yīng)用部署好一啟動就報數(shù)據(jù)庫連接超時。排查半天發(fā)現(xiàn)是新環(huán)境的應(yīng)用服務(wù)器 IP 段沒加進數(shù)據(jù)庫的白名單。原因設(shè)計網(wǎng)絡(luò)時只規(guī)劃了“遷移工具到數(shù)據(jù)庫”的通道漏掉了“新應(yīng)用服務(wù)器到數(shù)據(jù)庫”的連接。本質(zhì)上是資產(chǎn)清單里的連接關(guān)系沒有畫全。解決在第一步資產(chǎn)盤點時增加一張“連接關(guān)系表”列出所有源環(huán)境應(yīng)用到數(shù)據(jù)庫、應(yīng)用到中間件、應(yīng)用到外部系統(tǒng)的連接關(guān)系。網(wǎng)絡(luò)規(guī)劃階段按連接關(guān)系表逐條配置安全組和白名單而不是按服務(wù)器列表批量放行。5.2 現(xiàn)象切換窗口一拖再拖業(yè)務(wù)方失去耐心現(xiàn)象計劃 4 小時完成切換到第 6 小時增量數(shù)據(jù)還在漲業(yè)務(wù)方已經(jīng)在旁邊催運維頂不住壓力開始改參數(shù)風(fēng)險失控。原因切換前沒有做“寫停止”演練。存量數(shù)據(jù)同步完成后業(yè)務(wù)持續(xù)寫入增量一直追不平。追不平的原因是增量同步的速度跟不上業(yè)務(wù)寫入高峰。解決切換窗口務(wù)必選業(yè)務(wù)低峰期并提前與業(yè)務(wù)約定一個具體的“停止寫操作”時間點哪怕只停 30 分鐘。對于無法停寫的核心系統(tǒng)在流程設(shè)計階段就要規(guī)劃雙寫或消息隊列緩沖不能到切換現(xiàn)場再想辦法。另外增量追平階段要監(jiān)控延遲曲線如果延遲持續(xù)擴大而不是收斂直接進回退評估不要硬等。5.3 現(xiàn)象遷移后性能不升反降現(xiàn)象遷到云上之后CPU 使用率比原來還高數(shù)據(jù)庫慢查詢變多業(yè)務(wù)方質(zhì)疑“云上比物理機還差”。原因遷移時直接用了云平臺的默認實例規(guī)格內(nèi)存比源機小磁盤類型是普通云硬盤而不是高性能型。數(shù)據(jù)庫參數(shù)也是默認值buffer pool、連接數(shù)等關(guān)鍵參數(shù)沒按源配置對照調(diào)整。解決遷移前把源環(huán)境的關(guān)鍵配置參數(shù)采集下來包括內(nèi)存、CPU、磁盤 IOPS、數(shù)據(jù)庫 buffer pool、最大連接數(shù)。新環(huán)境按源配置對照調(diào)整。遷移后第一周做性能基線對比不要等業(yè)務(wù)方投訴了再調(diào)。5.4 現(xiàn)象回退操作把兩邊的數(shù)據(jù)搞亂了現(xiàn)象切換后發(fā)現(xiàn)問題需要回退運維直接恢復(fù)舊庫第二天業(yè)務(wù)反饋切換期間的新訂單全部丟失。原因回退流程只寫了“恢復(fù)舊庫”沒處理切換期間新庫產(chǎn)生的增量數(shù)據(jù)?；謴?fù)舊庫的動作把新數(shù)據(jù)全部覆蓋掉了而且無法找回。解決回退方案必須包含“增量反寫”動作——先導(dǎo)出新庫在切換期間產(chǎn)生的增量數(shù)據(jù)導(dǎo)入舊庫再恢復(fù)應(yīng)用指向舊庫。每次回退前先凍結(jié)新庫寫入再執(zhí)行反寫避免新一輪不一致。這套動作要在預(yù)演時跑通不能只停留在文檔里。6. 遷移后的基線驗證與成本止損讓云賬單和業(yè)務(wù)指標(biāo)對得上遷移還沒有完切換只是開始?？傆腥藛枴斑w上去到底快沒快、省沒省”這兩件事都必須用數(shù)據(jù)回答。6.1 性能基線遷移后 48 小時的對比方法我現(xiàn)在的做法是遷移前就把源環(huán)境的監(jiān)控數(shù)據(jù)存好至少保留一周。遷移后 48 小時做對比維度固定為接口響應(yīng)時間 P99、TPS/QPS、CPU 峰值、慢查詢數(shù)、磁盤 IO 等待。把這些維度做成一張對比表貼在項目的復(fù)盤文檔里。對比結(jié)果只有兩類一類是性能達標(biāo)另一類是差異項逐條列出原因——是參數(shù)沒調(diào)到位還是規(guī)格選小了。比如數(shù)據(jù)庫慢查詢變多大概率是 buffer pool 太小調(diào)整后復(fù)測48 小時內(nèi)給出結(jié)論。6.2 成本可視把賬單拆到部門和系統(tǒng)維度成本方面遷移后第一件要做的事是給所有云資源打標(biāo)簽標(biāo)簽落到系統(tǒng)名和成本中心兩個維度。一個月后拉取賬單按標(biāo)簽維度看費用分布找出兩類問題閑置資源和過度配置。閑置資源最常見的是源環(huán)境遷完后沒釋放的存量服務(wù)器那是最大的成本漏洞。過度配置則是遷移時按峰值申請了高規(guī)格遷完后實際用量只有 20%。我現(xiàn)在的習(xí)慣是每次遷移完必須開一次復(fù)盤會把計劃時長與實際時長、每項檢查清單的勾選情況、所有參數(shù)變更記錄逐項過一遍。沒有這次復(fù)盤下一輪遷移大概率會在同一個坑里再摔一次。這套流程未必能保證一次成功但能保證每次失敗都有記錄每次記錄都能指導(dǎo)下一次。希望幫到你。本文還有配套的精品資源點擊獲取