雲音樂貴州機房遷移總體方案回顧

一、背景

2023年確定要將雲音樂整體服務搬遷至貴州機房，專案需要在各種限制條件下，保障2000+應用、100w+QPS的服務穩定遷移，是雲音樂歷史上規模最大、人員最多、難度最高的技術專案。在此過程中，解決了大量歷史技術債務，同時化解了大量新增系統性風險。以下為總體方案回顧。

二、專案難點

• 遷移規模大
• 此次需要雲音樂以及旗下獨立App的服務均整體遷移至貴州。涉及2000+應用、100w+QPS的穩定遷移，同時涉及中介軟體、儲存、機房、三方依賴服務等整體的搬遷，搬遷規模大。
• 業務複雜度高
• 場景複雜。遷移規模大，帶來更廣的業務場景覆蓋。而不同的場景對資料一致性要求不同、延遲敏感度不同。遷移方案需要考慮各種場景帶來的問題，並提供標準化的解決方案。
• 服務間依賴複雜。此次帶來約2000+應用的搬遷，各服務間的呼叫和依賴情況複雜，在分批遷移方案中需要協調，以及解決遷移期間跨機房30msRT上升帶來的問題。
• 歷史積弊多
• 貴州遷移前，存在諸多歷史技術積弊，影響著全站整體的穩定性。
• 新增風險大
• 貴州遷移帶來諸多新增風險，且風險大、解決難度高。
• 部分場景無法做到真實環境全流程預演。
• 在基礎技術建設上，也有一些不足的情況，影響整體搬遷執行效率、遷移準確性。
• 限制條件嚴苛
• 雲音樂有著大量的使用者基數，此次搬遷要求：不停機遷移、不產生P2及以上事故。除此之外還有機器、網路頻寬、網路穩定性、網路RT、遷移方案等限制條件。
• 事項推進&協調難度大
• 此次搬遷規模大，同樣，參與人員規模大，整體協調難度大
• 此外帶來較多的人因風險。可能因極小的細節未執行到位，就會造成全域性事故。

三、重點限制&要求

• 儘可能少採購或不採購額外的機器，貴州和杭州無法完全對等部署。
• 杭州與貴州的長傳頻寬控制在200Gbps以內，且存在閃斷的可能性，各遷移方案需要重點考慮閃斷帶來的影響。
• 貴州機房與杭州機房之間網路延遲約30ms，各方遷移方案需重點考慮機房延遲帶來的影響。
• 業務可用性要求：不影響核心重點業務場景的可用性，不出現P2及以上事故。
• 控制遷移方案對業務程式碼的侵入。

四、分批方案

1. 分批的原則

1.1 團隊/領域間解耦

大團隊/領域之間的遷移方案儘可能解耦，分不同批次搬遷。好處：

• 可以將問題拆分、領域清晰。
• 大資料、演算法、雲音樂技術中心序列搬遷，可以實現機器資源池共享，降低機器採購成本。
• 降低單一團隊/領域切流時問題處理複雜度。

1.2 服務端流量自閉環

雲音樂服務端需要將流量閉環在同一個機房，避免產生跨區域呼叫。

雲音樂經過微服務之後，目前存在千+服務，各服務間依賴複雜。在貴州機房與杭州機房之間網路延遲約30ms的背景下，每產生一次跨區域呼叫，則RT上升30ms。

1.3 C端優先

優先遷移C端相關的應用及其資源，其次B端。

關於此處，會有同學認為優先B端可能會更穩，但優先採用B端優先，會有如下問題：

• B端服務搬遷後，騰挪的機器有限。
• B端服務與C端服務相差較大，即使B端服務先行搬遷無問題，也不足以證明C端服務就一定沒問題。

對於如何保障C端服務搬遷的穩定性，在文章後續章節展開。

1.4 在可用資源範圍內

遷移期間，需要在貴州準備與杭州同等規模的機器資源，因此批次不可能不受到資源的限制。其主要受限制資源為：

• 機器資源
• 貴州&杭州的長傳頻寬資源

因此，按照以上原則進行分批後，若資源仍不足，再根據團隊/領域拆分出第二批

2. 最終分批方案

