運維人員是非常勤奮、愛學習的，具有非常廣泛的技術視野和技能池。但在技術生態中為何總是處于一種較為弱勢的、從屬的、被動的地位？

我叫張觀石，目前在虎牙直播負責業務運維工作。先和大家談談我個人對運維的三點思考，拋個引子：

對運維的三個思考

傳統運維窘境

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

我們運維也都很努力，也不想每次被動救火，希望能主動控制服務狀態，體現我們的技術價值，做了很多有效的工作。

運維人員是非常勤奮、愛學習的，具有非常廣泛的技術視野和技能池。但在技術生態中好像總是處于一種較為弱勢的、從屬的、被動的地位。

運維技術深度和價值

我個人也是在不斷思考和學習， 幾年前也發現自身傳統運維的局限所在。并嘗試過深入業務，通過運維人員掌握更多業務知識，了解技術架構，更深度參與線上業務維護來提升價值。

比如，我們深入掌握了 Nginx 的運維知識和優化技術，掌握了 MySQL 的優化技術，掌握了 PHP/Java 的技術。

這確實能一定程度提升業務質量，不過靠的是個人的主動性和某方面技術的深入，沒有提升為 SRE 這么高的一種方法論體系。

可以說我們一直在實踐中進行摸索， 而 SRE 幫我們梳理了方法，樹立了標桿，指引了方向。

DevOps 和 SRE 的關系

DevOps 是一種運維研發協作，甚至是整個業務鏈路上的敏捷協作，是一種文化和運動，而 SRE 是 DevOps 的一種實踐、一種方法論。

SRE 對我們***收益是提供了一種方法論體系，來指導我們運維工作，也提供了一些具體的實踐來供我們參考。

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

虎牙直播運維現狀與挑戰

直播平臺的挑戰

YY 是秀場直播的開創者，而虎牙直播則是國內游戲直播的先行者，此外，虎牙直播是從 YY 里面分出來的一家公司，承襲了 YY 的部分技術基因。

現在做直播，有很多 CDN 廠商可以選擇，但我們在開始做直播時還沒有這么多廠商，很多技術靠自己研究和實現，所以我們很早就有一套直播體系。

大家看到這個直播技術的流程，首先是主播開播，這里有 N 種方式可以開播。

然后有多種推流的方式，將其推到某一條線路上，可能是我們自己的線路，也可能是 CDN 的線路，而后 CDN 要轉推到多家去，還要在整個網絡里分發到 CDN 邊緣，通過轉碼，轉碼到各種地區的運營商。

***觀眾通過各種用戶端連接到這些邊緣節點的音視頻流，觀眾可能是并發***的。

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

技術復雜性和運維著力點

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

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

另一方面，相對來說，研發同學以及各個團隊會比較關注自己環節上的事情。

所以在我們引入了多 CDN 以后，不僅技術和管理復雜性大幅提高，而且視頻流路徑在這么復雜的場景下，必須深入音視頻運維工作，這對運維質量和運維人員技能提出了更高的要求。

因此，由于直播平臺不同以往任何架構的特殊性，以及當時視頻板塊技術的有限性，促使我們必須盡快找到運維的著力點。

后來，我們接軌了近年來一直倡導的 DevOps 和 SRE 解決了這一困局，接下來便分享虎牙直播在這方面上的一些實踐經驗。

關于 SRE 理念

SRE 回顧

SRE 是由三個單詞組成的，我先簡單解釋一下：

• ***個 E。有兩種理解：一則是 Engineer 工程師，一則是 Engineering 工程化。在國內的很多分享文章里，講得更多是傾向于工程師這個概念。

我個人更認同 E 是工程和工程化，比如我們不叫 SRE 崗位，但做的事情是提升業務可靠性的“工程”，甚至事情不是我們單獨在做，而是和業務研發聯合來做。

• 第二個 R。Reliability，意思是可靠性，表達在業務上、工程上就是質量，理解為對外部最終用戶的質量和價值。
• 第三個 S。Site/Service，即運維對象、網站服務、業務服務和線上的各種服務。

SRE 理念

從另外一個角度來看 SRE 崗位，Google 是招聘軟件工程師培養成為 SRE 的，而在國內，我們傳統運維工程師如何轉型，是一個值得思考的問題。

目前我們在傳統 Ops 模式上的主要問題是：過分關注如何解決那些常規問題、緊急問題，而不是找到根本原因和減少緊急事件的數量。

大家都不喜歡風險，都不喜歡不期而遇、隨時可能出現的故障，可故障經常不請自來，怎么辦？

SRE 給出的答案是：

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

第二，質量目標。一般可能認為沒有故障就是正常，萬事大吉了。SRE 要求明確定義 SLI、SLO，定量分析某項服務的質量，而監控系統是 SRE 團隊監控服務質量和可用性的一個主要手段。

