“

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

我叫張觀石，目前在虎牙直播負(fù)責(zé)業(yè)務(wù)運維工作。先和大家談?wù)勎覀€人對運維的三點思考，拋個引子：

對運維的三個思考

傳統(tǒng)運維窘境

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

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

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

運維技術(shù)深度和價值

我個人也是在不斷思考和學(xué)習(xí)， 幾年前也發(fā)現(xiàn)自身傳統(tǒng)運維的局限所在。并嘗試過深入業(yè)務(wù)，通過運維人員掌握更多業(yè)務(wù)知識，了解技術(shù)架構(gòu)，更深度參與線上業(yè)務(wù)維護來提升價值。

比如，我們深入掌握了 Nginx 的運維知識和優(yōu)化技術(shù)，掌握了 MySQL 的優(yōu)化技術(shù)，掌握了 PHP/Java 的技術(shù)。

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

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

DevOps 和 SRE 的關(guān)系

DevOps 是一種運維研發(fā)協(xié)作，甚至是整個業(yè)務(wù)鏈路上的敏捷協(xié)作，是一種文化和運動，而 SRE 是 DevOps 的一種實踐、一種方法論。

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

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

虎牙直播運維現(xiàn)狀與挑戰(zhàn)

直播平臺的挑戰(zhàn)

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

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

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

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

最后觀眾通過各種用戶端連接到這些邊緣節(jié)點的音視頻流，觀眾可能是并發(fā)百萬級的。

整個過程路徑很長，需要在幾秒之內(nèi)完成，跟一般的 Web 類互聯(lián)網(wǎng)業(yè)務(wù)是不同的，是我個人經(jīng)歷過的最復(fù)雜的互聯(lián)網(wǎng)應(yīng)用。

技術(shù)復(fù)雜性和運維著力點

對 YY 來說，在開始做直播的時候，還是有一定的技術(shù)開創(chuàng)性。但在這方面，我們運維的挑戰(zhàn)比較大?？吹较旅嬷鞑サ接^眾遍布的這張架構(gòu)圖：

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

另一方面，相對來說，研發(fā)同學(xué)以及各個團隊會比較關(guān)注自己環(huán)節(jié)上的事情。

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

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

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

關(guān)于 SRE 理念

SRE 回顧

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

第一個 E。有兩種理解：一則是 Engineer 工程師，一則是 Engineering 工程化。在國內(nèi)的很多分享文章里，講得更多是傾向于工程師這個概念。 我個人更認(rèn)同 E 是工程和工程化，比如我們不叫 SRE 崗位，但做的事情是提升業(yè)務(wù)可靠性的“工程”，甚至事情不是我們單獨在做，而是和業(yè)務(wù)研發(fā)聯(lián)合來做。 第二個 R。Reliability，意思是可靠性，表達在業(yè)務(wù)上、工程上就是質(zhì)量，理解為對外部最終用戶的質(zhì)量和價值。 第三個 S。Site/Service，即運維對象、網(wǎng)站服務(wù)、業(yè)務(wù)服務(wù)和線上的各種服務(wù)。

SRE 理念

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

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

大家都不喜歡風(fēng)險，都不喜歡不期而遇、隨時可能出現(xiàn)的故障，可故障經(jīng)常不請自來，怎么辦？

SRE 給出的答案是：

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

第二，質(zhì)量目標(biāo)。一般可能認(rèn)為沒有故障就是正常，萬事大吉了。SRE 要求明確定義 SLI、SLO，定量分析某項服務(wù)的質(zhì)量，而監(jiān)控系統(tǒng)是 SRE 團隊監(jiān)控服務(wù)質(zhì)量和可用性的一個主要手段。

通過設(shè)立這樣的指標(biāo)，可量化質(zhì)量，使得我們有權(quán)力 PK 業(yè)務(wù)研發(fā)，也能跟老板對話，取得更大的話語權(quán)。

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

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

這里對傳統(tǒng)運維的思維也有一些挑戰(zhàn)，因為我們?nèi)粘Ｗ龅米疃嗟墓ぷ髟?SRE 中是被定義為價值不高的瑣事，運維不是操作，“運維”是個工作內(nèi)容，人工或是軟件都可以做。

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

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

推進產(chǎn)品研發(fā)改進架構(gòu)，經(jīng)常和研發(fā)探討架構(gòu)、集群、性能問題。 引入新的運維技術(shù)，基礎(chǔ)組件要 hold 住，比如 TSDB、Bosun、Consul、Zipkin 等。 自研工程技術(shù)、平臺、工具、系統(tǒng)、基礎(chǔ)組件、框架。

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

虎牙直播的 SRE 實踐

質(zhì)量指標(biāo) SLI

我們來看看直播平臺面對的風(fēng)險和質(zhì)量指標(biāo)，以及我們是怎么樣通過工程手段來提升質(zhì)量的。

直播流媒體技術(shù)中有很多指標(biāo)，內(nèi)部大概有上百個指標(biāo)，常用的也有十幾個，下面是音視頻方面的一些場景：

直播質(zhì)量指標(biāo)

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

卡頓分析

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

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

SLI 卡頓定義

卡頓分為以下四種情況：

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

卡頓率 SLI 定義

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

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

卡頓數(shù)據(jù)

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

卡頓率：卡次數(shù)/用戶數(shù)

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

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

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

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

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

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

全鏈路監(jiān)控

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

這個系統(tǒng)能夠幫助運維人員快速準(zhǔn)確定位到直播流卡頓的現(xiàn)象和原因，也能評估長期總體質(zhì)量。各個環(huán)節(jié)研發(fā)往往對自己的節(jié)點感興趣，由運維對整體負(fù)責(zé)，串起來。

