本文根據張觀石老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現場演講內容整理而成。

很榮幸被邀請來Gdevops峰會作分享，我叫張觀石，目前在虎牙直播負責業務運維工作。在正式開講之前，先和大家談談我個人對運維的三點思考，拋個引子：

對運維的思考

1、傳統運維窘境

我們運維一般是這樣的，把軟硬體資源按計劃準備好，按需求安裝起來，讓業務快速上線，讓伺服器上程序和和業務正常，處理各種故障，響應各方的需求。我們經常陷在處理這些工作上，成為操作員、保姆、救火隊員。

我們運維也都很努力，也不想每次被動救火，希望能主動控制服務狀態，體現我們的技術價值，做了很多有效的工作。運維人員是非常勤奮、愛學習的，具有非常廣泛的技術視野和技能池。但在技術生態中好像總是處於一種較為弱勢的、從屬的、被動的地位。

2、運維技術深度和價值

我個人也是在不斷思考和學習， 幾年前也發現自身傳統運維的侷限所在。嘗試過深入業務，通過運維人員掌握更多業務知識，瞭解技術架構，更深度參與線上業務維護來提升價值。 比如，我們深入掌握了Nginx的運維知識和優化技術，掌握了MySQL的優化技術，掌握了PHP/Java的技術。這確實能一定程度提升業務質量，不過靠的是個人的主動性和某方面技術的深入，沒有提升為SRE這麼高的一種方法論體系。可以說我們一直在實踐中進行摸索， 而SRE幫我們梳理了方法，樹立了標杆，指引了方向。

3、DevOps和SRE的關係

DevOps 是一種運維研發協作，甚至是整個業務鏈路上的敏捷協作，是一種的文化和運動，而SRE是DevOps的一種實踐、一種方法論。SRE對我們最大收益是提供了一種方法論體系，來指導我們運維工作，也提供了一些具體的實踐來供我們參考。

今天想簡單跟大家分享下我們在運維上跟SRE比較類似的經驗。

我們的運維現狀與挑戰

1、直播平臺的挑戰

YY是秀場直播的開創者，而虎牙直播則是國內遊戲直播的先行者，此外，虎牙直播是從YY裡面分出來的一家公司，承襲了YY的部分技術基因。現在做直播，有很多CDN廠商可以選擇，但我們在開始做直播時還沒有這麼多廠商，很多技術靠自己研究和實現，所以我們很早就有一套直播體系

大家看到這個直播技術的流程，首先是主播開播，這裡有N種方式可以開播，然後有多種推流的方式，將其推到某一條線路上，可能是我們自己的線路，也可能是CDN的線路，而後CDN要轉推到多家去，還要在整個網路裡分發到CDN邊緣，通過轉碼，轉碼到各種地區的運營商，最後觀眾通過各種使用者端連線到這些邊緣節點的音視訊流，觀眾可能是併發百萬級的。

整個過程路徑很長，需要在幾秒之內完成，跟一般的Web類網際網路業務是不同的，是我個人經歷過的最複雜的網際網路應用。

2、技術複雜性和運維著力點

對YY來說，在開始做直播的時候，還是有一定的技術開創性。但在這方面，我們運維的挑戰比較大。看到下面主播到觀眾遍佈的這張架構圖：

一方面，虎牙直播目前是異構多雲的架構，從整個鏈路看，任何觀眾都可以看到任何線路上任何主播的情況，複雜度高。

另一方面，相對來說，研發同學以及各個團隊會比較關注自己環節上的事情，所以在我們引入了多CDN以後，不僅技術和管理複雜性大幅提高，而且視訊流路徑在這麼複雜的場景下，必須深入音視訊運維工作，這對運維質量和運維人員技能提出了更高的要求。

因此，由於直播平臺不同以往任何架構的特殊性，以及當時視訊板塊技術的有限性，促使我們必須儘快找到運維的著力點。後來，我們接軌了近年來一直倡導的DevOps和SRE解決了這一困局，接下來便分享虎牙直播在這方面上的一些實踐經驗。

關於SRE理念

1、SRE回顧

SRE由三個單片語成的：S、R、E，我先簡單解釋一下：

• 第一個E。有兩種理解：一則是Engineer工程師，一則是Engineering工程化。在國內的很多分享文章裡，講得更多是傾向於工程師這個概念。我個人更認同E是工程和工程化，比如我們不叫SRE崗位，但做的事情是提升業務可靠性的“工程”，甚至事情不是我們單獨在做，而是和業務研發聯合來做。
• 第二個R。Reliability，意思是可靠性，表達在業務上、工程上就是質量，理解為對外部終端使用者的質量和價值。
• 第三個S。Site/Service，即運維物件、網站服務、業務服務和線上的各種服務。

