摘要：虎牙直播運維負責人張觀石張觀石，擁有余年網站開發架構運維經驗目前關注互聯網服務可靠性系統工程運維平臺的規劃建設網站高可用架構等方面在音視頻傳輸質量評估微服務運維方面積累了豐富的經驗。

虎牙直播運維負責人張觀石

張觀石，擁有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&度量風險
?做好監控及黃金指標
?應急事件處理
?變更管理
?需求預測和容量規劃
?資源部署
?效率與性能

（二）我們的思考：運維的六種能力

常有人問我們運維是做什么的，我們說是做質量、效率、成本 ，具體怎么做，要怎么做呢，幾句話很難講清楚?！禨RE Google運維解密》這本書強調實踐方法論，能落地，但不夠體系，可能是由不同的人寫不同的章節。我有機會順著可靠性這條路徑，找到了傳統行業的可靠性研究，發現了另外一片世界。大家都以為SRE是google提出來的，其實傳統行業的SRE已經存在了幾十年了，已經成為了一門學科。我個人研究之后，認為這門學科講得更體系更完整，于是希望能套到互聯網的服務中來。我參照照傳統行業一些可靠性的理論、對框架做了一些遷移，將自己的思考轉化成了一個運維的思考框架，叫做運維的六種能力，將其分為以下6點：

SER眼中的可靠性：規定條件規定時間內完成規定功能
可靠性的兩個故事：
二戰時某次美軍近半飛機無法起飛，發現是某些電子管不可靠引起的。朝鮮戰爭中美軍電子設備不可靠，維修成本比制造成本高了幾倍。從而誕生了可靠性這門學科。

①可靠性管理

首先要分析目標業務的可靠性模型，然后畫出可靠性邏輯框圖，評估每個環節和總體的可靠性性，進行度量和評價，可以是定性的，也可以是定量的。
②感知能力
在業務上線、建立連接之后，學會如何感知其狀態、變化及問題。

③修復能力
當可靠性在設計階段不夠完善時，修復能力可以幫助我們在用戶沒有感知的狀態下修復故障。
④反脆弱能力
業務運行在一定內部或外部環境里，尋找脆弱點和風險點，然后對它的脆弱點進行分析，并設計出反脆弱的能力，最終推動業務研發修改技術架構。
⑤保障能力

很多業務需要具備保障能力，建立保障性的設計，實現快速交付資源和快速能力到位。
⑥安全能力
如何保證我們業務安全、數據安全。

（三）我們的運維實踐

我們主要關注所負責業務的核心服務的核心指標，我們將每一條端到端鏈路都看做是一個服務，那么服務指標可以是成功率、延遲或其他，將指標能達到某個程度作為目標；研發和運維團隊會對這個服務畫出部署構架圖、可靠性邏輯框圖（見下圖）；建立業務的可靠性模型，同時還會做一些FMECA；分析失敗模式及其帶來的影響，以及討論設計解決方案；對一些關鍵的服務，要把故障樹畫出來，度量風險，選擇優先風險，推動解決；可靠性是管理出來，是運維出來的，但首先是設計出來的，可靠性設計的方法包括避錯、改錯、容錯等。

下圖是我們負責運維的同學畫的P2P技術架構流程圖。

下圖是主播上行經過的環節，這對運維人員做監控時有指導意義。邏輯框圖越畫越細，每個點都會分析、統計它的可靠性。

1.可靠性管理的要點
①如何識別風險
可以從幾個方面判斷：
復雜度；技術成熟度；重要程度；環境嚴酷程度
②如何驗證可靠性水平
開發階段前性能測試；上線壓測；容量模型；改進測試；模擬故障測試等
③實踐
建立可靠性指標大盤；黃金指標&SLO；主播上行APM；全鏈路的可靠性；多維度的析評估體系；日報，月報，實時可靠性等。

2.感知能力
什么是感知力，包括但不限于監控的覆蓋度，告警的實時性，準確性，觸達率，問題定位能力，趨勢預測能力 。
①監控、狀態感知能力
以監控數據作為基礎，提高人工感知能力和機器感知能力，監控是感知的基礎，監控指標多了，不能說就有了感知力，這遠遠不夠。
②故障感知能力

幫助運維人員感知業務的狀態、變化和其他問題

④AIOps大多是加強運維感知能力
大數據；智能告警
自動化測試、壓力測試
撥測、APM
日志trace可閱讀，可分析

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解決了這一困局。