虎牙直播運維負責人張觀石
張觀石，擁有10餘年網站開發、架構、運維經驗；目前關注網際網路服務可靠性系統工程、運維平臺的規劃建設、網站高可用架構等方面；在音視訊傳輸質量評估、微服務運維方面積累了豐富的經驗。
目錄
一、 直播平臺的架構及運維挑戰
（一） 音視訊傳輸流程及挑戰
（二） 一個直播間的流程
（三） 直播平臺的運維挑戰
二、 我們的思考和運維實踐
（一） Google SRE介紹
• SRE是什麼
• Google SRE方法論
（二） 我們的思考：運維的六種能力
（三） 我們的運維實踐
- 運維可靠性管理
- 感知能力
- 修復能力
- 反脆弱能力
- 保障能力
- 安全能力
虎牙直播介紹
虎牙直播是以遊戲為主要內容，涵蓋娛樂、綜藝、教育、戶外、體育等多種內容的直播平臺，2018年5月在紐交所上市。
虎牙算是整個直播行業比較重視技術的一家公司，大家可以對比下幾家平臺觀看體驗，我們應該是最好的一家了。英雄聯盟S8 是全球最大的電子競技賽事，目前正在如火如荼進行，從今天開始進入了總決賽的淘汰賽階段了。這會正在進行的是IG對KT隊，IG是中國的隊伍，今年共有3只中國對進入了8強，是歷年最好的成績，比賽很精彩，如果不來今天的分享，我可能在家看比賽，或是去公司值班了。歡迎大家到虎牙直播平臺觀看直播，為LPL加油！(釋出此稿時，中國隊IG已經獲得了總決賽冠軍，虎牙平臺觀眾數也突破了歷史新高，直播過程無較大故障發生)。
今天的分享正好會講到關於這次賽事的運維保障的技術。
一般網站比如電商類網站使用者是賣家+買家， 賣家先編輯商品資訊，釋出後買家重新整理後再看到，是非同步的，賣家可以慢慢改，錯了可以慢慢調。直播平臺上，一個主播開播出現在攝像頭面前，可能有成千上萬的人同時觀看，主播不能有任何小動作，不能離開，重新開播代價太大了，10分鐘不能播觀眾就跑了。要是互動不流暢，土豪也就不想看你了。主播更不可能停播配合我們運維人員做一些技術上的調整。如此看來，直播平臺相對於傳統網站還是有區別的。所以，這對運維的挑戰就更大。
直播平臺技術是比較複雜的，首先是音視訊處理本身有很多高深的技術，其實是大規模的觀眾和主播，還要對實時性要求特別高。
今年英雄聯盟總決賽S8是從韓國現場傳送回國，傳輸路徑也比較複雜。
一
直播平臺的架構及運維挑戰
（一）音視訊傳輸流程及挑戰
音訊流程是指平臺從開播到觀看一系列的流程。
①開播主播多
同時開播的主播數量非常多。
②上行選擇多
圖中，中間藍色部分的線是可以支援上行的線路，每一個主播都可以到任何一條線路上，虎牙有自動排程，運維人員也可以進行排程，主播上行哪裡。
③ 轉推路徑多
確定一條上行線路後，還要互相轉推到其他線路上，觀眾可以在任何一條線路看到主播的直播。
④觀眾線路多
觀眾有很大的選擇權，比如選擇不同的清晰度、不同的線路，包括H5技術等，播放技術和觀眾選擇不一樣。
⑤轉碼檔位多
⑥實時要求高
今年，虎牙運維研究團隊又做了P2P技術，架構又比以前複雜了很多。
（二）一個直播間的流程
上圖是一個虎牙主播直播的流程。首先，主播可以選擇一個開播方式（程式開播、桌面直播、攝像頭開播、手遊投屏、手遊桌面、OBS、導播系統、VR直播、第三方推流等）進行直播，經過4種推流方式（HUYA、UDP、 YY、 RTMP、CDN），直推到某條線路上，轉推多家CDN，從CDN邊緣到中心，然後再選擇轉位元速率，最後分發到不同省、市的運營商，之後就到觀眾的客戶端。
（三）直播平臺的運維挑戰
因為音視訊本身的複雜度，加上業務的實時性，對運維造成很大的挑戰。傳統的運維可以對開源元件做部署、配置、優化、高可用部署等。而音視訊技術變化很快，自成一個體系，主播端和觀眾端的邏輯性強，由於中間傳輸路線多，運維人員很難參與其中，所以我們必須換一種工作方式。
google的SRE 給了我們很大的啟發，我們在SRE的方法論指導下，比較深入地參與到了音視訊傳輸業務中，雖然我們不叫SRE，還是叫業務運維，不過做法吸收了SRE的很多思路。
今天要分享的也是這方面的內容，希望對大家有些啟發。
二
我們的思考和運維實踐
（一）Google SRE介紹
• SRE是什麼
S是Site/Service/Software，運維的物件，網站業務服務線上的服務
R是reliability，關注可靠性，質量，理解為對外部終端使用者的質量和價值
E是Engineer工程師、Engineering工程化。
運維的本質是人和機器參與的一項系統性工程，這種工程跟軟體工程不太一樣的是，我們是負責業務上線後穩定運營，可靠性、質量、成本等。有人比喻業務研發和運維的關係就像是：生孩子與養孩子，哪個更難哪個更容易呢？
• Google SRE方法論：
•關注研發工作，減少瑣事
•保障SLO&度量風險
•做好監控及黃金指標
•應急事件處理
•變更管理
•需求預測和容量規劃
•資源部署
•效率與效能
（二）我們的思考：運維的六種能力
常有人問我們運維是做什麼的，我們說是做質量、效率、成本 ，具體怎麼做，要怎麼做呢，幾句話很難講清楚。《SRE Google運維解密》這本書強調實踐方法論，能落地，但不夠體系，可能是由不同的人寫不同的章節。我有機會順著可靠性這條路徑，找到了傳統行業的可靠性研究，發現了另外一片世界。大家都以為SRE是google提出來的，其實傳統行業的SRE已經存在了幾十年了，已經成為了一門學科。我個人研究之後，認為這門學科講得更體系更完整，於是希望能套到網際網路的服務中來。我參照照傳統行業一些可靠性的理論、對框架做了一些遷移，將自己的思考轉化成了一個運維的思考框架，叫做運維的六種能力，將其分為以下6點：
SER眼中的可靠性：規定條件規定時間內完成規定功能
可靠性的兩個故事：
二戰時某次美軍近半飛機無法起飛，發現是某些電子管不可靠引起的。朝鮮戰爭中美軍電子裝置不可靠，維修成本比製造成本高了幾倍。從而誕生了可靠性這門學科。
①可靠性管理
首先要分析目標業務的可靠性模型，然後畫出可靠性邏輯框圖，評估每個環節和總體的可靠性性，進行度量和評價，可以是定性的，也可以是定量的。
②感知能力
在業務上線、建立連線之後，學會如何感知其狀態、變化及問題。
③修復能力
當可靠性在設計階段不夠完善時，修復能力可以幫助我們在使用者沒有感知的狀態下修復故障。
④反脆弱能力
業務執行在一定內部或外部環境裡，尋找脆弱點和風險點，然後對它的脆弱點進行分析，並設計出反脆弱的能力，最終推動業務研發修改技術架構。
⑤保障能力
很多業務需要具備保障能力，建立保障性的設計，實現快速交付資源和快速能力到位。
⑥安全能力
如何保證我們業務安全、資料安全。
（三）我們的運維實踐
我們主要關注所負責業務的核心服務的核心指標，我們將每一條端到端鏈路都看做是一個服務，那麼服務指標可以是成功率、延遲或其他，將指標能達到某個程度作為目標；研發和運維團隊會對這個服務畫出部署構架圖、可靠性邏輯框圖（見下圖）；建立業務的可靠性模型，同時還會做一些FMECA；分析失敗模式及其帶來的影響，以及討論設計解決方案；對一些關鍵的服務，要把故障樹畫出來，度量風險，選擇優先風險，推動解決；可靠性是管理出來，是運維出來的，但首先是設計出來的，可靠性設計的方法包括避錯、改錯、容錯等。
下圖是我們負責運維的同學畫的P2P技術架構流程圖。
下圖是主播上行經過的環節，這對運維人員做監控時有指導意義。邏輯框圖越畫越細，每個點都會分析、統計它的可靠性。
1.可靠性管理的要點
①如何識別風險
可以從幾個方面判斷：
複雜度；技術成熟度；重要程度；環境嚴酷程度
②如何驗證可靠性水平
開發階段前效能測試；上線壓測；容量模型；改進測試；模擬故障測試等
③實踐
建立可靠性指標大盤；黃金指標&SLO；主播上行APM；全鏈路的可靠性；多維度的析評估體系；日報，月報，實時可靠性等。
2.感知能力
什麼是感知力，包括但不限於監控的覆蓋度，告警的實時性，準確性，觸達率，問題定位能力，趨勢預測能力 。
①監控、狀態感知能力
以監控資料作為基礎，提高人工感知能力和機器感知能力，監控是感知的基礎，監控指標多了，不能說就有了感知力，這遠遠不夠。
②故障感知能力
幫助運維人員感知業務的狀態、變化和其他問題
④AIOps大多是加強運維感知能力
大資料；智慧告警
自動化測試、壓力測試
撥測、APM
日誌trace可閱讀，可分析
3.修復能力
SRE是與故障做鬥爭的系統工程。程式寫得再好，也很難達到完全不出故障。
衡量修復能力-MTTR：
對於大部分的故障，都應該知道它的故障模式，根據故障模式就可以制定故障預案（規定條件規定時間規定人進行修復），根據預案做出一些修復工具，即人工修復或智慧自愈。當發生一些考慮不到的情況出現時，需要維修和技術保養，進行擴容或者優化。根據平均修復時間和最大修復時間進行修復評價。
虎牙的一些實踐：
主播上行切換：從早期主播重新開播修復上行問題，到後臺手工切換，到主播端自動切換。修復時間（MTTR）從半個小時縮短到5分鐘，到秒級。
觀眾排程系統：基於主播端，觀眾端排程，小運營商排程、無縫切換，按協議排程等，機房一鍵上下線。
故障修復更高一級是自愈，這也是故障修復能力轉化為軟體架構設計的高度。
4.反脆弱能力
反脆弱的設計：
保證服務在脆弱條件下的保持容忍範圍內的健壯性。
軟體總是在不同環境執行、不同條件下執行，這個條件就是可靠性中“規定的條件”。環境總是有很多脆弱點，要做脆弱性分析、反脆弱設計，最後評估評審。網際網路常見的脆弱性因素，有機房、運營商、網路、單機故障，業務突發事件負載高、流量大，也可能微服務請求超時。健壯性設計，容災性設計、高可用的設計、資源冗餘等。這也是google SRE種說的擁抱風險、度量風險、評估風險容忍能力。
S8源流的反脆弱性設計
5.保障能力
軟體架構設計特性和計劃的保障資源，能快速滿足使用要求的能力。
可靠性保障的設計，要做到無狀態，可切換，可排程，可重試等，比如說我們怎麼樣實現替換一臺故障機器，且要求在10分鐘內提供業務服務。
做可靠性保障要做一個閉環，分析目標、風險、脆弱性；設計SLO-感知還有保障、修復、演練。感知SLI的變化以及相關的子SLI的變化，儘快修復SLI退化情況，在設計時儘量考慮到各種脆弱條件，做出反脆弱的保障方案。
我們的一些實踐：
•頻寬資源保障：
能分鐘級實現頻寬排程，能1分鐘內實現切流
•伺服器保障：
3分鐘能拿到多個機房伺服器
3分鐘能把核心服務部署起來
保障能力需要架構設計、介面的設計
我們在直播間的做了一些特殊設計
保障能力是多方面能力的綜合體現：
•考驗的是自動化的程度，要有支撐系統的保障，要有自動化工具的保障
•要做人力和人員的規劃，考驗故障時人員到位時間
•要做硬體、軟體資源的供應保障
•是對軟體架構的要求，是否支援平滑擴容
•要有演練，確保能執行
6.安全能力
安全是最基本的能力，也是最大的風險之一。
資料安全：層出不窮的資料洩露事件，使用者資訊涉密事件。
業務安全：優惠券被刷，支付漏洞，主播言行、登入風控等。
使用者安全，比如滴滴的安全事件。
以上內容來自張觀石老師的分享。
由msup主辦的第七屆TOP100全球軟體案例研究峰會將於11月30日至12月3日在北京國家會議中心舉行，張觀石老師將作為大會講師為大家帶來《直播平臺的運維保障實踐》話題。
案例目標
相對於Web服務，直播音視訊的運維更特殊，業界沒有很好的參考的經驗，剛接手時，這方面運維的挑戰比較大。
（1）虎牙直播目前是異構多雲的架構，從整個鏈路看，任何觀眾都可以看到任何線路上任何主播的情況，複雜度高；
（2）研發人員以及各個團隊會比較關注自己環節上的事情，所以在虎牙運維團隊引入了多CDN以後，不僅技術和管理複雜性大幅提高，而且視訊流路徑在這麼複雜的場景下，必須深入音視訊運維工作，這對運維質量和運維人員技能提出了更高的要求。
成功（或教訓）要點
直播音視訊的傳輸質量評估體系，音視訊質量資料的全鏈路監控，以及對於網際網路服務可靠性系統工程的思考。
案例重點
運維效率的提升，直播質量的提升。
案例啟示
由於直播平臺不同以往任何架構的特殊性，以及當時視訊板塊技術的有限性，促使我們必須儘快找到運維的著力點。後來，我們接軌了近年來一直倡導的DevOps和SRE解決了這一困局。