通過設立這樣的指標，可量化質量，使得我們有權力 PK 業務研發，也能跟老板對話，取得更大的話語權。

第三，減少瑣事。SRE 理念里講究要花 50% 左右的時間在工程研發上，剩余 50% 的時間用來做一些如資源準備、變更、部署的常規運維，以及查看和處理監控、應急事務處理、事后總結等應急處理工作。

如果一個屏幕上十幾個窗口，各種刷屏，但卻不徹底解決問題，這時就需要用更好的方式——自動化、系統化、工具化的方式 ,甚至是自治的方式去處理這些“瑣事”。

這里對傳統運維的思維也有一些挑戰，因為我們日常做得最多的工作在 SRE 中是被定義為價值不高的瑣事，運維不是操作，“運維”是個工作內容，人工或是軟件都可以做。

在谷歌里，會要求 SRE 有能力進行自動化工具研發，對各種技術進行研究 ，用自動化軟件完成運維工作 ，并通過軟件來制定、管理合理 SLI/SLO。

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

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

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

虎牙直播的 SRE 實踐

質量指標 SLI

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

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

直播質量指標

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

卡頓分析

當我們把卡頓單獨切出來進行分析，會發現它是由比如平臺、主播、線路、地區、運營商、時間段、端、時長、用戶數量、卡頓率等多方面因素制約的。

雖然卡頓是平臺中最常見也是最重要的質量指標，但什么是卡頓、什么是卡頓率？業界目前沒有統一的定義。下面我們以虎牙的定義，來講講直播的 SLI、SLO。

SLI 卡頓定義

卡頓分為以下四種情況：

• 由延時造成的卡頓。如果沒有丟幀，但持續超過一定時間沒有畫面就算是卡頓。（比如 1，2 是連續的丟幀，2 比應該播放時刻晚數百 ms 算一個卡頓）
• 由丟幀造成的卡頓。如果連續丟幀大于 1 個，而且持續數百 ms 沒有畫面就是產生了卡頓。
• 由跳幀造成的卡頓。如果連續丟幀大于 1 個，有連續畫面，但丟掉的幀播放時長大于一定時間的情況。（即通過增加丟掉的幀前面幀的播放時長，可以有效減少卡頓，但后續畫面接上去時會產生畫面跳動感覺，超過一定時間用戶就能察覺。）
• 是由視頻源幀率低造成的卡頓。如果可解碼幀幀率低于 10 幀，以及丟幀率大于 20% 時會發生卡頓。（因為視頻隨機丟幀后，導致幀率下降，容易被人眼看出來）

卡頓率 SLI 定義

有了卡頓之后，怎么把卡頓計算成卡頓率呢？業界沒有統一的定義，有人統計卡頓用戶比例，卡頓時長方法，但這些太粗了，都不能滿足我們的要求。

而且很多的維度分析，都不能很好地衡量質量和做監控，卡頓率這事其實有點小復雜，這里說說我們的一些計算方法。

卡頓數據

對于卡頓的數據，我們有 5 秒、20 秒的粒度上報，而且上報的是多維度信息。那卡頓率怎么來定義？

卡頓率：卡次數/用戶數

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

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

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

其中，當某個時刻卡頓率區間范圍為 10%-40%，屬于中度卡頓率，超過 40% 的屬于重度卡頓率。

直播平臺帶寬是非常猛的，每年可能有幾個億的帶寬費用要付出去，而付給每一家都是一個很大的量。

老板很重視這個情況，如果沒有這個卡頓率，我們很難去跟老板上報質量如何，應該分配多少量給哪一家，得有數據可以作為決策的依據。

全鏈路監控

有了卡頓率之后，接下來就是如何做監控。直播視頻質量全鏈路監控圍繞視頻直播平臺的場景，我們構建了從主播視頻源到觀眾端觀看直播所有環節的點，實時采集，展示、定位、告警系統。

這個系統能夠幫助運維人員快速準確定位到直播流卡頓的現象和原因，也能評估長期總體質量。各個環節研發往往對自己的節點感興趣，由運維對整體負責，串起來。

在這里面，整合多環節質量數據，體現了 DevOps 的理念；通過構建系統來做，體現了 SRE 的工程化理念；從上報到監控，告警、評估閉環，能力落地到系統，我們不是靠專家，而是解放了專家。

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

故障處理和質量閉環

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

從這個監控全平臺的卡頓數據，我們還可以再挖掘一些數據出來，比如每天生成一些卡頓日報，然后自動發到我們內部和廠商兩邊，廠商會自己來做一些回復、調查和總結，***反饋回給我們。

這樣通過定期 Review CDN 的質量，進行定期總結和評估對比，我們再以此為根據，看看質量調整和效果的情況。

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

還有就是建立更開放的技術交流氛圍，把質量數據反饋給各 CDN，推動分析問題。

