裴澤良 | 騰訊架構平臺部運營開發組負責人
本文為騰訊裴澤良老師在 GOPS 2018 · 上海站自動化運維專場演講全文，社區將速記文字整理發佈，以饗讀者。
架構平臺部提供的服務大家都使用過，微信QQ聊天的圖片、朋友圈圖片；QQ音樂裡面的歌曲，騰訊遊戲，應用寶裡面的app的下載、騰訊雲的COS對象存儲、點播、直播，以及騰訊視頻的點播、直播等產品。
目前總存儲量超過2EB，儲備帶寬超過100Tb，使用的服務器超過20W臺，建設了1000多個OC機房。我們提供的服務總流量佔據了騰訊90%以上的出口流量，負責託管的服務本身的運維人員只有50人。
如果用發電站來類比海量服務的基礎運維，發電站的日常運維需要具備強有力的監控能力，能夠實時監測到各種指標有沒有異常。
比如當前總輸出電壓值、電流值、發電量，日常中還需要對生產環境做各種操作、調整，比如裝填各種原料、調整發電量、維修零部件。
我們日常運維同樣需要版本配置變更，維修故障機。
安全運維是根基，否則一旦出事，後果不堪設想。
對於發電站來說，下游的工業、居民全停電了，會帶來巨大的經濟損失；對我們來說，用戶數據丟失找不回來，會產生巨大的信任危機。
直觀來看，我們的運維挑戰就是監控體量大、告警多，對現網變更非常頻繁，安全要求高。
在介紹運維體系前，需要先了解下我們的業務平臺架構，這樣才能理解我們的工作重心，比如生產環境中我們沒用常見的web服務器，沒有使用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 · 深圳站！
閱讀更多 高效運維 的文章