基於以上原則，最終分批方案如下所示

• 大資料、演算法、技術中心序列搬遷。
• 心遇因強依賴雲信IM服務，與雲信服務獨立搬遷
• 技術中心應用基本一批次全部搬遷完成。
• 技術中心的轉碼、公技側後臺、質量側系統在第二批次搬遷完成。

五、切流方案

1. 切流的原則

1.1 可灰度

能夠按照使用者ID、裝置ID、IP、流量標幾個維度逐步灰度切流。

• 利於預熱。在服務啟動後，快取、連線池需要隨請求逐步預熱，若流量直接全部打過來，可能會將服務打垮。
• 利於測試。能夠灰度測試整體功能，避免大面積異常。

1.2 可回滾

儘管做了各種穩定性保障來避免回滾，但是如遇到極端情況，仍有整體回滾的可能性。因此搬遷方案必須可回滾。

1.3 控制長傳頻寬

在切流過程中，杭州和貴州之間會有大量的服務訪問、資料傳輸，從而可能突破長傳頻寬200Gbps的限制。因此切流方案中必須減少不必要的跨區域流量。

2. 切流方案

2.1 切流點選擇

貴州機房遷移切流點選擇.png

服務端整體通用架構簡化後，如上圖所示，因此有如下幾個切入點：

• 客戶端切流。客戶端透過動態切換域名配置，可實現流量的切換。切流演算法可以與閘道器使用保持一致，我們在貴州遷移中就採用了此方案，從而大幅降低貴州與杭州的長傳頻寬。
• DNS切換。因DNS存在快取過期，不適合作為流量控制的主要手段。在貴州遷移中，我們主要用其作為長尾流量的切換的手段。
• 四層LB切流、Nginx切流。主要由SA側負責，因自動化和操作複雜度等因素，在貴州遷移中，四層LB切流只用於輔助切流手段，Nginx因過高的人工操作複雜度，不用於切流。
• 閘道器切流。閘道器作為服務端廣泛接觸的首要流量入口，其系統建設相對完善、自動化程度較高，因此作為主要切流手段。在此次遷移中，閘道器支援按使用者ID、裝置ID、IP進行按比例切流。
• 定時任務、MQ切換。主要用於定時任務、MQ的流量切換。
• RPC流量控制。RPC流量路由策略與閘道器保持一致，依據切流比例，進行RPC流量呼叫。從而避免跨機房RT的不可控。
• 儲存層切換。主要負責儲存的切換。

2.2 儲存層遷移策略

雲音樂業務場景較多，不同場景下對資料一致性的要求也不一樣，例如：營收下的訂單類場景需要資料強一致性，而點贊需要資料最終一致性即可。

在涉及不同的儲存時，也有著多種多樣的遷移策略。對此，中介軟體以及各儲存層支援了不同的遷移策略選擇，各個業務基於不同的場景，選擇正確的策略。遷移策略主要如下：

型別	遷移策略
DB	讀本地寫遠端、讀遠端寫遠端、讀本地寫本地、禁寫
Redis	讀寫遠端+需要禁寫、讀本地寫遠端+需要禁寫、讀寫本地
Memcached	非同步雙寫、同步雙寫、不同步

2.3 切流步驟

對以上切入點再次進行分類，可再次簡化為流量層切流、儲存層切換。在正式切流時，我們按照如下步驟進行切流。

3. 回滾方案

先儲存層按序切換，然後流量層按序切換。

六、穩定性保障&治理

1. 全域的穩定性風險

• 全域的穩定性風險。我們在做一般的活動穩定性保障時，一般從活動的主鏈路出發，再梳理相關依賴，從而整理出穩定性保障&治理的重點。而這種方法確不適用於貴州機房遷移，從前面的分批概覽圖可得知：此次貴州機房遷移帶來全域的穩定性風險。
• 墨菲定律："如果一件事情有出錯的可能性,那麼它最終一定會出錯。"
• 業界沒有類似的經驗可參考

因此整個專案組也在摸著石頭過河，在此過程中，既有大的方案的設計，也有細枝末節的問題發現和推進處理。總結起來，我們總共從以下幾個方面著手進行穩定性保障：