2、SRE理念

從另外一個角度來看SRE崗位，Google是招聘軟體工程師培養成為SRE的，而在國內，我們傳統運維工程師如何轉型，是一個值得思考的問題。目前我們在傳統Ops模式上的主要問題是：過分關注如何解決那些常規問題、緊急問題，而不是找到根本原因和減少緊急事件的數量。大家都不喜歡風險，都不喜歡不期而遇、隨時可能出現的故障，可故障經常不請自來，怎麼辦？SRE給出的答案是：

第一，擁抱風險。並且把風險識別出來，用SLI/SLO加以評估、度量、量化出來，最終達到消除風險的目的。

第二，質量目標。一般可能認為沒有故障就是正常，萬事大吉了。SRE要求明確定義SLI、SLO，定量分析某項服務的質量，而監控系統是 SRE 團隊監控服務質量和可用性的一個主要手段。通過設立這樣的指標，可量化質量，使得我們有權力PK業務研發，也能跟老闆對話，取得更大的話語權。

第三，減少瑣事。SRE理念裡講究要花50%左右的時間在工程研發上，剩餘50%的時間用來做一些如資源準備、變更、部署的常規運維，以及檢視和處理監控、應急事務處理、事後總結等應急處理工作。如果一個螢幕上十幾個視窗，各種刷屏，但卻不徹底解決問題，這時就需要用更好的方式——自動化、系統化、工具化的方式 ,甚至是自治的方式去處理這些“瑣事”。

這裡對傳統運維的思維也有一些挑戰，因為我們日常做得最多的工作在SRE中是被定義為價值不高的瑣事，運維不是操作，“運維”是個工作內容，人工或是軟體都可以做。在谷歌裡，會要求SRE有能力進行自動化工具研發，對各種技術進行研究 ，用自動化軟體完成運維工作 ，並通過軟體來制定、管理合理SLI/SLO。

第四，工程研發。我個人理解的工程研發工作包括三個方面：

1. 推進產品研發改進架構，經常和研發探討架構、叢集、效能問題；
2. 引入新的運維技術，基礎元件要hold住，比如TSDB、Bosun、Consul、Zipkin等；
3. 自研工程技術、平臺、工具、系統、基礎元件、框架。

我們目前在這些方面都有一些開始在探索和轉型，下面將展開詳談。

虎牙直播的SRE實踐

1、質量指標SLI

我們來看看直播平臺面對的風險和質量指標，以及我們是怎麼樣通過工程手段來提升質量的。

直播流媒體技術中有很多指標，內部大概有上百個指標，常用的也有十幾個，下面是音視訊方面的一些場景：

（1）直播質量指標

• 主播端：開播、採集、處理、推流失敗、崩潰
• 觀眾端：進不了直播、拉視訊失敗、黑屏、花屏、卡頓、延遲

（2）卡頓分析

當我們把卡頓單獨切出來進行分析，會發現它是由比如平臺、主播、線路、地區、運營商、時間段、端、時長、使用者數量、卡頓率等多方面因素制約的。雖然卡頓是平臺中最常見也是最重要的質量指標，但什麼是卡頓、什麼是卡頓率？業界目前沒有統一的定義。下面我們以虎牙的定義，來講講直播的SLI、SLO。

2、SLI卡頓定義

• 第一種情況，由延時造成的卡頓。

如果沒有丟幀，但持續超過一定時間沒有畫面就算是卡頓。（比如1，2是連續的丟幀，2比應該播放時刻晚數百ms算一個卡頓）

• 第二種情況，由丟幀造成的卡頓。

如果連續丟幀大於1個，而且持續數百ms沒有畫面就是產生了卡頓。

• 第三種情況，由跳幀造成的卡頓。

如果連續丟幀大於1個，有連續畫面，但丟掉的幀播放時長大於一定時間的情況。

（即通過增加丟掉的幀前面幀的播放時長，可以有效減少卡頓，但後續畫面接上去時會產生畫面跳動感覺，超過一定時間使用者就能察覺。）

• 最後一種情況，是由視訊源幀率低造成的卡頓。

如果可解碼幀幀率低於10幀，以及丟幀率大於20%時會發生卡頓。（因為視訊隨機丟幀後，導致幀率下降，容易被人眼看出來）

3、卡頓率SLI定義

有了卡頓之後，怎麼把卡頓計算成卡頓率呢？業界沒有統一的定義，有人統計卡頓使用者比例，卡頓時長方法，但這些太粗了，都不能滿足我們的要求。而且很多的維度分析，都不能很好地衡量質量和做監控，卡頓率這事其實有點小複雜，這裡說說我們的一些計算方法。

（1）卡頓資料