在這里面，整合多環(huán)節(jié)質(zhì)量數(shù)據(jù)，體現(xiàn)了 DevOps 的理念；通過構(gòu)建系統(tǒng)來做，體現(xiàn)了 SRE 的工程化理念；從上報到監(jiān)控，告警、評估閉環(huán)，能力落地到系統(tǒng)，我們不是靠專家，而是解放了專家。

有了全鏈路系統(tǒng)后，我們還做了一個告警和事后問題分析總結(jié)的反饋閉環(huán)。

故障處理和質(zhì)量閉環(huán)

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

從這個監(jiān)控全平臺的卡頓數(shù)據(jù)，我們還可以再挖掘一些數(shù)據(jù)出來，比如每天生成一些卡頓日報，然后自動發(fā)到我們內(nèi)部和廠商兩邊，廠商會自己來做一些回復(fù)、調(diào)查和總結(jié)，最后反饋回給我們。

這樣通過定期 Review CDN 的質(zhì)量，進行定期總結(jié)和評估對比，我們再以此為根據(jù)，看看質(zhì)量調(diào)整和效果的情況。

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

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

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

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

質(zhì)量指標(biāo) SLI/SLO 效果

這是我們把這整個質(zhì)量指標(biāo)串起來之后實現(xiàn)的效果：

案例 1：直播音視頻質(zhì)量

建立了全鏈路的監(jiān)控系統(tǒng)，實現(xiàn)了秒級發(fā)現(xiàn)流級別的卡頓情況，也提升了監(jiān)控的覆蓋率，同時是自動化、實時性、可觀測的。 通過建立質(zhì)量模型，運用卡頓率和穩(wěn)定性可以隨時評估主播、平臺、線路的質(zhì)量，可以Review質(zhì)量。 和 CDN 廠商一起持續(xù)發(fā)現(xiàn)和優(yōu)化質(zhì)量。 把能力推到一線值班。把能力推到一線值班 ，以前運維是沒有音視頻Oncall能力的，只有資深的音視頻研發(fā)工程師可以處理問題，現(xiàn)在一線值班，我們業(yè)務(wù)運維可以當(dāng)做二線，只處理一些更重要的問題。

案例 2：點播成功率

我們在點播項目上也用了質(zhì)量指標(biāo)的方式去做，也實現(xiàn)不錯的效果。目前我們可以實現(xiàn)評估供應(yīng)商，僅保留好用的；推動播放器改進統(tǒng)計，優(yōu)化自動上報；推動服務(wù)端研發(fā)加強故障統(tǒng)計，整個質(zhì)量有了大幅度的提升。

同時我們也可以全平臺評估業(yè)務(wù)質(zhì)量，生成相關(guān)數(shù)據(jù)報告給老板去看，讓他了解到項目目前的質(zhì)量狀況和質(zhì)量變化情況。

虎牙實踐：帶寬調(diào)度

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

為什么要調(diào)度？有兩點原因：

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

調(diào)度方法有如下幾種：

主播調(diào)度 觀眾調(diào)度 靜態(tài)調(diào)度 動態(tài)調(diào)度 無縫切換能力調(diào)度

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

觀眾端也是做了靜態(tài)和動態(tài)的調(diào)度策略，優(yōu)先使用平臺里的線路，它的質(zhì)量會更有所保障的。

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

在這整個過程中，我們運維人員都參與其中，提出我們的需求和目標(biāo)。并跟研發(fā)一起，或者自己開發(fā)其中的某些環(huán)節(jié)，形成一個個工程工作，促使業(yè)務(wù)質(zhì)量大幅提升，并且自己的能力落地到了工程系統(tǒng)中，實現(xiàn)了運維價值的輸出。

SRE 理念的一些實踐

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

以 SRE 的姿勢接維

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

具體來說有如下幾點：

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

運維研發(fā)會議

運維研發(fā)會議，我們試過了，效果很不錯。時間上來說是每周一次，有兩級的領(lǐng)導(dǎo)在場，包括研發(fā)團隊的同學(xué)、具體業(yè)務(wù)研發(fā)的領(lǐng)導(dǎo)和上一級業(yè)務(wù)領(lǐng)導(dǎo)在場。

內(nèi)容有如下幾點：

定期 Review 性能指標(biāo)、容量數(shù)據(jù)、可用性情況等質(zhì)量、趨勢。 緊急的告警 、非緊急的告警。 即將進行的生產(chǎn)環(huán)境變化。 要進行技術(shù)決策的事宜。 運維希望研發(fā)推進的事情、研發(fā)希望運維推進的事情。 技術(shù)工作的同步。 接下來待辦事項及計劃。

事后報告

事后總結(jié)和改進是 SRE 切入深入業(yè)務(wù)的最直接的方式。這是我們的模板：

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

轉(zhuǎn)型 SRE

SRE 與運維的關(guān)系

傳統(tǒng)運維究竟如何轉(zhuǎn)型 SRE 呢？正如我第一部分講到的，在谷歌內(nèi)部，是直接招聘軟件工程師專職做 SRE，跟傳統(tǒng)的業(yè)務(wù)公司不一樣，它是有第三種崗位的。

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

如何轉(zhuǎn)型 SRE

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

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

作者：張觀石

介紹：虎牙直播業(yè)務(wù)運維負(fù)責(zé)人，《運維前線》聯(lián)合作者。擁有多年互聯(lián)網(wǎng)業(yè)務(wù)運維經(jīng)驗。

編輯：陶家龍、孫淑娟

出處：轉(zhuǎn)載自DBAplus社群微信公眾號，本文根據(jù)張觀石老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現(xiàn)場演講內(nèi)容整理而成。