• 資訊梳理&摸查
• 新增風險發現&處理
• 歷史技術債務處理
• 標準化接入
• 監控告警增強
• 應急預案保障
• 業務側技術方案保障
• 杭州叢集下線保障

2. 資訊梳理&摸查

盤點梳理機器資源情況、網路頻寬、遷移期間服務可用性要求等全侷限制條件，從而確定分批方案、遷移思路。

2.1 機器資源盤點

主要盤點核數、記憶體。在此過程中，也推進了資源利用率最佳化、廢棄服務下線等事宜。透過如下公式計算機器資源缺口：搬遷機器缺口 = 搬遷所需數量 -（可用數量+可最佳化數量）

2.2 長傳頻寬盤點

需要控制雲音樂的長傳頻寬總量 <= 相對安全的頻寬量相對安全的頻寬量 = (長傳頻寬總量 / 2 x 0.8) - 已被佔用頻寬量

2.3 遷移期間服務可用性要求

若業務允許全站停服遷移、或僅保障少量核心服務不掛，那麼整體遷移方案會簡單很多。因此業務對遷移期間的可用性要求，關乎著搬遷方案如何設計。最終討論後確定，需要：遷移不產生P2及以上事故

2.4 服務間跨區域呼叫RT摸查

基於Trace鏈路，預測分批情況下RT增長情況。

3. 新增系統性風險

此次貴州遷移主要帶來的新增系統性風險是：

• 因公網質量問題，帶來遷移後使用者體驗差的風險。
• 因跨機房延遲30ms ，帶來的業務側應用雪崩風險。
• 因跨機房傳輸網路不穩定，帶來的整體系統性風險。
• 因杭州和貴州機房同時部署，帶來的服務節點數量、API數量、RPC數量翻倍風險
• 因大規模資料變更，帶來的系統效能風險。
• 因新機房建設、搬遷，帶來的底層基礎設施風險。
• 因全域團隊協作、大範圍配置變更&釋出，帶來的人因操作、協作風險。

3.1 因公網質量問題，帶來遷移後使用者體驗差的風險

貴州公網質量如何？遷移至貴州之後是否會因公網質量問題，導致使用者體驗差？由於雲音樂使用者基數大，且注重使用者體驗，這個是必須提前摸清的問題。若公網質量真的存在較大問題，雲音樂可能會停止貴州遷移專案。

對此，我們透過如下方式進行了公網質量驗證和保障：

1. 透過客戶端預埋邏輯，抽樣檢測同時請求杭州和貴州機房的RT差異。
2. 透過RT的差異，再下鑽分析杭州和貴州機房的差異點。
3. 解決或排除機房、客戶端、域名配置等差異，最終得出公網質量的差異。
4. 在正式切流前，解決完成客戶端、機房等差異，保障整體網路請求質量。
5. 透過QA側的整體測試。

3.2 因跨機房延遲30ms ，帶來的業務側應用雪崩風險

雲音樂C端服務當前的RT普遍在5~70ms之間，若增加30ms，可能會導致請求堆積、執行緒池打爆等風險。為避免此風險，我們從如下幾個方面入手：

• 儘可能同一批次搬遷，避免長期跨機房呼叫。
• 同一批次應用，基於使用者ID、裝置ID、IP進行Hash，實現同機房呼叫優先。
• 無法同一批次搬遷的應用。
• 確保會只跨一次，避免因迴圈呼叫等原因導致的多次跨機房。
• 需提供降級方案，對服務弱依賴。
• 服務需透過QA側的測試。

3.3 因跨機房傳輸網路不穩定，帶來的整體系統性風險

跨機房網路的現狀和參考資料：

• 共計2條線，單條頻寬為：100Gbps，但建議保持單條利用率在80%及以下。
• 參考網易北京與杭州的長傳頻寬質量。
• 可能會出現單條中斷的情況，在網路側的表現為網路抖動。若單條線中斷，那麼發生故障的請求會重連至另一條線。
• 極低機率出現2條線全部中斷的情況。

基於以上現狀，需要重點考慮並解決：