對於卡頓的資料，我們有5秒、20秒的粒度上報，而且上報的是有多維度資訊。那卡頓率怎麼來定義？

（2）卡頓率：卡次數/使用者數

我們稍稍分析下，從縱向看，有全平臺或某條流某個時刻的卡頓率，這個很好理解，單單統計這個時刻的卡頓上報次數/上報樣本數即可。

從橫向看，單條流在直播時段內的卡頓率，比如一個主播的卡頓率，卡頓樣本次數累加/上報樣本數累加；從全體來看，可以分全平臺每天的卡頓率。此外，我們還有計算線路卡頓率以及其它多種維度的卡頓率。

但這裡會有一個小小的問題：一個直播間有小部分使用者一直卡和在一小段時間內一直卡頓，卡頓率可能都是一樣的，這顯然不公平，於是我們在這中間又多定義了中度卡頓率和重度卡頓率。

其中，當某個時刻卡頓率區間範圍為10%-40%，屬於中度卡頓率，超過40%的。直播平臺頻寬是非常猛的，每年可能有幾個億的頻寬費用要付出去，而付給每一家都是一個很大的量。老闆很重視這個情況，如果沒有這個卡頓率，我們很難去跟老闆上報質量如何，應該分配多少量給哪一家，得有資料可以作為決策的依據。

4、全鏈路監控

有了卡頓率之後，接下來就是如何做監控。這是我們直播視訊質量全鏈路監控圍繞視訊直播平臺的場景，我們構建了從主播視訊源到觀眾端觀看直播所有環節的點，實時採集，展示、定位、告警系統。這個系統能夠幫助運維人員快速準確定位到直播流卡頓的現象和原因，也能評估長期總體質量。各個環節研發往往對自己的節點感興趣，由運維對整體負責，串起來。在這裡面，整合多環節質量資料，體現了DevOps的理念；通過構建系統來做，體現了SRE的工程化理念；從上報到監控，告警、評估閉環，能力落地到系統，我們不是靠專家，而是解放了專家。

有了全鏈路系統後，我們還做了一個告警和事後問題分析總結的反饋閉環。

5、故障處理和質量閉環

這是我們做的一個質量故障處理和質量評估的閉環。首先是質量資料的採集，上報儲存，然後由監控系統來監控，通過秒級監控，自動報障到運維和CDN廠商，由廠商人員分析定位後反饋，可以減少運維的人工參與。

從這個監控全平臺的卡頓資料，我們還可以再挖掘一些資料出來，比如每天生成一些卡頓日報，然後自動發到我們內部和廠商兩邊，廠商會自己來做一些回覆、調查和總結，最後反饋回給我們，這樣通過定期Review CDN的質量，進行定期總結和評估對比，我們再以此為根據，看看質量調整和效果的情況。

同時我們會有一些評估的手段，也是從這些資料裡面把它挖掘出來的，用來推動處理CDN直播平臺的發展和完善。

還有就是建立更開放的技術交流氛圍，把質量資料反饋給各CDN，推動分析問題。以往每家廠商過來都要踩很多坑，現在我們對各家CDN、各條線路、各個地區和各個運營商的質量線路都進行了切量、排程、線路的調整，實現了大部分主播的監控覆蓋。當然，在這裡面我們還會有一些運維能力在整合，後面會再展開講。

6、質量指標SLI/SLO效果

這是我們把這整個質量指標串起來之後實現的效果：

案例1：直播音視訊質量

• 第一，建立了全鏈路的監控系統，實現了秒級發現流級別的卡頓情況，也提升了監控的覆蓋率，同時是自動化、實時性、可觀測的。
• 第二，通過建立質量模型，運用卡頓率和穩定性可以隨時評估主播、平臺、線路的質量，可以Review質量。
• 第三，和CDN廠商一起持續發現和優化質量。
• 第四，把能力推到一線值班。把能力推到一線值班 ，以前運維是沒有音視訊Oncall能力的，只有資深的音視訊研發工程師可以處理問題，現在一線值班，我們業務運維可以當做二線，只處理一些更重要的問題。

案例2：點播成功率

我們在點播專案上也用了質量指標的方式去做，也實現不錯的效果。目前我們可以實現評估供應商，僅保留好用的；推動播放器改進統計，優化自動上報；推動服務端研發加強故障統計，整個質量有了大幅度的提升。同時我們也可以把全平臺評估業務質量，生成相關資料報告給老闆去看，讓他了解到專案目前的質量狀況和質量變化情況。

7、虎牙實踐：頻寬排程

接下來介紹虎牙頻寬排程的一個實踐，會從排程的原因、方法和評估三方面進行介紹。

（1）為什麼要排程

