騰訊海量存儲與CDN的自動化運維

• 2019 年 10 月 11 日
• 筆記

9月14-15日，GOPS全球運維大會上海站圓滿舉行，為期兩天的運維盛宴，為各位運維人帶來了相互交流和學習的絕佳平台，來自騰訊技術工程事業群（TEG）架構平台部的裴澤良給大家帶來了「騰訊海量存儲與CDN的自動化運維」的主題分享。

我們同步了嘉賓現場沙龍分享視頻（內含高清PPT），請點擊下方「騰訊技術課小程序」卡片即可查看：

同時附上整理好的演講稿：

裴澤良，來自騰訊技術工程事業群的架構平台部，從事運營系統相關的建設工作超過8年，參與建設了騰訊雲CDB、騰訊海量文件存儲系統TFS以及騰訊CDN服務的運營體系從初級到較為完善的各個階段，目前專註於提升騰訊雲上直播、點播、靜態文件CDN、COS等業務的運營質量，以及建設更為高效與安全的自動化運維體系。

騰訊架構平台部是做什麼的

騰訊架構平台部提供了微信QQ聊天的圖片，朋友圈圖片，QQ音樂裏面的歌曲，騰訊遊戲，應用寶裏面的app的下載，騰訊雲的COS對象存儲，點播，直播，以及騰訊視頻的點播，直播，這些產品背後的海量存儲與CDN服務都是由我們部門提供的。

目前總存儲量超過2EB，儲備帶寬超過100Tb，使用的服務器超過了20W台，建設了1000多個OC機房，我們提供的服務總流量佔據了騰訊90%以上的出口流量，而我們的運維人員就只有50人，這裡要解釋下，我們的背後還有其他兄弟團隊在支撐，比如機器的採購維修、機房的建設，而對於我們託管的服務本身的運維人員就只有50人。

可以透過發電站來形象的了解我們海量服務的基礎運維，發電站的日常運維需要具備強有力的監控能力，能夠實時監測到各種指標有沒有異常，比如當前總輸出電壓值、電流值、發電量，而且日常中還需要對生產環境做各種操作、調整，比如裝填各種原料、調整發電量、維修零部件，我們日常運維同樣有版本配置變更，有維修故障機，當然了安全運維是根基，否則一旦出事，後果不堪想像，對於發電站來說，下游的工業、居民全停電了，會帶來巨大的經濟損失，對於我們來說，用戶數據丟失找不回來了，會有巨大的信任危機。形象的來看，我們的運維挑戰就是監控體量大告警多，對現網變更非常頻繁，安全要求高。

這個是我們的自動化運維體系，可以分為三大部分來看，基礎系統，像配置系統、設備資源管理系統、資源預算核算計費系統，通用運維能力的系統，像監控、變更、PAAS運維平台、質量測試、流程，業務專用的運維繫統，像相冊運維繫統、COS運維繫統、VOIP運維繫統。我今天分享的就是中間這塊通用運維能力方面的。對於我們來說，所有這些系統的建設就是為了保障業務質量、控制業務成本的。

海量業務的監控

大家有沒有經常遇到過業務或用戶投訴過來「我朋友圈看不到圖了，什麼情況」，然後我們的人員一臉迷惑「好像一切正常，我沒收到告警呢」，也就是監控不全的問題，然後我們在監控系統上面各種查找數據，想看下到底出什麼問題了，結果點了「查詢」按鈕，系統一直提示「請等候，正在萬分努力查詢中」結果就是半天出不來數據，也就是系統性能低的問題，好不容易看到視圖了，隨即來了個疑問，總共有上千台機器在上報失敗數據，到底是哪台機器上報了大量的失敗數據呢？又是一臉迷惑「找不到呢」，也就是系統不具備多維下鑽分析的能力，找不到來源。下面看看我們是怎麼解決的。

這個是監控總覽，我主要會介紹一些與一般常見監控系統不一樣的地方，主要體現在監控上報、即時計算、異常自動發現、自動分析這幾方面。

這個是我們的上報模塊，上報端通過內網或外網發數據到服務器，我們監控的數據主要分三類：結構化的，也就是時序數據，詳細日誌的，也就是程序流水數據，自定義數據，業務藉助監控上報通道上報的自己需要的特定的數據，監控系統最關心的當然是結構化的時序數據了，像流量、請求數、延時都是這類數據。