• 各中介軟體、儲存在切流期間，長傳網路出現問題時的表現、應對和兜底措施。例如ZK重連、重連失敗後的重連風暴問題。
• 各服務在切流完成後，若仍長期使用長傳網路，若長傳網路出現問題的表現、應對和兜底措施。

在貴州遷移專案中，我們對以上重點問題進行了梳理和解決，並制定了各種應急預案和極端情況下的回滾方案。

3.4 因杭州和貴州機房同時部署，帶來的服務節點數量、API數量、RPC數量翻倍風險

因杭州和貴州機房同時部署，帶來的服務節點數量、API數量、RPC數量翻倍風險

在服務節點數量、API數量、RPC數量翻倍後，主要對底層依賴帶來連線、重連上的衝擊，以及原有連線數上限的衝擊。

在我們實際搬遷中，也因遺漏了這一點，導致線上ZK出現瓶頸，進而ZK掛掉的問題。其主要表現為在閘道器場景下存在資料推送瓶頸。最終透過閘道器側的ZK拆分解決該問題。

除此之外，DB、Memcached、Redis、MQ等資源的連線數也可能會超過原先設定的上限，需要評估後進行調整。

3.5 因大規模資料變更，帶來的系統效能風險

大規模資料變更的場景包含但不限於：

• 批次調整配置中心值，因達到配置中心的效能瓶頸，導致配置變更時間過長，或服務掛掉。
• 批次的服務部署、重啟，因達到K8S、構建機的效能瓶頸，導致部署、重啟時間過長，或服務掛掉。
• 對遷移當晚核心路徑上的服務進行集中訪問、操作，因達到服務的效能瓶頸，導致訪問超時、白屏、資料延遲、或服務掛掉的問題。

針對以上風險，我們重點對配置中心、K8S、貴州遷移管控平臺等系統進行了效能最佳化，以支撐整體遷移。

3.6 因新機房建設、搬遷帶來的底層基礎設施風險。

因新機房建設、搬遷帶來的底層基礎設施風險包含但不限於：

• 同城雙活能力的缺失。為應對此風險，我們在邏輯上繼續保留同城雙活的能力，並暫時透過機房不同樓層的部署架構，來儘可能彌補同城雙活能力的缺失。
• 機器上架、環境搭建、網路傳輸等需確保達到驗收標準。為應對此風險，運維側提供相關方案保障整體環境，並最終透過業務側QA驗收。

3.7 因全域團隊協作、大範圍變更&釋出，帶來的人因操作、協作風險

在貴州遷移前，已經有多次發生因配置變更錯誤帶來的事故。而此專案帶來從未有過的全域遷移，全域協作，大範圍變更&釋出，風險不可謂不高。在此過程中，透過了許多方式來保障事項的落地，其中比較關鍵的點，也是專案成功的關鍵點包括：

• 各部門領導與同事的支援。
• 分工明確。在戰略、戰術、細節、事項推進等多個點均有相關人員把控，各司其職。
• 各項資訊的細化梳理&定位。
• 定期的溝通協作會議，透過敏捷式專案管理，進行滾動式問題發現。
• 問題發現、治理、驗證必須閉環。
• 儘可能中心繫統化、自動化處理。無法自動化的，則提供標準化實施手冊。
• 重點問題，case by case，one by one。

4. 歷史技術債務處理

在貴州遷移專案中，比較突出的歷史債務處理有：

• ZK強依賴問題
• 線上業務Kafka遷移Nydus。
• 配置硬編碼
• 服務間依賴改造
• 資源最佳化&控制
• 心遇依賴拆分
• 元資訊不準確
• 元件版本過於陳舊問題
• 測試環境自動化部署成功率低
• 租戶多叢集拆分為多應用

4.1 ZK強依賴問題

ZK的不穩定已導致雲音樂最高出現P1級事故，在貴州遷移專案中，因網路環境、機房環境、遷移複雜度等因素，ZK服務掛掉的機率極大，因此必須不能對其強依賴。

最終中介軟體側對其改造，支援ZK發生故障時，其註冊資訊降級到本地記憶體讀取。並推進相關依賴方進行升級改造。

4.2 線上業務Kafka遷移Nydus。