• 質量挑戰。質量是我們最在乎的事情，但每家CDN線路和我們都經常有故障等各類情況出現，這裡就需要有一個排程的能力，當某條線路或者某些情況下出現質量問題了，可以及時把它調走。
• 容量挑戰。直播平臺對頻寬消耗是非常大的，可每家CDN可承受的頻寬是有一定上限的，必須要做一定排程，特別是大型活動上，要防止某家CDN廠商全部掛掉或者區域性掛掉的情況。

（2）排程方法

排程方法有這樣主播排程、觀眾排程、靜態排程、動態排程、無縫切換能力幾種。

主播排程，就是把這個主播排程到某條線路上去，我們或某家CDN的都可以。主播的排程又分為單CDN內的智慧排程和多CDN的智慧排程兩種，我們會做一些預設的配置，並提供動態的能力，實現無縫的切流。觀眾端也是做了靜態和動態的排程策略，優先使用平臺裡它的質量會應該是更有所保障的。此外，我們也提供了動態排程系統，讓它在觀眾進直播間時可以調到某一條線路上去。

在這整個過程中，我們運維人員都參與其中，提出我們的需求和目標。並跟研發一起，或者自己開發其中的某些環節，形成一個個工程工作，促使業務質量大幅提升，並且自己的能力落地到了工程系統中，實現了運維價值的輸出。

SRE理念的一些實踐

除了上述的，我們還有一些其它比較接近SRE理念的實踐，這裡先和大家簡單分享一下。

1、以SRE的姿勢接維

如何接維一個新的業務，或是從其他人手裡接維老專案；接維後如何處理和其他團隊的關係，如何持續改進業務質量，這部分可以說是DevOps的實踐，也是有我整理出來的一些實踐，具體來說：

（1）瞭解產品，作為使用者區瞭解，以開發者視角去了解產品，瞭解網站結構，以及背後的技術原理和流程；

（2）閱讀文件，獲取開發文件、運維文件、設計文件、閱讀wiki等；

（3）掌握資源：作為內部人員去了解部署和伺服器等資源、CMDB ，瞭解監控 、管理後臺；

（4）熟悉架構：請研發leader 整體介紹產品、架構、部署；

（5）獲取故障：請研發轉發最近的bug郵件、故障郵件，瞭解最近的事故和事後總結；

（6）獲取需求：最近重要的需求和開發計劃；

（7）運研關係：參與研發週會，積極合作 ，改變運維與研發的關係；

（8）瞭解期望：和產品研發Leader溝通，瞭解核心問題和對運維的期望；

（9）梳理指標：核心業務指標，加上監控；

（10）輸出進展：舉行運維研發週會，請研發上級領導參加，瞭解最近接維後的故障；

（11）推進改進：大家都重視後，提出改進需求和工程計劃；

（12）輸出價值：把核心指標提升為公司級關注的指標。

2、運維研發會議

運維研發會議，我們試過了，效果很不錯。時間上來說是每週一次，有兩級的領導在場，包括研發團隊的同學、具體業務研發的領導和上一級業務領導在場。內容有這麼幾點：

（1）定期Review效能指標、容量資料、可用性情況等質量、趨勢；

（2）緊急的告警 、非緊急的告警；

（3）即將進行的生產環境變化；

（4）要進行技術決策的事宜；

（5）運維希望研發推進的事情、研發希望運維推進的事情；

（6）技術工作的同步；

（7）接下來待辦事項及計劃。

3、事後報告

事後總結和改進是SRE切入深入業務的最直接的方式。這是我們的模板：

其中，改進措施裡面必須是要長效的措施，而不能是頭痛醫頭，腳痛醫腳這種方式。

轉型SRE

1、SRE與運維的關係

那麼，傳統運維究竟如何轉型SRE呢？正如我第一部分講到的，在谷歌內部，是直接招聘軟體工程師專職做SRE，跟傳統的業務公司不一樣，它是有第三種崗位的。但我個人的理解是，SRE是一個工程性的活動，不一定是一個崗位，研發可以轉過來，運維也可以轉過來，所以運維人員要有認識，這是可以互相搶飯碗的。

2、如何轉型SRE

從SRE的工程性活動這個層面出發，在研發層面，運維做SRE，不一定是完全自己做，我們可以提出需求、設想和計劃，然後找開發的資源實現，這是工程師的維度。此外，在反向工程的層面上，深入理解技術架構，學會站在更高視角去完善自己的架構思維和質量思維，留出時間來用於工程相關的思考與學習。要明確運維的本質：就是人與機器一起完成的工程性的工作！

作者：

張觀石，虎牙直播業務運維負責人，《運維前線》聯合作者。擁有多年網際網路業務運維經驗。

原文來自微信公眾號：DBAplus社群