我們在上報中比較特別的一點就是在上報端，業務邏輯每一次的用戶請求處理相關的數據都會調用監控上報API，比如業務邏輯中每請求一次後端系統，就會把調用延時、主調接口、被調接口、成功還是失敗、錯誤碼等數據調用監控上報API上報到監控系統中，在上報API中我們會按秒把同一類型的多條數據匯聚成一條，然後上報給本機的監控Agent守護進程，在Agent中會把秒級數據直接發給監控平台，就形成了秒級監控，同時Agent也會把同類型的多個秒級數據點匯聚成一個分鐘級的數據，然後上報給監控平台，從而形成分鐘級告警，目前每分鐘有6億的分鐘級結構化數據上報。

總結一下，我們在同一個上報通道中實現了秒級、分鐘級、詳細日誌、業務自定義數據等多種上報能力。

我們監控系統用結構化的多維度多指標模型來描述業務的監控，指標維度這種概念在OLAP中很常見，具體的做法就是一個軟件模塊的監控數據分解為多個指標與多個維度，譬如朋友圈圖片下載的download模塊，指標有流量、延時、請求數、失敗數等等，維度有地區、運營商、圖片規格等等，用戶的每一次下載請求的監控，都對應了某種維度指標組合的數據，譬如圖中紅色的線條是指上海電信大圖的流量，監控系統會自動把這種軟件上報的維度指標組合映射為一個唯一的特性ID，特性ID是數字型的，然後把該維度指標組合的時間序列值與該特性ID做為(key, value)存在單獨的KV系統中，把特性ID與該維度指標組合的關係做為配置數據存在DB中。一個(key, value)中的value只保存2小時共120個點的時間序列值，同一個key每天會存在12個value，採用專用壓縮算法後，每天的存儲量超過350GB。

總結下，多維度模型可以有效的描述業務的各種監控數據。

多維度模型好是好，但也會帶來一些很明顯的問題，就是軟件只會上報最基本的各種維度指標組合的數據，而用戶卻需要查詢各種維度匯聚的數據，譬如前面說的軟件上報了上海電信大圖的流量，而用戶卻需要查看電信整體的流量。

怎麼辦呢？

如果數據是存在MySQL中，我們直接select sum group by就可以了，但這樣的海量數據顯然不適合存關係數據庫，我們是存在KV系統中，然後我們採用了實時計算+即時計算的模式來解決匯聚的問題，實時計算用於軟件直接上報的最基礎的各種維度組合的數據在多台機器之間的匯聚計算，即時計算用於用戶查詢的數據不是基礎組合時的立即計算。

當然大家已經看出來了還是會有問題，比如用戶查詢的維度組合有幾十萬時，立即匯聚是無法保證能在1秒內返回的，怎麼辦呢？這時候就要用到我們即時計算的索引技術了，類似於MySQL中可以建索引，用於加快select的速度，這裏面的思想類似，做法就是對明顯增長查詢耗時的維度生成為「索引」，這個索引會在這個維度上做匯總並且與其他維度做組合，這個索引又會自動加入到實時計算中，以保證數據每分鐘都會被計算，大家又會有疑問了，索引這麼好，是不是也要像MySQL索引一樣需要用戶自己維護呢？我們已經做到了自動化，當系統發現某個業務的維度組合過多可能會影響查詢速度時，會自動找到最優的維度來添加索引。

整個思路與apache kylin有些類似，也就是預計算，但又不同，kylin只會預計算用戶提前預定義的所有組合，不管實際中會不會被用到，而我們是一次預計算+二次按需的自動索引預計算+按需的立即匯聚，採用這種做法後，即使用戶看到的維度組合達到幾十萬，甚至上百萬，系統同樣會對用戶的查詢亞秒級返回結果，同時又保證了預計算的結果數據量不會太大，降低系統成本。

但業務體量大了之後，還是會存在各種各樣的挑戰，譬如某個維度包含的維度子項太多，有幾十萬，甚至上百萬，像CDN的域名，騰訊雲直播的房間，這時候即使是即時計算也不是那麼有效了，怎麼辦呢？

仔細分析業務特性會發現大部分都是長尾用戶，這部分用戶對整體流量貢獻很少，有些域名每天就幾十、幾百次請求，沒必要籠統的都做分鐘級監控告警，這樣比較浪費監控資源，所以我們提出了重點業務與長尾業務區分監控的概念，在數據上報後的實時分析模塊，把長尾業務數據稍做處理寫入HBase，再有一個長尾數據分析模塊會起一個spark任務，保證每5分鐘分析一輪長尾數據，把滿足一定條件，譬如流量達到某一閾值的業務轉為重點業務，這樣做了之後就達到了把有限的資源用來優先保障重點業務，而長尾業務做到5分鐘級別發現異常，並且能在5分鐘內把達到一定流量的業務自動轉為重點業務，從而增強監控能力。