以往每家廠商過來都要踩很多坑，現在我們對各家 CDN、各條線路、各個地區和各個運營商的質量線路都進行了切量、調度、線路的調整，實現了大部分主播的監控覆蓋。

當然，在這里面我們還會有一些運維能力在整合，后面會再展開講。

質量指標 SLI/SLO 效果

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

案例 1：直播音視頻質量

建立了全鏈路的監控系統，實現了秒級發現流級別的卡頓情況，也提升了監控的覆蓋率，同時是自動化、實時性、可觀測的。

通過建立質量模型，運用卡頓率和穩定性可以隨時評估主播、平臺、線路的質量，可以Review質量。

和 CDN 廠商一起持續發現和優化質量。

把能力推到一線值班。把能力推到一線值班 ，以前運維是沒有音視頻Oncall能力的，只有資深的音視頻研發工程師可以處理問題，現在一線值班，我們業務運維可以當做二線，只處理一些更重要的問題。

案例 2：點播成功率

我們在點播項目上也用了質量指標的方式去做，也實現不錯的效果。目前我們可以實現評估供應商，僅保留好用的；推動播放器改進統計，優化自動上報；推動服務端研發加強故障統計，整個質量有了大幅度的提升。

同時我們也可以全平臺評估業務質量，生成相關數據報告給老板去看，讓他了解到項目目前的質量狀況和質量變化情況。

虎牙實踐：帶寬調度

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

為什么要調度？有兩點原因：

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

調度方法有如下幾種：

• 主播調度
• 觀眾調度
• 靜態調度
• 動態調度
• 無縫切換能力調度

主播調度，就是把這個主播調度到某條線路上去，我們或某家 CDN 的都可以。主播的調度又分為單 CDN 內的智能調度和多 CDN 的智能調度兩種，我們會做一些默認的配置，并提供動態的能力，實現無縫的切流。

觀眾端也是做了靜態和動態的調度策略，優先使用平臺里的線路，它的質量會更有所保障的。

此外，我們也提供了動態調度系統，讓它在觀眾進直播間時可以調到某一條線路上去。

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

SRE 理念的一些實踐

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

以 SRE 的姿勢接維

如何接維一個新的業務，或是從其他人手里接維老項目；接維后如何處理和其他團隊的關系，如何持續改進業務質量，這部分可以說是 DevOps 的實踐，也是有我整理出來的一些實踐。

具體來說有如下幾點：

• 了解產品，作為用戶去了解，以開發者視角去了解產品，了解網站結構，以及背后的技術原理和流程。
• 閱讀文檔，獲取開發文檔、運維文檔、設計文檔、閱讀 WiKi 等。
• 掌握資源，作為內部人員去了解部署和服務器等資源、CMDB ，了解監控 、管理后臺。
• 熟悉架構，請研發 Leader 整體介紹產品、架構、部署。
• 獲取故障，請研發轉發最近的 Bug 郵件、故障郵件，了解最近的事故和事后總結。
• 獲取需求，最近重要的需求和開發計劃。
• 運研關系，參與研發周會，積極合作 ，改變運維與研發的關系。
• 了解期望，和產品研發 Leader 溝通，了解核心問題和對運維的期望。
• 梳理指標，核心業務指標，加上監控。
• 輸出進展，舉行運維研發周會，請研發上級領導參加，了解最近接維后的故障。
• 推進改進，大家都重視后，提出改進需求和工程計劃。
• 輸出價值，把核心指標提升為公司級關注的指標。

運維研發會議

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

內容有如下幾點：

• 定期 Review 性能指標、容量數據、可用性情況等質量、趨勢。
• 緊急的告警 、非緊急的告警。
• 即將進行的生產環境變化。
• 要進行技術決策的事宜。
• 運維希望研發推進的事情、研發希望運維推進的事情。
• 技術工作的同步。
• 接下來待辦事項及計劃。

事后報告

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

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

轉型 SRE

SRE 與運維的關系

傳統運維究竟如何轉型 SRE 呢？正如我***部分講到的，在谷歌內部，是直接招聘軟件工程師專職做 SRE，跟傳統的業務公司不一樣，它是有第三種崗位的。

但我個人的理解是，SRE 是一個工程性的活動，不一定是一個崗位，研發可以轉過來，運維也可以轉過來，所以運維人員要有認識，這是可以互相搶飯碗的。

如何轉型 SRE

從 SRE 的工程性活動這個層面出發，在研發層面，運維做 SRE，不一定是完全自己做，我們可以提出需求、設想和計劃，然后找開發的資源實現，這是工程師的維度。

此外，在反向工程的層面上，深入理解技術架構，學會站在更高視角去完善自己的架構思維和質量思維，留出時間來用于工程相關的思考與學習。要明確運維的本質：就是人與機器一起完成的工程性的工作！