Nydus作為雲音樂主力MQ產品，相較開源Kafka有更好的監控、運維等能力，Kafka在雲音樂線上業務中已不再推薦使用。在貴州遷移中，MQ也需要進行兩地切換/切流。

主要收益：

• 線上業務穩定性
• Kafka機器資源回收
• MQ切流特性&歷史債務收斂

在推進層面：

• 第一里程碑：生產者完成雙寫
• 第二里程碑：消費者完成雙消費
• 第三里程碑：完成廢棄TOPIC下線、程式碼下線等收尾工作

4.3 配置硬編碼

在貴州遷移專案中，需要做大量的配置遷移、變更。其主要為：機房名、叢集名、機器IP、機器Ingress域名的變化。而這些在配置中心、程式碼、自動化指令碼、JVM引數中均有存在，此外，IP黑白名單還可能涉及到外部廠商的改造變更。

在具體推進上，採用自動化掃描+人工梳理結合，並輔以標準化改造指引文件。

• 自動化掃描：透過程式碼掃描、配置中心掃描、JVM引數掃描、連線掃描等方式進行問題發現。
• 人工梳理：外部廠商、不受Git管控的指令碼、以及運維側的配置（例如：儲存層訪問許可權的黑白名單等）、以及自動化掃描可能的遺漏，由各研發、運維人員再次自行梳理。

4.4 服務間依賴改造

核心應對杭州與貴州跨機房30ms RT和長傳網路不穩定的風險。對迴圈呼叫、不合理依賴、強依賴進行改造。

• 減少不必要依賴。
• 必須不能出現服務跨機房強依賴。
• 不能因迴圈呼叫導致跨機房RT飆升。

4.5 資源最佳化&控制

因貴州需要與杭州同等容量部署，可能存在資源不足的情況。對此需要：

• 統一服務的資源利用率標準，推進資源利用率改造
• 對部分服務進行合併、下線、縮容處理。

4.6 心遇依賴拆分

因心遇強依賴雲信，且雲信IM為心遇核心業務功能，最終確定心遇為獨立批次搬遷。因此心遇依賴的中臺服務、儲存、演算法&大資料相關任務，均需拆分出來，不能與雲音樂耦合，否則會產生跨機房呼叫，影響服務穩定性。

4.7 元資訊不準確

在此次遷移中，存在較多的元資訊不準確的問題，例如：

不足項	解釋
應用的元資訊需要補充、更新	1. 應用歸屬的團隊資訊不準確 2. 應用的廢棄、待廢棄狀態未知 3. 測試應用、非業務應用資訊偏雜亂
應用團隊歸屬資訊多處維護，未統一	應用在多個平臺均有維護，且均存在維護不準確的問題
應用的各項依賴資訊不全	應用依賴的db、redis、memcached資源，以及在配置中心的key無法全面準確拉取
應用的各項依賴資訊視覺化、系統化建設不足	1. 應用依賴的元件版本、依賴的儲存資源等，缺乏友好的視覺化查詢能力。 2. 各項資訊之間的關聯性建設不足
底層中介軟體、儲存元資訊不全	1. 不同的ZK叢集的用處缺乏統一維護。 2. 各項元資訊反查呼叫源IP、叢集、應用、團隊、負責人的能力不足

以上問題在遷移中，透過指令碼、1對1溝通確認、手動梳理等多種方式進行了臨時處理，在貴州遷移後，仍需再全面的系統性規劃。

4.8 元件版本過於陳舊問題

有較多的應用長期不升級，與最新版本跨度較大，存在較多的相容性問題，需要人工進行升級處理。升級流程大致如下：

在遷移中期，我們進行了自動升級平臺建設，基本支援以上升級流程自動化。

4.9 測試環境自動部署成功率低

因此次遷移涉及全部的應用在不同環境的部署，全部人工操作的效率過低，因此我們在非線上環境均由指令碼自動化部署，而測試環境由於維護不足，部署成功率較低。

4.10 租戶多叢集拆分為多應用

當前貴州遷移時整體會按照應用維度進行遷移、切流到貴州。因此對於中臺租戶型應用、多地域註冊型別的應用需要拆分。

5. 標準化接入