前面我在上報部分內容中提到了秒級監控，對於我們來說秒級監控最重要的不是用來秒級告警，這樣會帶來非常多的毛刺騷擾，而是在有異常時能夠幫助分析軟件分鐘內負載不均衡的情況，譬如分鐘級數據掩蓋真實的高負載問題，以及像直播、紅包這種會秒級突發場景的分析。

AI ops非常流行，我們在這方面也有探索，目前在異常的自動發現、告警毛刺的去除上面，都有在實際使用，效果還不錯，在異常的自動溯源方面，還在努力探索中。我想強調的是，對於我們業務來說，即使上了機器學習版的異常自動發現、告警毛刺的自動分類，但傳統的人工干預的閾值波動率告警仍然不可少，比如某些業務近期很受關注，對質量的抖動要求很敏感，這個時候就要人工干預配置傳統的閾值、波動率了，所以在我們看來，AI ops並不是由自動來接管一切，而是傳統的閾值這種策略仍然要使用，以防止自動的失效。

在異常的自動發現方面，我們採用了兩階段方式，先用統計分析算法做一次篩選。統計分析算法目前用了四種，Grubbs，EWMA，最小二乘法，First Hour Average，輸入的曲線數據是今天、昨天、上周同天總共三天的數據，用這四種算法來投票決定當前點是否為異常點，至少要有三個算法認為是異常點才會認為是異常點，然後再用IF算法對這個異常點做一次離散點判斷，這樣就得出最終的異常點，這裏面用的都是無監督算法，對流量、延時、失敗率這種相對還算平滑的數據都比較有效，當然了對於有些場景會基本無效，像右邊這個圖是直播的流量，大主播一上線流量就會大幅上漲，一下線流量就會大幅下跌，而且大主播的上下線時間對整個業務來說都是不確定的，人工來看都很難斷定哪些是異常，哪些又是正常的，算法也必然是直接一臉迷茫，我想強調的是，算法還是要結合業務特性，不能只看數據本身，這樣才能最終提升準確度，對於直播流量這種情況，我們直接就用傳統的閾值就好，把智能化的判定加在卡頓率這種指標上，同樣能夠達到應有的發現故障的效果。

業務的質量數據偶爾會有一個突起，譬如延時或失敗率在短暫的幾秒時間內有個比較明顯的上升，但隨之又立即降下來了，這類問題對一般業務來說都沒什麼影響，但如果都告警出來，那運維是受不了的，怎麼辦呢？

我們採用了有監督學習算法來智能化的去毛刺，既然是有監督，那就是需要人的參與了，我們建設了一套告警送達負責人微信時，負責人可以直接在微信上面認領告警，選擇異常的原因，裏面有一項就是「毛刺抖動」，這樣我們就獲取到了有標籤的樣本了，然後根據告警的業務特性來建立樣本特徵，譬如把時間、地區、運營商等都做為特徵，再用RF、GBDT、SVM分別建立毛刺模型，對於之後的告警都會採用這三個模型來投票，至少要有2個認定為毛刺，我們才會最終判定為毛刺，然後降級發給負責人，這個模型的訓練是在線的，用戶不斷的認領，模型不斷的精準，後面的告警去毛刺會不斷的有效。最終我們通過智能化的異常發現與去毛刺，來綜合提升告警的全面性與準確性。

告警的自動分析處理也是我們比較有特點的一個方面，我們建設了完整的自動分析體系，在異常產生後，如果有相應的自動分析工具，告警就不會直接發給用戶，而是會先送到分析工具，分析工具分析出結果後會再推送給用戶，同時如果有處理工具，用戶還可以在收到分析結果時，直接點擊處理。要說明的是分析、處理工具是放在我們的PAAS運維平台中的，只需要用戶手工拖拽、編寫一些小腳本就可以完成工具的開發，這才是我們自動分析體系的便利之處。要強調的是，這裏面的自動分析並不是指異常出現後，系統就具備通用的能力可無條件的自動分析出原因，即使是人，如果對業務不熟悉，也做不到通用的分析效果。對於常見的問題，建設專用的分析處理工具，可以極大的提升運維效率。

在告警的自動分析與處理方面，我們最終期望的效果就類似於自動淋水系統，當探測到火災後，就自動開啟噴頭來滅火。

在沒有更智能、更精準的容量評估前，常常可以看到運維人員與預算管理人員的爭論，「我需要200台設備」，「你為什麼需要這麼多，理由是什麼，能不能再減少些」。

