虎牙直播運維負責人張觀石 | SRE實踐指南

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

 

本文是根據虎牙直播運維負責人張觀石10月20日在msup攜手魅族、Flyme、百度雲主辦的第十三期魅族開放日《虎牙直播平臺SRE實踐》演講中的分享內容整理而成。

 

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

 

目錄

1、 直播平臺的架構及運維挑戰 

（一） 音視頻傳輸流程及挑戰 

（二） 一個直播間的流程 

（三） 直播平臺的運維挑戰 

2、 咱們的思考和運維實踐 

（一） Google SRE介紹 

  • SRE是什麼 

  • Google SRE方法論

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

（三） 咱們的運維實踐 

  1. 運維可靠性管理 

  2. 感知能力 

  3. 修復能力   

  4. 反脆弱能力 

  5. 保障能力 

  6. 安全能力 

 

虎牙直播介紹

虎牙直播是以遊戲爲主要內容，涵蓋娛樂、綜藝、教育、戶外、體育等多種內容的直播平臺，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解決了這一困局。

 

 

點擊「閱讀原文「或識別圖中二維碼，便可查看更多運維案例！