除了以上提到的歷史技術債務處理和新增系統性風險，公共技術側大都提供了標準化的接入、改造治理方式。例如：

• 貴州遷移中介軟體方案彙總。涵蓋所有涉及中介軟體的遷移、切流、遷移策略、接入等指導方案。
• 貴州遷移升級指導。涵蓋自動升級與手動升級、腳手架應用與非腳手架應用的升級方案。
• 貴州遷移線上部署指導。涵蓋貴州線上部署前的各項必要準備事項，以及特殊應用的注意事項。
• 貴州遷移監控大盤觀測指導。涵蓋各類遷移監控的觀測指導。
• 中臺、多地域註冊拆分指導。涵蓋中臺租戶、多地域註冊型別應用的拆分指導方案，以及整體的拆分流程、驗證要點等。
• ddb、redis、memcached、KSchedule等非標治理。涵蓋各中介軟體、儲存的非標風險列表、處理辦法等。
• 杭州叢集下線指導。涵蓋杭州叢集如何觀察、縮容、下線、機器回收的指導方案。

6. 監控告警

在監控告警層面，主要提供了：

• 貴州遷移整體大盤監控。提供了遷移相關全域性比例，異常流量，異常比例，能夠區分是遷移導致的還是本身杭州服務就有問題導致。同時整合資源層相關指標，判斷是單個資源有問題還是全部資源有問題。
• 貴州遷移應用監控。提供了單個應用的貴州遷移監控，應用貴州杭州流量比例，異常流量，異常比例，能夠區分是貴州還是杭州的問題。同時有資源相關的指標。
• 杭州叢集與貴州叢集的哨兵監控對比分析。提供指定應用的杭州和貴州叢集在CPU利用率、執行緒池滿、異常比例、RT超時等維度的對比。
• 全域性/應用的SLO監控。提供核心指標受損監控。
• 應用層面的系統監控。研發可透過哨兵、APM來檢視定位具體的問題。

7. 應急預案

在貴州遷移期間，基於以上風險，主要準備如下應急預案：

• 客戶端截流。在開啟後，客戶端將訪問本地或CDN快取，不再向服務端傳送請求。
• 全站服務QPS限流至安全閾值。在開啟後，全站的後端服務將限流調整至較低的安全閾值上，在極端情況下，避免因跨機房RT、跨機房傳輸、跨機房訪問等因素的效能瓶頸引起服務端雪崩。
• 長傳頻寬監控&限流。在開啟後，部分離線資料傳輸任務將會被限流。保障線上業務的頻寬在安全水位下。
• 回滾方案。當出現重大問題，且無法快速解決時，逐步將儲存、流量切回杭州。
• 外網逃生通道。當出現長傳網路完全中斷，需要回滾至杭州。透過外網逃生通道實現配置、核心資料的回滾。
• 業務領域內的應急預案。各業務領域內，需要考慮切流前的主動降級預案、切流中的應急預案。
• 批次重啟。當出現區域性服務必須透過重啟才能解決的問題時，將會啟用批次重啟指令碼實現快速重啟。當出現全域性服務必須透過重啟才能解決問題時，需要當場評估問題從而選擇全量重啟或全量回滾至杭州。

8. 業務技術側方案

業務技術側方案重點包含但不限於：

• 應用搬遷範圍、搬遷批次梳理明確。當上下游依賴的應用處於不同批次時，需要跨團隊溝通協調。
• 明確業務影響，從而確定各應用的中介軟體、儲存遷移策略。
• 歷史技術債務處理
• 標準化接入
• 核心場景穩定性保障方案
• 核心指標監控建設完善。
• 切流SOP。包括切流前（前2天、前1天、前5分鐘）、切流中、切流後各階段的執行事項。
• 切流降級方案、應急預案
• 切流停止標準

9. 杭州叢集下線

在服務遷移至貴州後，若杭州仍有流量呼叫，需排查流量來源，並推進流量下線或轉移至貴州。先縮容觀察，無正常流量、CDN回源等之後，再做叢集下線。

七、測試&演練

此次貴州遷移，在各應用標準化治理之後，透過系統批次工具完成貴州各項環境的搭建、測試環境的批次部署。

