本文作者：邵東風

貴州機房遷移是雲音樂歷史上規模最大、人員最多、難度最高的技術項目，此文對總體方案進行回顧。

一、背景

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 切流點選擇

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

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

2.2 存儲層遷移策略

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

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

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對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 執行步驟

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

2. 線上環境演練

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

2.1 演練原則

• 不對線上數據產生污染；
• 不產生線上 P2 以上事故。

2.2 演練目標

2.3 演練終止條件

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

3. 獨立App遷移驗證

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

八、系統沉澱

1. SOP平台

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

SOP平台將標準化、流程化的操作進行系統化呈現，並對接各中間件平台，實現操作效率的提升。在貴州遷移過程中，能夠實現多部門信息同步、信息檢查，並顯著降低批量操作的出錯概率、執行效率，降低人因風險。同時也可為後續其他大型項目提供基礎支撐。

2. 自動升級平台

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

九、不足反思

1. 元信息建設仍然不足

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

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條主線貫穿：

• 組件生產發佈線：組件的生產、測試驗證、發佈。

• 組件風險治理線：風險定義、風險發現、升級推進、升級驗證
  
  依據此分類，服務端的組件管理仍有較多可提升空間。

  最後

  
  更多崗位，可進入網易招聘官網查看