容量管理方面，大家常常可以見到docker化，k8s等等，那為什麼我們還需要單獨的容量管理呢？對於我們來說，我們把模塊分為二大類，一類是無狀態的模型，這類是可以docker化管理的，另一類是有狀態的模塊，不適合docker化。在docker化的容量管理方面，我們具備了秒級CPU、流量監控的能力，來計算容量需求，同時採用了提前把容器部署到母機的方式來達到秒級擴容的效果，目前我們建設了超過100W核的docker資源池，用於圖片壓縮、視頻轉碼、AI訓練這類場景。在有狀態模塊的容量管理方面，我們引入了機器學習的算法來自動評估容量，並且做到了與預算、資源系統的聯動，直接一鍵提交設備增長需求。

我們的容量評估原理是這樣的，從監控系統中可以獲取到軟件模塊的請求數、流量、CPU值的對應數據，採用回歸算法建立起模型，在實際中常常會把業務的關鍵特徵加進來建立模型，譬如圖片規格（像大圖、小圖）、請求類型（像圖片、視頻、文件），因為很顯然，不同圖片規格、請求類型下的請求數會有帶來明顯不同的流量。當業務自然增長需要報備或活動提前需要報備資源時，就可以很容易的計算出上漲多少請求，會帶來多少的流量、CPU的上漲，進而需要多少的設備量。採用了機器學習算法後，容量的評估不再是人工的「大概」式預估，而是精準化評估。

從此運維報備設備時，便不再與預算管理人員有爭論了，「根據現有模塊的性能如果要支撐未來的這個增長量，系統算出來就需要這麼多設備」，「看來需要拉上開發人員 PK 下他們的程序性能是不是可以再優化下了」。

安全高效的現網變更與操作

監控是用於發現問題的，監控做的很好了，發現了很多問題，但出問題時卻沒有得心應手的工具，運維只能手忙腳亂，半天也解決不了問題，效率非常低下，這不是我們想要的。接下來看看我們變更與操作方面的工具化建設。

對現網的變更操作就需要運營系統能夠更改生產機，如果整個生產系統只有幾十台機器，還可以直接expect ssh的方式，幾千台的時候這種辦法就不行了，可以使用ansible、saltstack，而幾十萬台生產機、複雜網絡環境下、要求一定安全策略的時候，ansible、saltstack也不可行，所以我們建設了自己的管控平台，管控平台本身只有兩個核心功能：執行命令、傳輸文件，然後在此基礎上會建設了作業流程管理、模板機制、操作範圍隔離機制等安全策略，當然了我們的管控平台還需要具備屏蔽各種網絡、地域環境差異的能力，給上層用戶提供一個統一的使用體驗。

在文件傳統方面，我們使用了類似P2P的方式，當源與目標機器可以直連的時候就直傳，當無法直連的時候，系統會自動計算最優路徑，從接入svr上面做中轉，這些對於上層調用方都是不可見的，系統會自動完成。比如我們變更時的版本文件位於IDC內的服務器，目標機器位於CDN邊緣結點，且無外網，這時候就會用到自動中轉的文件傳輸了。

目前我們管控平台的終端數量超過30W，每天調度的作業數量超過5KW。對於海量的運營來說，管控平台是運營系統操作生產機的唯一途徑，絕不允許有人再通過expect直接ssh這種方式來操作生產機，所以管控平台是自動化運營中非常基礎與重要的一環。

變更常常是導致現網出現故障的一大原因，所以變更是一個值得發精力做好的環節，變更的基礎依賴就是管控平台，這個是我們的變更流程，從開發提交版本，然後進入自動化構建與測試，接下來進入灰度變更，效果確認後再到批量變更，在整個流程中我們做到了自動化，目前每天有50單非通用配置的變更任務，變更機器數量超過1W台，比較有特色的就是在變更階段的自動化監控，也就是在每台機器變更之後，系統採用機器學習的算法自動發現變更前後機器負載、業務請求量、失敗量等這些指標是否出現異常，如果一切正常，就會繼續變更下去，一旦發現異常就會暫停變更，通知負責人處理。

還有一個比較有特色的就是變更後的檢查，不同業務的變更或擴容會有一些區別，譬如A業務是在外網，並且用了TGW，TGW是騰訊的網關產品，類似於LVS，那麼在擴容的時候就要申請防火牆、安裝隧道，一旦有某個部署沒做正確，就會導致最終出問題，我們在變更後會對接一個工具化的檢查，用來再次確認變更效果，而這個工具化的檢查不是在變更系統中做的，因為不同業務可能是不同的、多樣的、經常變化的，所以不適合放在變更系統中，我們是把它放在我們自己的PASS運維平台中，這個PAAS運維平台可以很方便的創建一些小工具，並且與變更系統對接，從而做到統一變更系統中千人千面的效果。

