海量儲存與 CDN 的自動化運維是這麼做到的
裴澤良 | 騰訊架構平臺部運營開發組負責人
本文為騰訊裴澤良老師在 GOPS 2018 · 上海站自動化運維專場演講全文，社群將速記文字整理髮布，以饗讀者。
架構平臺部提供的服務大家都使用過，微信QQ聊天的圖片、朋友圈圖片；QQ音樂裡面的歌曲，騰訊遊戲，應用寶裡面的app的下載、騰訊雲的COS物件儲存、點播、直播，以及騰訊視訊的點播、直播等產品。
目前總儲存量超過2EB，儲備頻寬超過100Tb，使用的伺服器超過20W臺，建設了1000多個OC機房。我們提供的服務總流量佔據了騰訊90%以上的出口流量，負責託管的服務本身的運維人員只有50人。
如果用發電站來類比海量服務的基礎運維，發電站的日常運維需要具備強有力的監控能力，能夠實時監測到各種指標有沒有異常。
比如當前總輸出電壓值、電流值、發電量，日常中還需要對生產環境做各種操作、調整，比如裝填各種原料、調整發電量、維修零部件。
我們日常運維同樣需要版本配置變更，維修故障機。
安全運維是根基，否則一旦出事，後果不堪設想。
對於發電站來說，下游的工業、居民全停電了，會帶來巨大的經濟損失；對我們來說，使用者資料丟失找不回來，會產生巨大的信任危機。
直觀來看，我們的運維挑戰就是監控體量大、告警多，對現網變更非常頻繁，安全要求高。
在介紹運維體系前，需要先了解下我們的業務平臺架構，這樣才能理解我們的工作重心，比如生產環境中我們沒用常見的web伺服器，沒有使用SQL/">MySQL。
因此監控本身不需要整合這類通用服務的效能資料採集功能，跟開源的監控不一樣。
我們主要有兩大平臺： 儲存與CDN 。
簡單來說，儲存是使用者在app上面上傳下載圖片、檔案、視訊這類資料；儲存分為接入層、邏輯層、分散式儲存層。
這裡面每層都有容災、負載均衡，實際結構會比 ppt 中複雜的多。
CDN 是支援使用者下載資料或者 VOIP 轉發資料的，一般分為多級，最後一公里的邊緣OC結點，向上的中間源，再向上的源站。
源站可以是客戶自己的，譬如快手、鬥魚的源站，也可以是我們託管的，譬如cos源站。
如果是voip實時通話的，則使用者的資料就會從某個邊緣結點進來，中間經過最優路徑選擇之後，由某個邊緣結點出到對方使用者。
我們的自動化運維體系可以分為三大部分：
1.基礎系統，如配置系統、裝置資源管理系統、資源預算核算計費系統。
2.通用運維能力的系統，如監控、變更、PAAS運維平臺、質量測試、流程。
3.業務專用的運維繫統，如相簿運維繫統、COS運維繫統、VOIP運維繫統。
今天分享的是中間這塊通用運維能力，對於我們來說，所有這些系統的建設就是為了保障業務質量、控制業務成本的。
一、海量業務的監控
我們有段時間經常遇到業務或使用者投訴“我朋友圈看不到圖了，什麼情況”，我們的同事一臉迷惑“我沒收到告警呢，好像一切正常”，就是監控不全的問題。
當我們在監控系統上面各種查詢資料，想分析到底出什麼問題了，點“查詢”按鈕，系統卻一直提示“請等候，正在萬分努力查詢中”，結果就是半天出不來資料，系統性能低。
好不容易看到檢視了，隨即來了新疑問，總共上千臺機器在上報失敗資料，到底是哪臺機器上報了大量失敗資料呢？
又是一臉迷惑“找不到呢”，這就是系統不具備多維下鑽分析的能力，找不到來源。我們是怎麼解決這個問題呢？
這是監控總覽，我會側重介紹與常見監控系統不一樣的地方，主要體現在監控上報、即時計算、異常自動發現、自動分析這幾方面。
這是我們的上報模組，上報端通過內網或外網發資料到伺服器，監控資料主要分三類：
1.結構化的，也就是時序資料；
2.詳細日誌的，也就是程式流水資料；
3.自定義資料，業務藉助監控上報通道，上報的自己需要的特定的資料。
監控系統最關心的是結構化的時序資料，像流量、請求數、延時都是這類資料。
我們在上報中比較特別的一點就是在上報端，業務邏輯每一次的使用者請求處理相關的資料都會呼叫監控上報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分鐘內把達到一定流量的業務自動轉為重點業務，從而增強監控能力。
前面在上報部分內容提到了秒級監控，對於我們來說秒級監控最重要的不是用來秒級告警，這樣會帶來非常多的毛刺騷擾，而是在有異常時能夠幫助分析軟體分鐘內負載不均衡的情況，譬如分鐘級資料掩蓋真實的高負載問題，以及像直播、紅包這種會秒級突發場景的分析。
AIOps非常流行，我們在這方面也有探索，目前在異常的自動發現、告警毛刺的去除上面，都有在實際使用，效果還不錯，在異常的自動溯源方面，還在努力探索中。
我想強調的是，對於業務來說，即使上了機器學習版的異常自動發現、告警毛刺的自動分類，但傳統的人工干預的閾值波動率告警仍然不可少，比如某些業務近期很受關注，對質量的抖動要求很敏感，這個時候就要人工干預配置傳統的閾值、波動率了，所以在我們看來，AIOps並不是由自動來接管一切，傳統的閾值這種策略仍然要使用，以防止自動的失效。
在異常的自動發現方面，我們採用了兩階段方式，先用統計分析演算法做一次篩選。
統計分析演算法目前用了四種：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，那麼在擴容的時候就要申請防火牆、安裝TGW隧道，一旦有某個部署沒做正確，就會導致最終出問題。
我們在變更後會對接一個工具化的檢查，用來再次確認變更效果，而這個工具化的檢查不是在變更系統中做的，因為不同業務可能是不同的、多樣的、經常變化的，所以不適合放在變更系統中。
我們是把它放在自己的PASS運維平臺中，這個PAAS運維平臺可以很方便的建立一些小工具，並且與變更系統對接，從而做到統一變更系統中千人千面的效果。
以前每位運維人員手頭都有一些自己寫的工具指令碼，當需要使用的時候，到處找來找去，就像這堆散亂的工具一樣，而且因為自己寫自己的，還會導致這些個人專用的工具難以給到其他人使用，難以傳承下去，以及安全性不可控，怎麼辦呢？
我們建設了一個輕量型的PAAS運維平臺，運維可以在這個平臺裡方便的編寫各種工具，快速搭建出複雜一些的流程，目標就是通過工具+流程來快速拼湊出需要的功能，平臺本身有工具排程引擎、流程執行引擎，採用管控平臺做為基礎，上層提供給其他運營系統，或者運維人員直接來使用。
右側是一個新增crontab項的工具示例，目前平臺總共有超過1000多個工具與流程，周人工使用量超過5000次。
有了這個PAAS運維平臺後，我們再也不需要各自在自己機器上維護一些小指令碼了，從而讓工具變的更易於維護、安全可控、分享與傳承。
三、現網安全體系
當我們監控已經做的很好了，可以做在辦公桌前喝著咖啡看著檢視，手機沒收到告警電話，就一切正常，工具也做的豐富多彩、各種功能都有了，但是如果對生產機不加以專門保護，讓運維人員能夠經常的接觸到生產機，就會像這幅圖一樣，雖然我們無意搞破壞，但常在危險地帶走，也難免會出事，所以一定要建設更安全的操作生產機的道路。
這是攜程2015年誤刪除程式導致的不可用，這是滴滴2015年誤刪導致的不可用，這是aws s3 2017年誤下線導致的不可用，都說明了安全運維的份量，安全無小事。
我們從總體上把生產機的安全劃分為兩大塊，一是人工直接登入到生產機，二是運營系統操作生產機，從原則上來說，直接卡住這兩方面的安全運維，就可以保證整體的安全運維。
總結下來就是不要讓運營系統能夠隨意操作生產機，也不要讓人能夠隨意操作生產機，這兩方面我們都做了一些具體的管控措施，因為運營系統操作生產機只能通過管控平臺，所以就需要卡住管控平臺的安全策。
具體做法是高危操作一定要模板化，模板化是指上線這個操作工具前要人工稽核，之後的執行使用都不可以再更改該工具的程式碼，而且高危操作會限定執行頻率，譬如每小時限量只能操作100臺裝置，運營系統限定只能操作相關業務的生產機，不能隨便一個運營系統都可以操作到所有生產機。
在直接登入生產機方面，對生產機的許可權做了劃分，分為普通、root兩種，業務程序用root啟動，人工正常只具備普通許可權，也就是說人工登入進去後可以檢視，但無法修改，如果需要root許可權，就要走審批流程。
然而即使做了這些之後，就能保證不出現前面說的那些誤操作了嗎？不存在的，只要是人，只要是有不斷改變的需求，就無法保證100%不出錯，但我們仍然需要盡力從根基上來保證安全，盡力降低可能的意外發生後帶來的損失。
目前我們對現網生產機的操作，97%是通過各種運營系統來做的，像變更系統、PAAS運維平臺、業務專用運營系統，2%會通過管控平臺來操作，只有大約1%是直接登入生產機來修改的，這部分一般是緊急故障處理時才會用到的。
就像這個倒三角，越向下風險越高，效率越低。採用這種三層的體系結構，來綜合平衡運維效率與安全。總之就是盡力避免直接操作生產機，盡力避免當場匆忙寫工具運維，儘量使用提前做好的工具，這樣才能遠離危險。
說明：本文根據 GOPS 2018 · 上海站自動化運維專場騰訊 · 裴澤良演講整理而成，經騰訊 TEG 運營運維圈授權釋出。
面對大型、複雜、多樣產品線，騰訊 DevOps 實踐下的海量資源運營如何做？11月2-3日，深圳！DevOps 國際峰會，與騰訊佈道師熊普江聊聊“ DevOps 最佳實踐之海量資源精細化技術運營”！
點選 閱讀原文，速速備戰 DOIS 2018 · 深圳站！