一、問題挑戰(zhàn)

基線治理前，我們的基線運(yùn)維存在較多的問題，有兩個(gè)數(shù)字很能說明問題：

（1）月平均起夜天數(shù)達(dá)80%以上。為什么會這么多呢，有很多因素，例如運(yùn)維范圍不清晰、基線掛載沒有約束、集群資源緊張等等。 

（2）基線產(chǎn)出時(shí)間較遲，經(jīng)常無法在上班前產(chǎn)出，月平均破線時(shí)長將近十小時(shí)。

要進(jìn)行全鏈路基線治理，面臨的挑戰(zhàn)也很大，主要來自3方面：

• 任務(wù)多：千億級日志量，萬級任務(wù)數(shù)，如何收斂在可控的范圍，如何在出錯后，能較快的重跑完？
  
• 資源緊：凌晨資源水位95%以上，沒有任何的 buffer 預(yù)留，也沒有彈性資源可用；
  
• 要求高：顯微鏡下工作，以 MUSE 產(chǎn)品為例，上百 BD，每天上班就看數(shù)據(jù)，他們的 KPI 考核就以 MUSE 的數(shù)據(jù)為準(zhǔn)。
  

二、目標(biāo)衡量

全鏈路基線治理的價(jià)值，總結(jié)起來主要有4個(gè)方面：

• 服務(wù)于管理層，讓管理層第一時(shí)間能查看公司的經(jīng)營數(shù)據(jù)。
  
• 面向 C 端的業(yè)務(wù)數(shù)據(jù)，能夠穩(wěn)定、及時(shí)的讓用戶更友好的使用。
  
• 能夠建立數(shù)據(jù)開發(fā)團(tuán)隊(duì)的研發(fā)口碑和影響力。
  
• 提升我們數(shù)據(jù)開發(fā)同學(xué)的運(yùn)維幸福度，進(jìn)而提升組織的穩(wěn)定性。
  

那么我們用什么指標(biāo)來衡量我們的目標(biāo)呢？我們提出了兩個(gè)數(shù)字來牽引：

• 98%：全年可用天數(shù)達(dá)到98%以上，即服務(wù)不達(dá)標(biāo)天數(shù)全年不超過7天。
  
• 基線時(shí)間：核心 SLA 基線產(chǎn)出時(shí)間需滿足業(yè)務(wù)要求。
  

三、行動方案

3.1 整體方案

基于上述問題挑戰(zhàn)的剖析，我們對該問題的解題思路拆成3個(gè)方面：

• 平臺基建：俗話說：“根基不牢，地動山搖”，首先要解決的就是平臺基建，例如如何衡量我們的集群資源是否飽和、我們的隊(duì)列如何管控、產(chǎn)品功能如何支持等等。
  
• 任務(wù)運(yùn)維：全鏈路上，哪些任務(wù)是卡點(diǎn)？超長高耗資源任務(wù)是什么原因？哪些任務(wù)需要高保障？
  
• 組織流程：有沒有標(biāo)準(zhǔn)的運(yùn)維 SOP ？跨團(tuán)隊(duì)的協(xié)作機(jī)制如何建立？出問題后，如何有效的跟蹤以及避免再次發(fā)生？
  

用3個(gè)詞歸納，就是穩(wěn)基建、優(yōu)任務(wù)、定標(biāo)準(zhǔn)。

3.2 穩(wěn)基建

基建這塊，我們梳理了存在的問題：（1）隊(duì)列使用不明確：總共拆分了幾十個(gè)隊(duì)列，沒有明確的使用規(guī)范；（2）資源監(jiān)控靠經(jīng)驗(yàn)，無通用指標(biāo)衡量；（3）集群 Namenode 壓力大，負(fù)載高；（4）資源管控弱，遇到突發(fā)情況無法保障高優(yōu)任務(wù)優(yōu)先獲取資源。

針對上述問題，我們實(shí)施了如下的解決方案：

