簡(jiǎn)介這是北京市政務(wù)云平臺(tái)互聯(lián)網(wǎng)云項(xiàng)目的完整方案文檔面向電子政務(wù)規(guī)劃者、云架構(gòu)師及數(shù)據(jù)中心運(yùn)維人員重點(diǎn)闡述如何通過(guò)IaaS平臺(tái)整合分散政務(wù)系統(tǒng)、提升資源利用率并保障安全。文檔包含1個(gè)PDF文件大小約117KB已有189人學(xué)習(xí)。內(nèi)容完整呈現(xiàn)華為IaaS平臺(tái)總體架構(gòu)與硬件組成涵蓋P2V、V2V、數(shù)據(jù)庫(kù)遷移等業(yè)務(wù)平滑遷移工具以及近三十個(gè)小數(shù)據(jù)中心資源整合、統(tǒng)一互聯(lián)網(wǎng)出口的安全設(shè)計(jì)。方案同時(shí)提供了運(yùn)維管理優(yōu)化路徑與國(guó)產(chǎn)化自主知識(shí)產(chǎn)權(quán)說(shuō)明并附有真實(shí)客戶價(jià)值數(shù)據(jù)三個(gè)月內(nèi)完成計(jì)生、社保、醫(yī)保等民生業(yè)務(wù)遷移上線資源利用率由不足16%提升至55%安全威脅降至原來(lái)的5%運(yùn)維人力由70人減至5人。這些量化指標(biāo)與實(shí)踐過(guò)程能為政務(wù)云規(guī)劃、遷移實(shí)施和成本效益評(píng)估提供具體參考。1. 政務(wù)云不是“買臺(tái)服務(wù)器”那么簡(jiǎn)單從三十個(gè)孤島到一個(gè)平臺(tái)北京政務(wù)云這個(gè)案例最反直覺(jué)的一點(diǎn)是它把近三十個(gè)委辦局的小數(shù)據(jù)中心全砍了統(tǒng)一收編到一個(gè)云平臺(tái)上。這套由華為交付的互聯(lián)網(wǎng)云方案本質(zhì)上是給北京市電子政務(wù)外網(wǎng)建了一個(gè)從服務(wù)器、存儲(chǔ)、安全設(shè)備到云平臺(tái)和運(yùn)維的完整 IaaS 底座承載的是計(jì)生、社保、醫(yī)保、視頻北京這類直接面向市民的民生業(yè)務(wù)。結(jié)果也很直接計(jì)算資源利用率從不到 16% 拉到 55%互聯(lián)網(wǎng)出口統(tǒng)一后安全威脅降到原來(lái)的 5%運(yùn)維人員從七十多人壓到 5 人。如果你正在做政務(wù)云、國(guó)企私有云或者多云整合的項(xiàng)目這份方案的參考價(jià)值不光是技術(shù)選型更是“遷移怎么組織、邊界怎么劃分、坑在哪里”的完整樣本。2. IaaS 平臺(tái)怎么搭從硬件選型到云平臺(tái)層的關(guān)鍵參數(shù)2.1 資源池設(shè)計(jì)先把“集中化”這件事想清楚政務(wù)云和商業(yè)云最大的不同是它要先回答一個(gè)問(wèn)題哪些業(yè)務(wù)能上云、哪些暫時(shí)不能。北京政務(wù)云的思路是“統(tǒng)一承載、分權(quán)分域”把原來(lái)分散在各委辦局小數(shù)據(jù)中心的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源收編為一個(gè)邏輯資源池再按委辦局的業(yè)務(wù)屬性切成不同的資源分區(qū)。這個(gè)設(shè)計(jì)看起來(lái)簡(jiǎn)單真正落地時(shí)最考驗(yàn)人的是容量規(guī)劃——你不能簡(jiǎn)單地把三十個(gè)數(shù)據(jù)中心的峰值需求加起來(lái)當(dāng)總?cè)萘恳驗(yàn)椴煌k局的業(yè)務(wù)峰值時(shí)段不同資源共享后總?cè)萘渴切∮诜逯弹B加的。我當(dāng)時(shí)拆這個(gè)案例時(shí)做了一張粗略的資源估算表思路可以復(fù)用資源項(xiàng)傳統(tǒng)模式按委辦局峰值求和云模式按共享池規(guī)劃備注CPU 總量各局峰值之和 × 1.5 冗余各局平均負(fù)載之和 × 1.2 冗余共享池靠錯(cuò)峰省冗余內(nèi)存同左通常按物理機(jī)配置按虛擬機(jī)規(guī)格累加后 × 1.3預(yù)留內(nèi)存超分空間存儲(chǔ)容量各局實(shí)際占用 × 2各局實(shí)際占用 × 1.5去重和快照減少冗余互聯(lián)網(wǎng)帶寬三十個(gè)出口之和統(tǒng)一出口的 60%70%安全設(shè)備并聯(lián)處理這套估算方法不是我發(fā)明的是政務(wù)云項(xiàng)目里比較通用的規(guī)劃邏輯。核心思路是先摸清每個(gè)委辦局業(yè)務(wù)的真實(shí)負(fù)載曲線再做總量削峰填谷而不是拍腦袋定規(guī)格。如果各局業(yè)務(wù)高峰期恰好重疊那共享池的優(yōu)勢(shì)會(huì)被削弱這一步做扎實(shí)了后面資源利用率提升才有基礎(chǔ)。2.2 硬件選型國(guó)產(chǎn)化約束下的服務(wù)器、存儲(chǔ)與網(wǎng)絡(luò)方案里明確寫(xiě)了“華為唯一提供全套自主知識(shí)產(chǎn)權(quán)產(chǎn)品”這在政務(wù)項(xiàng)目里不是簡(jiǎn)單的一句宣傳而是直接影響硬件選型的硬約束。服務(wù)器層面用的是華為自研的 Taishan 系列和 FusionServer 混搭關(guān)鍵業(yè)務(wù)跑在虛擬化集群上非關(guān)鍵業(yè)務(wù)跑在容器節(jié)點(diǎn)上。存儲(chǔ)層面采用 FusionStorage 分布式存儲(chǔ)三副本策略保證數(shù)據(jù)安全同時(shí)支持在線擴(kuò)容。網(wǎng)絡(luò)層面值得多說(shuō)一句。政務(wù)云的網(wǎng)絡(luò)分區(qū)一般至少分為政務(wù)外網(wǎng)接入?yún)^(qū)、核心業(yè)務(wù)區(qū)、DMZ 區(qū)、管理區(qū)和存儲(chǔ)區(qū)。每個(gè)區(qū)之間通過(guò)安全設(shè)備或防火墻做訪問(wèn)控制各區(qū)之間的流量走向要提前畫(huà)清楚。我當(dāng)時(shí)梳理這套網(wǎng)絡(luò)分區(qū)時(shí)的一個(gè)經(jīng)驗(yàn)是管理區(qū)和業(yè)務(wù)區(qū)必須物理分離或強(qiáng)邏輯隔離否則運(yùn)維誤操作導(dǎo)致業(yè)務(wù)中斷是早晚的事。華為那套方案里強(qiáng)調(diào)安全設(shè)備、防火墻的部署本質(zhì)上解決的就是這個(gè)隔離問(wèn)題。2.3 云平臺(tái)層OpenStack 架構(gòu)與多租戶管理政務(wù)云平臺(tái)的底座一般基于 OpenStack 架構(gòu)來(lái)搭北京政務(wù)云也是走的這個(gè)路線。OpenStack 在這里承擔(dān)的是計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源的統(tǒng)一調(diào)度上層再封裝一層政務(wù)云運(yùn)營(yíng)管理平臺(tái)對(duì)外提供租戶管理、配額管理、工單流程、計(jì)費(fèi)內(nèi)部核算等功能。多租戶管理是政務(wù)云區(qū)別于企業(yè)私有云的核心點(diǎn)。每個(gè)委辦局是一個(gè)租戶租戶之間網(wǎng)絡(luò)隔離、資源配額隔離、操作審計(jì)隔離。華為云的實(shí)現(xiàn)方式是底層用 OpenStack 的 project租戶隔離網(wǎng)絡(luò)用 VPC 或 VLAN 隔離安全組規(guī)則按租戶獨(dú)立配置。如果你要自己搭一套類似的平臺(tái)硬件資源池之上至少要明確這幾個(gè)參數(shù)配置項(xiàng)參考值說(shuō)明計(jì)算節(jié)點(diǎn) CPU 超分比4:18:1取決于業(yè)務(wù)類型數(shù)據(jù)庫(kù)類不超分存儲(chǔ)副本策略三副本政務(wù)數(shù)據(jù)不能丟兩副本風(fēng)險(xiǎn)大租戶配額默認(rèn)值16 vCPU / 32GB 內(nèi)存 / 500GB 存儲(chǔ)可按需申請(qǐng)調(diào)整虛擬機(jī)快照保留數(shù)35 份太多占存儲(chǔ)太少不好回溯心跳網(wǎng)絡(luò)與業(yè)務(wù)網(wǎng)絡(luò)必須分離避免管理網(wǎng)擁塞影響業(yè)務(wù)我拆這份方案文檔時(shí)最大的感觸是技術(shù)棧本身不神秘OpenStack 早已不是新鮮詞但政務(wù)場(chǎng)景對(duì)穩(wěn)定性、合規(guī)性、國(guó)產(chǎn)化的要求把很多在互聯(lián)網(wǎng)公司習(xí)以為常的做法給否決掉了——比如操作系統(tǒng)不能用社區(qū)版 CentOS 直接上生產(chǎn)得用有服務(wù)保障的商用發(fā)行版或國(guó)產(chǎn)化操作系統(tǒng)虛擬化底層要有國(guó)產(chǎn)生態(tài)適配光這一步就要做大量兼容性測(cè)試。3. 業(yè)務(wù)云化遷移P2V、V2V 不是跑個(gè)工具那么簡(jiǎn)單3.1 分階段遷移流程從現(xiàn)狀評(píng)估到業(yè)務(wù)上線政務(wù)業(yè)務(wù)遷移跟普通企業(yè)應(yīng)用遷移最大的區(qū)別在兩點(diǎn)一是不能長(zhǎng)時(shí)間中斷服務(wù)二是數(shù)據(jù)敏感不能被泄露。華為方案里把遷移分成五個(gè)階段——現(xiàn)狀評(píng)估、規(guī)劃設(shè)計(jì)、實(shí)施驗(yàn)證、試運(yùn)行、業(yè)務(wù)上線。這個(gè)流程不是走過(guò)場(chǎng)每一階段都有明確的產(chǎn)出物和驗(yàn)收標(biāo)準(zhǔn)。我做遷移時(shí)一般這樣拆解現(xiàn)狀評(píng)估盤(pán)點(diǎn)每臺(tái)物理機(jī)的配置、操作系統(tǒng)版本、中間件版本、數(shù)據(jù)庫(kù)版本、業(yè)務(wù)依賴關(guān)系、數(shù)據(jù)量、峰值帶寬。政務(wù)系統(tǒng)里最常翻車的不是應(yīng)用本身而是老舊系統(tǒng)的中間件和數(shù)據(jù)庫(kù)版本太老虛擬化平臺(tái)不支持。規(guī)劃設(shè)計(jì)確定每個(gè)業(yè)務(wù)系統(tǒng)的遷移順序先邊緣后核心、遷移窗口一般選凌晨業(yè)務(wù)低峰、回退方案。實(shí)施驗(yàn)證先在云平臺(tái)上做鏡像模擬驗(yàn)證系統(tǒng)能正常啟動(dòng)、數(shù)據(jù)能正常讀寫(xiě)、網(wǎng)絡(luò)策略正確。試運(yùn)行灰度切流量觀察 12 周確認(rèn)穩(wěn)定后正式割接。業(yè)務(wù)上線被遷移業(yè)務(wù)在新平臺(tái)正式對(duì)外服務(wù)同時(shí)持續(xù)監(jiān)控資源使用情況。按我的經(jīng)驗(yàn)整個(gè)流程里最耗時(shí)的是第一步和第三步。現(xiàn)狀評(píng)估往往要花掉整個(gè)遷移計(jì)劃三分之一的時(shí)間因?yàn)槔吓f政務(wù)系統(tǒng)的文檔往往不全很多業(yè)務(wù)邏輯只有運(yùn)維老人才知道。實(shí)施驗(yàn)證階段虛擬機(jī)模板的定制化、操作系統(tǒng)內(nèi)核參數(shù)的調(diào)優(yōu)、數(shù)據(jù)庫(kù)驅(qū)動(dòng)的兼容性每一步都可能在深夜加班時(shí)突然炸出個(gè)新問(wèn)題。3.2 P2V 與 V2V 遷移命令示例與常見(jiàn)配置P2V物理機(jī)到虛擬機(jī)和 V2V虛擬機(jī)到虛擬機(jī)是遷移工作里最常用的兩類工具。華為在這里提供了自動(dòng)化遷移工具鏈但從操作角度你完全可以先用開(kāi)源的方案打通流程。一個(gè)典型的 P2V 遷移過(guò)程可以用以下思路實(shí)現(xiàn)# 1. 在源物理機(jī)上收集系統(tǒng)信息以 Linux 為例 uname -a cat /etc/os-release df -hT fdisk -l lspci | grep -i raid # 2. 檢查源系統(tǒng)是否有特殊驅(qū)動(dòng)或硬件依賴 lsmod | grep -E raid|scsi|nvme ethtool -i eth0 # 3. 使用 virt-v2v 做離線轉(zhuǎn)換常見(jiàn)做法 virt-v2v -i disk -r -o local -os /data/vm-images \ --network bridge:br0 \ --machine-readable \ /dev/sda # 4. 轉(zhuǎn)換完成后在云平臺(tái)上創(chuàng)建虛擬機(jī)并掛載磁盤(pán)調(diào)整啟動(dòng)順序 # 5. 啟動(dòng)前先做一次文件系統(tǒng)檢查 fsck -y /dev/vda這段命令里的核心參數(shù)在幾個(gè)地方-i disk -r表示輸入是物理磁盤(pán)且自動(dòng)識(shí)別磁盤(pán)順序-o local -os /data/vm-images指定轉(zhuǎn)換后鏡像的輸出路徑--network bridge:br0把虛擬機(jī)的網(wǎng)卡橋接到目標(biāo)云平臺(tái)的業(yè)務(wù)網(wǎng)絡(luò)上。這里有個(gè)容易被忽略的點(diǎn)virt-v2v轉(zhuǎn)換出來(lái)的鏡像默認(rèn)磁盤(pán)控制器可能是 virtio如果源系統(tǒng)的內(nèi)核不帶 virtio 驅(qū)動(dòng)轉(zhuǎn)換出來(lái)的虛擬機(jī)根本起不來(lái)。所以在轉(zhuǎn)換前一定要確認(rèn)源內(nèi)核支持 virtio_blk或者用-o rhv這類目標(biāo)平臺(tái)模板自動(dòng)注入驅(qū)動(dòng)。V2V 遷移更常見(jiàn)的是跨虛擬化平臺(tái)遷移比如從 VMware 遷到 OpenStack。做法有兩種一種是導(dǎo)出 OVF 再導(dǎo)入一種是通過(guò)工具直接轉(zhuǎn)換。命令行工具層面常用qemu-img轉(zhuǎn)換格式# VMware vmdk 轉(zhuǎn) qcow2 qemu-img convert -f vmdk -O qcow2 vmware-disk.vmdk cloud-disk.qcow2 # 轉(zhuǎn)換完成后檢查鏡像信息 qemu-img info cloud-disk.qcow2 # 如需調(diào)整磁盤(pán)大小只能擴(kuò)大不能縮小 qemu-img resize cloud-disk.qcow2 50G幾乎每個(gè)在政務(wù)云項(xiàng)目里做過(guò)遷移的人都經(jīng)歷過(guò)這樣的場(chǎng)景V2V 轉(zhuǎn)換完虛擬機(jī)進(jìn)去一看網(wǎng)卡起不來(lái)因?yàn)?VMware 的 vmxnet3 驅(qū)動(dòng)在 OpenStack 的 virtio 網(wǎng)絡(luò)下沒(méi)有被加載。這種問(wèn)題的解決思路一般是在源虛擬機(jī)里先把 virtio 網(wǎng)卡驅(qū)動(dòng)裝上、把 network 腳本寫(xiě)好再做轉(zhuǎn)換而不是轉(zhuǎn)換完再去補(bǔ)救。3.3 數(shù)據(jù)庫(kù)遷移最容易翻車的環(huán)節(jié)P2V、V2V 遷移的是操作系統(tǒng)和應(yīng)用數(shù)據(jù)庫(kù)遷移是另一個(gè)層級(jí)的問(wèn)題。政務(wù)系統(tǒng)后臺(tái)的數(shù)據(jù)庫(kù)大多是 Oracle、人大金倉(cāng)數(shù)據(jù)庫(kù)或開(kāi)源 MySQL、PostgreSQL不同數(shù)據(jù)庫(kù)之間還有遷移的工具選擇問(wèn)題。常見(jiàn)的做法是先做結(jié)構(gòu)遷移再做數(shù)據(jù)遷移最后做增量同步驗(yàn)證。結(jié)構(gòu)遷移相對(duì)簡(jiǎn)單數(shù)據(jù)遷移才是真正考驗(yàn)?zāi)托牡沫h(huán)節(jié)# MySQL 邏輯備份再導(dǎo)入常見(jiàn)做法 mysqldump -u admin -p --single-transaction --routines --triggers \ --databases gov_service gov_service_full.sql # 導(dǎo)入目標(biāo)庫(kù) mysql -u admin -p -h 10.0.8.10 gov_service gov_service_full.sql # 如果要更快的大表遷移用物理備份 xtrabackup --backup --target-dir/data/backup/mysql/ \ --useradmin --password*** xtrabackup --prepare --target-dir/data/backup/mysql/ # 把備份目錄同步到新庫(kù)對(duì)應(yīng)的 data 目錄后再調(diào)整權(quán)限和配置這里最容易被忽略的是--single-transaction這個(gè)參數(shù)不加它備份過(guò)程中如果有寫(xiě)操作備份數(shù)據(jù)會(huì)不一致。政務(wù)系統(tǒng)白天都在對(duì)外服務(wù)必須保證備份的一致性。另一個(gè)經(jīng)驗(yàn)是大表數(shù)據(jù)量超過(guò) 50GB 就別用邏輯備份了物理備份加增量同步效率高得多但物理備份對(duì)版本的兼容性要求高M(jìn)ySQL 小版本不一致直接恢復(fù)會(huì)報(bào)錯(cuò)。數(shù)據(jù)庫(kù)遷移時(shí)我會(huì)額外注意三點(diǎn)一是數(shù)據(jù)庫(kù)字符集政務(wù)老系統(tǒng)最常見(jiàn)的是 GBK新云平臺(tái)默認(rèn) UTF8字符集不一致會(huì)出現(xiàn)亂碼二是自增主鍵沖突多庫(kù)合并到一個(gè)庫(kù)時(shí)容易出現(xiàn)三是視圖、存儲(chǔ)過(guò)程、觸發(fā)器這些對(duì)象備份時(shí)容易遺漏光有表數(shù)據(jù)沒(méi)有觸發(fā)器業(yè)務(wù)邏輯就悄悄丟了。4. 資源整合與統(tǒng)一管控從“信息孤島”到分權(quán)分域4.1 網(wǎng)絡(luò)出口統(tǒng)一安全策略的收斂與配置要點(diǎn)北京政務(wù)云把近三十個(gè)互聯(lián)網(wǎng)出口收成一個(gè)出口這不僅是物理拓?fù)涞淖兓且淮伟踩呗缘拇笫諗?。原?lái)每個(gè)委辦局自己管出口安全水平參差不齊有的局連基礎(chǔ)的入侵檢測(cè)都沒(méi)有統(tǒng)一出口后安全能力可以集中建設(shè)。出口收斂后的架構(gòu)一般是統(tǒng)一互聯(lián)網(wǎng)出口 → 防火墻集群 → 入侵檢測(cè)/防御系統(tǒng) → 負(fù)載均衡 → 政務(wù)外網(wǎng)核心交換區(qū)。訪問(wèn)控制策略不再針對(duì)各局的獨(dú)立 IP 段分別放行而是通過(guò)虛擬化防火墻按租戶隔離。具體到配置層面常見(jiàn)的做法是防火墻雙機(jī)熱備加策略分組# 防火墻策略分組邏輯示例非具體廠商命令 zone: untrust (internet) zone: dmz (web-server) zone: trust (internal) # 每條業(yè)務(wù)訪問(wèn)路徑對(duì)應(yīng)一條策略 # 社保系統(tǒng)互聯(lián)網(wǎng)用戶 - untrust - dmz(web) - trust(app) - trust(db) policy 1: 允許 https 從 untrust 到 dmz 的 10.0.10.0/24 policy 2: 允許 http 從 dmz 到 app 區(qū) 10.0.20.0/24 policy 3: 僅允許 3306 端口從 app 區(qū)到 db 區(qū) 10.0.30.0/24配置策略時(shí)最大的坑是順序防火墻策略從上到下匹配如果前面有一條寬的 deny 策略后面再精細(xì)的 allow 也不會(huì)生效。政務(wù)場(chǎng)景里經(jīng)常出現(xiàn)為了臨時(shí)解決問(wèn)題加一條寬策略事后忘了收緊——半年后做安全審計(jì)時(shí)才發(fā)現(xiàn)一堆失效但未刪除的策略。我的習(xí)慣是每條策略都帶生命周期字段定期清理。4.2 分權(quán)分域運(yùn)維配額、權(quán)限與審計(jì)的落地運(yùn)維從各委辦局獨(dú)立運(yùn)維收編到統(tǒng)一政務(wù)云運(yùn)維中心不是簡(jiǎn)單地一個(gè)團(tuán)隊(duì)接管所有機(jī)器而是通過(guò)分權(quán)分域讓各局在自己的權(quán)限范圍內(nèi)自助運(yùn)維。華為方案里提到的“可視化運(yùn)維系統(tǒng)”落地時(shí)大概對(duì)應(yīng)這四塊能力運(yùn)維能力實(shí)現(xiàn)方式關(guān)鍵參數(shù)租戶資源配額每個(gè)委辦局一個(gè)租戶資源配額可彈性調(diào)整CPU/內(nèi)存/存儲(chǔ)配額按需設(shè)置操作權(quán)限分級(jí)超管、租戶管理員、業(yè)務(wù)操作員三級(jí)RBAC 模型最小權(quán)限原則監(jiān)控告警物理層、虛擬化層、業(yè)務(wù)層層層覆蓋CPU 超 80%、磁盤(pán)余量小于 20% 告警操作審計(jì)所有運(yùn)維操作留痕定期導(dǎo)出至少保留 6 個(gè)月以上配額管理是政務(wù)云日常運(yùn)維里最常被挑戰(zhàn)的一環(huán)。各局總是覺(jué)得自己的配額不夠用但實(shí)際資源利用率往往很低。我的處理辦法是先給各局一個(gè)基礎(chǔ)配額運(yùn)行一個(gè)月后看真實(shí)使用率曲線再按“使用率超過(guò) 70% 才擴(kuò)容”的原則調(diào)整。這樣既避免一開(kāi)始資源被占著不用也給了各局一個(gè)明確的擴(kuò)容預(yù)期。運(yùn)維審計(jì)這塊政務(wù)項(xiàng)目有硬性要求登錄堡壘機(jī)、操作記錄、命令行輸入輸出都要留存。實(shí)踐中不光要留操作日志還要定期做回放審計(jì)防止“有權(quán)限的人做了不該做的事”。5. 華為方案的避坑指南政務(wù)云落地最容易踩的五個(gè)坑5.1 坑一老系統(tǒng)在虛擬化平臺(tái)啟動(dòng)失敗現(xiàn)象P2V 遷移完成后虛擬機(jī)無(wú)法正常啟動(dòng)卡在引導(dǎo)階段或者啟動(dòng)后黑屏。原因源物理機(jī)的磁盤(pán)控制器驅(qū)動(dòng)與虛擬化平臺(tái)不兼容常見(jiàn)于老的 Windows Server 2003 或 CentOS 5/6 系統(tǒng)其自帶的 IDE 或老 RAID 驅(qū)動(dòng)無(wú)法驅(qū)動(dòng) virtio 磁盤(pán)。解決在遷移前先給源系統(tǒng)打入 virtio 驅(qū)動(dòng)或者在目標(biāo)云平臺(tái)創(chuàng)建虛擬機(jī)時(shí)把磁盤(pán)總線類型調(diào)整為 IDE 或 SATA先把系統(tǒng)拉起再裝 virtio 驅(qū)動(dòng)最后切回 virtio 總線。這個(gè)坑在政務(wù)老系統(tǒng)里出現(xiàn)頻率極高幾乎每次遷移都會(huì)遇到至少一兩臺(tái)這樣的機(jī)器。5.2 坑二數(shù)據(jù)庫(kù)字符集不一致導(dǎo)致亂碼現(xiàn)象業(yè)務(wù)系統(tǒng)遷移到新云平臺(tái)后頁(yè)面顯示的問(wèn)號(hào)、亂碼、個(gè)別漢字變成“口”字。原因源庫(kù)使用 GBK/GB2312 字符集新庫(kù)默認(rèn)為 UTF8數(shù)據(jù)在邏輯導(dǎo)入導(dǎo)出時(shí)沒(méi)有做字符集轉(zhuǎn)換或轉(zhuǎn)換映射失敗。解決在遷移規(guī)劃階段就要確認(rèn)源庫(kù)和目標(biāo)庫(kù)的字符集用SELECT character_set_name FROM information_schema.columns WHERE table_schemaxxx檢查所有表的字符集。如果涉及轉(zhuǎn)換用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4在源庫(kù)先把數(shù)據(jù)轉(zhuǎn)到 UTF8再導(dǎo)出導(dǎo)入而不是導(dǎo)出后再轉(zhuǎn)。5.3 坑三網(wǎng)絡(luò)策略順序錯(cuò)誤導(dǎo)致業(yè)務(wù)間無(wú)法互訪現(xiàn)象遷移后的業(yè)務(wù)系統(tǒng)在測(cè)試時(shí)一切正常正式上線后某些模塊無(wú)法訪問(wèn)報(bào)連接超時(shí)或連接被重置。原因云平臺(tái)安全組或物理防火墻策略順序問(wèn)題——寬泛的 deny 規(guī)則被排在精細(xì)的 allow 規(guī)則前面或者只關(guān)注了東西向流量忽略了南北向流量的策略配置。解決做網(wǎng)絡(luò)策略時(shí)按“最小化開(kāi)放”逐條梳理每加一條策略都做連通性驗(yàn)證同時(shí)定期導(dǎo)出策略清單做人工審查清理長(zhǎng)期無(wú)命中流量的僵尸策略。5.4 坑四業(yè)務(wù)高峰期遷移導(dǎo)致上線窗口失控現(xiàn)象遷移選在業(yè)務(wù)高峰期窗口強(qiáng)行割接導(dǎo)致部分業(yè)務(wù)超時(shí)中斷不得不回退。原因政務(wù)業(yè)務(wù)也有高峰比如社保申報(bào)月初、醫(yī)保結(jié)算月底、公積金提取集中在月末如果遷移窗口沒(méi)有避開(kāi)這些周期一次性割接大概率出問(wèn)題。解決遷移窗口選在月初首周之后的周二至周四凌晨避開(kāi)業(yè)務(wù)結(jié)算周期大業(yè)務(wù)系統(tǒng)先做灰度放量比如先切 5% 流量驗(yàn)證 24 小時(shí)再全量切換。政務(wù)業(yè)務(wù)回退方案必須有而且要提前演練。5.5 坑五國(guó)產(chǎn)化硬件兼容性驗(yàn)證不充分現(xiàn)象新采購(gòu)的國(guó)產(chǎn)化服務(wù)器或存儲(chǔ)設(shè)備在資源池上線后虛擬機(jī)性能不穩(wěn)定存儲(chǔ) IO 延遲抖動(dòng)。原因國(guó)產(chǎn)化硬件與虛擬化軟件之間的兼容性列表更新滯后部分驅(qū)動(dòng)沒(méi)有經(jīng)過(guò)充分驗(yàn)證。解決在設(shè)備采購(gòu)前就與云平臺(tái)廠商確認(rèn)兼容性列表在采購(gòu)入庫(kù)后先建一個(gè)小規(guī)模驗(yàn)證環(huán)境做壓測(cè)和長(zhǎng)穩(wěn)測(cè)試至少連續(xù)運(yùn)行 72 小時(shí)以上驗(yàn)證通過(guò)后再并入生產(chǎn)資源池。不要看廠商官網(wǎng)寫(xiě)了兼容就直接上生產(chǎn)。6. 驗(yàn)證一份政務(wù)云方案是否靠譜三個(gè)必須復(fù)盤(pán)的數(shù)據(jù)拆這份方案時(shí)我給自己定了個(gè)規(guī)矩所有遷移完成或方案評(píng)審后必須復(fù)盤(pán)三個(gè)數(shù)據(jù)——資源利用率提升是不是實(shí)打?qū)?、安全威脅下降是怎么統(tǒng)計(jì)的、運(yùn)維人力下降有沒(méi)有水分。資源利用率這塊不要只看最終數(shù)字。方案說(shuō)從 16% 提到 55%我會(huì)反過(guò)來(lái)問(wèn)這個(gè) 55% 是 CPU 利用率還是整體資源利用率統(tǒng)計(jì)周期是峰值還是均值有沒(méi)有把存儲(chǔ)容量當(dāng)作計(jì)算依據(jù)只有搞清楚口徑這個(gè)數(shù)字才有參考意義。安全威脅降為原來(lái)的 5%要看統(tǒng)一出口之前是不是本來(lái)就把掃描日志分到了不同的系統(tǒng)統(tǒng)一后集中統(tǒng)計(jì)數(shù)據(jù)才更完整——這存在口徑變化導(dǎo)致數(shù)字大幅變化的可能不算造假但需要明辨。運(yùn)維人力從 70 人降到 5 人要確認(rèn)這 5 人里是否包含了各局保留的自運(yùn)維人員以及外包團(tuán)隊(duì)是否計(jì)入。驗(yàn)證時(shí)我常用的方法很樸素找兩份監(jiān)控報(bào)表遷移前和遷移后的同口徑對(duì)比找三個(gè)典型業(yè)務(wù)系統(tǒng)分別問(wèn)他們的真實(shí)體驗(yàn)——啟動(dòng)時(shí)間有沒(méi)有變慢、查詢有沒(méi)有超時(shí)、夜間批量作業(yè)有沒(méi)有被虛擬機(jī)搶占 CPU。技術(shù)指標(biāo)再漂亮最后都要落到使用單位的一句“比原來(lái)快多了”或者“還不如原來(lái)穩(wěn)定”上。還有一個(gè)我摸出來(lái)的小技巧拿到任何政務(wù)云方案先看它怎么處理“數(shù)據(jù)遷移失敗的回退路徑”和“老舊系統(tǒng)的兼容性測(cè)試方案”。這兩點(diǎn)寫(xiě)清楚了方案大概率靠譜這兩點(diǎn)含糊其辭后面交接和上線大概率要出幺蛾子。從那以后我每次評(píng)審云平臺(tái)方案都強(qiáng)制走一遍這個(gè)邏輯資源利用率怎么算的、安全數(shù)據(jù)口徑是什么、運(yùn)維人力怎么定義、回退方案有沒(méi)有演練過(guò)。這套功課做完心里基本就有底了。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取