以前我們每位運維人員手頭都有一些自己寫的工具腳本，當需要使用的時候，到處找來找去，就像這堆散亂的工具一樣，而且因為自己寫自己的，還會導致這些個人專用的工具難以給到其他人使用，難以傳承下去，以及安全性不可控，怎麼辦呢？

我們建設一個輕量型的PAAS運維平台，運維可以在這個平台里方便的編寫各種工具，快速搭建出複雜一些的流程，目標就是通過工具+流程來快速拼湊出需要的功能，平台本身有工具調度引擎、流程執行引擎，採用管控平台做為基礎，上層提供給其他運營系統，或者運維人員直接來使用。右側的就是一個新增crontab項的工具示例，目前平台總共有超過1000多個工具與流程，周人工使用量超過5000次。

有了這個PAAS運維平台後，我們再也不需要各自在自己機器上維護一些小腳本了，從而讓工具變的更易於維護、安全可控、分享與傳承。

現網安全體系

我們監控已經做的很好了，可以做在辦公桌前喝着咖啡看着視圖，手機沒收到告警電話，就一切正常，我們工具也做的豐富多彩、各種功能都有了，但是如果對生產機不加以專門保護，讓運維人員能夠經常的接觸到生產機，就會像這幅圖一樣，雖然我們無意搞破壞，但常在危險地帶走，也難免會出事，所以一定要建設更安全的操作生產機的道路。

這個是攜程2015年誤刪除程序導致的不可用，這個是滴滴2015年誤刪導致的不可用，這個是aws s3 2017年誤下線導致的不可用，甚至最近的騰訊雲2018年的誤回收導致的不可用等等，這都說明了安全運維的份量，安全無小事，誰出誰知道。

我們從總體上把生產機的安全劃分為兩大塊，其一是人工直接登錄到生產機，其二是運營系統操作生產機，從原則上來說，直接卡住這兩方面的安全運維，就可以保證整體的安全運維，總結下來就是不要讓運營系統能夠隨意操作生產機，也不要讓人能夠隨意操作生產機，這兩方面我們都做了一些具體的管控措施，因為運營系統操作生產機只能通過管控平台，所以就需要卡住管控平台的安全策略，我們具體的做法是高危操作一定要模板化，模板化是指上線這個操作工具前要人工審核，之後的執行使用都不可以再更改該工具的代碼，而且高危操作會限定執行頻率，譬如每小時限量只能操作100台設備，運營系統限定只能操作相關業務的生產機，不能隨便一個運營系統都可以操作到所有生產機。

在直接登錄生產機方面，我們對生產機的權限做了劃分，分為普通、root兩種，業務進程用root啟動，人工正常只具備普通權限，也就是說人工登錄進去後可以查看，但無法修改，如果需要root權限，就要走審批流程。當然了，即使我們做了這些之後，就能保證不出現前面說的那些誤操作了嗎？

不存在的，只要是人，只要是有不斷改變的需求，就無法保證100%不出錯，但我們仍然需要儘力從根基上來保證安全，儘力降低可能的意外發生後帶來的損失。

做了這麼多之後，我們對現網生產機的操作，有97%都是通過各種運營系統來做的，像變更系統、PAAS運維平台、業務專用運營系統，有2%會通過管控平台來操作，只有大約1%是直接登錄生產機來修改的，這部分一般是緊急故障處理時才會用到的。就像這個倒三角，越向下風險越高，效率越低。採用這種三層的體系結構，來綜合平衡運維效率與安全。

總之就是儘力避免直接操作生產機，儘力避免當場匆忙的寫工具運維，盡量使用提前做好的工具，這樣才能遠離危險。

總結&未來

對今天的分享做個總結，監控方面我們用多維度多指標模型來描述數據，採用了實時計算+即時計算的方法做匯聚，為了提高查詢速度，我們加入了自動化的索引機制，容量方面我們採用了機器學習的算法來更精準的評估，變更方面我們建設了海量設備的管控平台，在變更流程方面做了異常的自動化發現，在工具方面我們建設了PAAS運維平台，集運維小工具於一處，方便使用維護與分享，安全上我們卡住人工登錄生產機、運營系統操作生產機的風險點，並最終形成了絕大多數操作生產機都是通過前端系統，只有非常少的比如故障定位才可能會登錄生產機這種現況。

在未來，我們會在運維安全方面繼續探索，在AI ops方面持續邁入，以及持續深挖運營中海量數據的價值。