• 集群穩(wěn)定性建設(shè)：聯(lián)合杭研，對負(fù)載高的 Namenode 集群進(jìn)行 DB 拆分，遷移上百張表；同時(shí)完善集群的監(jiān)控，例如 nvme 盤夯住自動監(jiān)控修復(fù)，dn/nn/hive 等節(jié)點(diǎn)監(jiān)控優(yōu)化快速發(fā)現(xiàn)問題。
  
• 集群資源數(shù)字化：實(shí)現(xiàn)了一個(gè)高可靠的資源使用模型，為集群資源管理員提供具體的數(shù)字化指標(biāo)，以此可以快速判斷當(dāng)前集群的資源使用情況，解決當(dāng)前集群資源分配不合理的情況。
  
• 產(chǎn)品化：通過產(chǎn)品層面提升資源的使用效率，比如產(chǎn)品功能支持按任務(wù)優(yōu)先級獲取隊(duì)列資源，產(chǎn)品層面實(shí)現(xiàn)自助分析&補(bǔ)數(shù)功能凌晨禁用或有限度使用。
  
• 隊(duì)列資源使用指導(dǎo)建議：制定隊(duì)列的資源使用規(guī)范，明確各個(gè)隊(duì)列的作用，管控隊(duì)列使用，規(guī)劃高中低級隊(duì)列。
  

3.3 優(yōu)任務(wù)

針對云音樂體量大、業(yè)務(wù)多、團(tuán)隊(duì)廣的數(shù)據(jù)任務(wù)特點(diǎn)，我們在這塊做的工作主要有：

• 核心 ETL 引入流式處理，按小時(shí)預(yù)聚合數(shù)據(jù)，這樣1小時(shí)內(nèi)完成流量日任務(wù)批跑。
  
• 任務(wù)優(yōu)化：如 hive、spark2 版本升級至 spark3 ，隊(duì)列調(diào)整、sql 改造等等。
  
• 打通表、任務(wù)、基線間的血緣關(guān)系，優(yōu)化任務(wù)的調(diào)度時(shí)間，減少任務(wù)依賴錯漏配。
  
• 指標(biāo)的異常監(jiān)控，我們除了傳統(tǒng)的 dqc 外，還引入機(jī)器學(xué)習(xí)模型，解決云音樂 DAU 這類指標(biāo)具有周期性、假日因素的監(jiān)控難點(diǎn)。
  

其中，spark 升級得到了杭研同學(xué)的貼身服務(wù)，取得了比較好的成果，hive 升級到 spark3 完成大幾百個(gè)任務(wù)的改造，節(jié)省60%資源。spark2 升級 spark3，完成將近千個(gè)任務(wù)的改造，整體性能提升52%，文件數(shù)量減少69%。

指標(biāo)的異常監(jiān)控，引入的機(jī)器學(xué)習(xí)模型，我們主要融合了 Holtwinter、XGBoost 算法，相比 dqc 的監(jiān)控，我們在 DAU 這個(gè)指標(biāo)上，召回率提升74%，準(zhǔn)確率提升40%，正確率提升20%；同時(shí)這里還有一個(gè)很大的作用是，它能感知業(yè)務(wù)的動態(tài)趨勢性變化，而且部署也很簡單，配置化接入。在產(chǎn)品層面，我們也正在聯(lián)合杭研產(chǎn)研同學(xué)，將該能力集成到數(shù)據(jù)質(zhì)量中心。

3.4 定標(biāo)準(zhǔn)

在定標(biāo)準(zhǔn)方面，主要從兩方面出發(fā)：運(yùn)維的范圍和運(yùn)維規(guī)范。基于這兩點(diǎn)，我們展開了如下的工作：

• 以核心產(chǎn)品+核心報(bào)表為載體，劃定核心 SLA 運(yùn)維基線+數(shù)倉中間基線，值班運(yùn)維的范圍從原先的上萬個(gè)任務(wù)縮減到千級任務(wù)數(shù)。
  
• 明確任務(wù)責(zé)任人，解決之前事不關(guān)己高高掛起的問題，按照業(yè)務(wù)線劃分，工具+人肉并行的方式將無歸屬的任務(wù)歸屬到責(zé)任人。
  