1. 測試環境演練

1.1 準備事項

在測試演練開始前，我們重點做了如下準備：

• 貴州測試環境批次建立。透過遷移工具，實現貴州測試叢集的批次建立、配置批次遷移等。
• 應用自動化升級。透過自動升級平臺，實現大規模應用的批次升級，支援了各元件、各應用的多次快速驗證、快速升級。
• 測試環境自動化部署。透過自動化部署指令碼，為支援測試環境能夠多次、高效演練。
• SOP梳理&平臺建設。透過SOP平臺，將SOP文件沉澱為系統能力，實現各SOP能力的系統化。
• 遷移監控大盤建設。透過細化梳理監控指標，構建監控大盤，掌握各應用、各元件在切流期間的表現。

1.2 執行步驟

在測試環境演練，總體思路是逐步擴大驗證範圍，最終達到全域性基本功能基本驗證透過。以下為主要演練順序，每一步視執行結果，再選擇是否重複執行。

順序	驗證事項
1	驗證中介軟體內部邏輯是否正確： 1. 閘道器、RPC、儲存層路由策略是否正確。 2.驗證監控大盤是否正確 3.驗證SOP平臺是否正確 4....
2	驗證儲存層切換是否正確
3	逐一對各業務團隊進行演練： 1.加深各團隊對切流能力的感知。 2.驗證收集中介軟體、儲存在各領域的表現。 3.驗證各團隊、各領域遷移策略的合理性
4	對BFF、FaaS等特殊應用型別進行演練

2. 線上環境演練

因測試環境和線上環境仍存在較大的差異，需要摸清線上真實情況，在演練原則和演練目標上均較測試環境演練有更嚴格、細緻的要求。

2.1 演練原則

• 不對線上資料產生汙染；
• 不產生線上 P2 以上事故。

2.2 演練目標

分類	目標內容
公技演練目標	1. 切流驗證，閘道器，rpc，貴州遷移大盤監控 2.閘道器切流比例、快慢，資料庫 ddb 貴州跨機房建連對業務影響 3.端上切流，閘道器切流驗證
業務演練目標	1.流量切換，貴州跨機房對業務影響 2.業務指標和SLO 3.業務預案有效性驗證 4.RT變化情況
儲存演練目標	1.ddb 複製延遲，連線數(由於跨機房建立DDB連線非常慢, 主要觀察流量到貴州後新建連線對應用和資料庫影響及恢復情況) 2.redis資料同步、整體表現
網路演練目標	1.跨機房延遲情況 2.跨機房頻寬實際佔用 3.網路頻寬佔用監控

2.3 演練終止條件

• P0、P1 核心場景 SLO 95%以下；
• 使用者輿情增長波動明顯；
• 跨機房網路大規模異常；
• 大量業務指標或者資料異常；
• 貴州流量達到預定 90%。

3. 獨立App遷移驗證

在雲音樂主站正式切流前，先對雲音樂旗下獨立App進行了線上搬遷驗證，保障雲音樂遷移時的穩定性。

八、系統沉澱

1. SOP平臺

SOP即標準作業程式（Standard Operating Procedure），源自傳統工業領域，強調將某項操作以標準化、流程化的方式固化下來。

SOP平臺將標準化、流程化的操作進行系統化呈現，並對接各中介軟體平臺，實現操作效率的提升。在貴州遷移過程中，能夠實現多部門資訊同步、資訊檢查，並顯著降低批次操作的出錯機率、執行效率，降低人因風險。同時也可為後續其他大型專案提供基礎支撐。

2. 自動升級平臺

自動升級平臺串聯程式碼升級變更、測試部署、測試驗證、線上釋出、線上檢測，實現升級生命週期重要節點的自動化。在貴州遷移過程中，顯著提升整體升級、驗證、部署效率。同時可為後續的大規模元件升級、元件風險治理、元件相容性摸查、Sidecar式升級提供基礎支撐。

九、不足反思

1. 元資訊建設仍然不足

精準篩選出每項事宜涉及的範圍，是順利進行各項風險治理的前提條件。在此次貴州機房遷移中也暴露出元資訊建設不足的問題。