• 制定基線掛載原則，明確約束條件、各角色職責(zé)等。
  
• 制定標(biāo)準(zhǔn)的運(yùn)維 SOP ，嚴(yán)格運(yùn)維軍規(guī)和獎懲機(jī)制；同時(shí)跟杭研建立數(shù)據(jù)運(yùn)維交警隊(duì)，多舉措保證異常情況的及時(shí)處理。
  
• 建立官方運(yùn)維消防群，第一時(shí)間通知問題和處理進(jìn)展，解決信息傳遞不夠高效，業(yè)務(wù)體感差的問題。
  
• 與杭研、安全中臺、前端等達(dá)成統(tǒng)一意見，引入 QA 作為公正的第三方，統(tǒng)一牽頭處理問題的復(fù)盤和歸因，確保問題的收斂。
  

四、成果展示

項(xiàng)目成果這塊，主要分為業(yè)務(wù)成果、技術(shù)成果、產(chǎn)品成果三方面。

業(yè)務(wù)成果，目前我們的核心基線凌晨就能跑完，平均告警天數(shù)下降60%，核心基線破線次數(shù)0，完成全年可用天數(shù)98%以上的目標(biāo)。

技術(shù)成果，我們的《機(jī)器學(xué)習(xí)模型在云音樂指標(biāo)異動預(yù)測的應(yīng)用實(shí)踐》榮獲了網(wǎng)易集團(tuán)2022年度技術(shù)大會-開源引入獎。同時(shí)，我們的集群資源數(shù)字化，通過計(jì)算出合理的彈性資源，確保集群服務(wù)或者任務(wù)出現(xiàn)相關(guān)波動或異常的情況下，不會造成大量任務(wù)延遲、核心基線破線等現(xiàn)象；其次根據(jù)資源的安全水位，為擴(kuò)縮容提供量化的數(shù)據(jù)指標(biāo)；最后集群、隊(duì)列、任務(wù)資源透明化后，可以提高整體的資源利用率，降低成本。

產(chǎn)品層面，在杭研的鼎力支持下，實(shí)現(xiàn)了隊(duì)列資源的傾斜、自助取數(shù)自動查殺等功能，有效的提升了我們的資源利用率。

五、后續(xù)規(guī)劃

我們將從產(chǎn)品、系統(tǒng)、業(yè)務(wù)、機(jī)制四個(gè)方面繼續(xù)全鏈路基線治理的工作。

產(chǎn)品層面，我們將引入 DataOps，增強(qiáng)任務(wù)的代碼自動稽核能力，從開發(fā)、上線、審批全流程做管控。優(yōu)化基線預(yù)警，通過檢測基線上任務(wù)調(diào)度時(shí)間、依賴設(shè)置等，判斷是否有優(yōu)化空間或者異常，并做提示或告警。

系統(tǒng)層面，優(yōu)化資源監(jiān)控，支持基于 Label 級別展示分配的物理 CPU、虛擬  CPU、內(nèi)存等系統(tǒng)資源總量以及指定時(shí)段的實(shí)際 CPU、虛擬 CPU、內(nèi)存使用量。同時(shí)在任務(wù)級的資源使用上，對配置的資源做合理性評估，進(jìn)而提供優(yōu)化建議。

業(yè)務(wù)層面，提升內(nèi)容級監(jiān)控覆蓋率、準(zhǔn)確度；打通線上服務(wù)的血緣，覆蓋線上服務(wù)的任務(wù)。

機(jī)制完善，聯(lián)合分析師、數(shù)據(jù)產(chǎn)品等團(tuán)隊(duì)，確定報(bào)表、數(shù)據(jù)產(chǎn)品的下線以及對應(yīng)歷史任務(wù)下線流程。

寫在最后，治理是一件久久為功的事情，上述更多的是從方法論的角度在講這件事，但是治理其實(shí)更考驗(yàn)執(zhí)行，需要不斷修煉內(nèi)功，把事情做細(xì)，把細(xì)事做透。