不足項	解釋
應用的元資訊需要補充、更新	1. 應用歸屬的團隊資訊不準確 2. 應用的廢棄、待廢棄狀態未知 3. 測試應用、非業務應用資訊偏雜亂
應用團隊歸屬資訊多處維護，未統一	應用在多個平臺均有維護，且均存在維護不準確的問題
應用的各項依賴資訊不全	應用依賴的db、redis、memcached資源，以及在配置中心的key無法全面準確拉取
應用的各項依賴資訊視覺化、系統化建設不足	1. 應用依賴的元件版本、依賴的儲存資源等，缺乏友好的視覺化查詢能力。 2. 各項資訊之間的關聯性建設不足
底層中介軟體、儲存元資訊不全	1. 不同的ZK叢集的用處缺乏統一維護。 2. 各項元資訊反查呼叫源IP、叢集、應用、團隊、負責人的能力不足

2. 各項元資訊的建立、更新、銷燬標準化、系統化

在貴州遷移過程中，做了歷史技術債務處理、標準化接入方式，後續可針對各項元資訊的建立、更新、銷燬進行標準化、系統化建設。例如：

• 應用、叢集的建立和銷燬需要前置校驗、審批。以及後期的架構治理掃描。
• 藉助元件升級平臺，實現元件釋出、升級的標準化、系統化。
• DB、Redis、Memcached、ZK的申請、使用、接入等標準化、防劣化。

3. 應用配置標準化

目前應用可做配置的入口有：配置中心、properties檔案、props檔案、JVM引數、硬編碼。不同的中介軟體提供出的配置方式也各有不同，所以各應用的配置比較五花八門。因此可做如下改進：

• 明確各種配置入口的使用標準。比如：什麼時候建議用配置中心？什麼時候建議用JVM引數？
• 在元件提供側、應用研發側均有一定的宣貫、提示。避免配置方式過於雜亂。
• 提供配置統一上報的能力。助力元資訊的建設。

4. 批處理能力需再進一步增強

在貴州機房遷移中，除了SOP平臺和自動升級平臺的系統沉澱外，業務中介軟體、Horizon部署平臺都提供了一定的工具支撐，從而在一定程度上提升了整體遷移的效率。在之後，隨著對效率、系統間融合的要求的提高。需要繼續在功能、效能、穩定性等多個層面，繼續對批處理、系統間融合進行系統化建設。例如：

• 批次拉取、篩選指定條件的應用以及相關依賴資訊。
• 基於指定的環境、團隊、應用、叢集等維度，進行服務的批次重啟、部署。此處需要進一步提升測試環境部署成功率
• 基於指定的應用、叢集等維度，進行批次的服務複製、配置複製。

5. ZK穩定性、可維護性最佳化

在貴州遷移中，ZK的問題相對突出，對此也投入了比較多的人力去排查、解決以及推進風險治理。後續仍需要在ZK的穩定性、可維護性上探討進一步最佳化的可能性：

• ZK元資訊的維護和使用標準。明確各ZK叢集的用處、各ZK Path的用處，ZK叢集間隔離、複用的標準，並推進相關標準化治理。
• ZK故障時，因開啟降級至記憶體，業務無法重啟服務。若故障期間疊加其他事故，則會導致其他事故被放大。
• 其他穩定性、可維護性梳理

6. 公技側穩定性保障長效機制和系統化建設

儘管在貴州機房遷移中，做了大量的穩定性保障措施，但依賴每個研發對各自負責領域的理解、運維能力。是否能在團隊管理、設施管理、服務管理、穩定性管理、架構設計等多方面，探索出一套可持續的長效保障機制？並進行一定的穩定性系統化建設？從而避免點狀問題隨機發生。

7. 元件生產、釋出、治理能力增強

貴州遷移中涉及大量的元件變更與釋出，以及業務側元件升級與治理。元件可以從生產側和使用側進行分析，而元件生命週期主要由2條主線貫穿：

• 元件生產釋出線：元件的生產、測試驗證、釋出。
• 元件風險治理線：風險定義、風險發現、升級推進、升級驗證

  

  依據此分類，服務端的元件管理仍有較多可提升空間。

最後