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

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

對(duì)運(yùn)維的三個(gè)思考

傳統(tǒng)運(yùn)維窘境

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

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

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

運(yùn)維技術(shù)深度和價(jià)值

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

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

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

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

DevOps 和 SRE 的關(guān)系

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

SRE 對(duì)我們***收益是提供了一種方法論體系，來(lái)指導(dǎo)我們運(yùn)維工作，也提供了一些具體的實(shí)踐來(lái)供我們參考。

今天想簡(jiǎn)單跟大家分享下我們?cè)谶\(yùn)維上跟 SRE 比較類似的經(jīng)驗(yàn)。

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

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

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

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

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

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

***觀眾通過(guò)各種用戶端連接到這些邊緣節(jié)點(diǎn)的音視頻流，觀眾可能是并發(fā)***的。

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

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

對(duì) YY 來(lái)說(shuō)，在開(kāi)始做直播的時(shí)候，還是有一定的技術(shù)開(kāi)創(chuàng)性。但在這方面，我們運(yùn)維的挑戰(zhàn)比較大。看到下面主播到觀眾遍布的這張架構(gòu)圖：

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

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

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

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

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

關(guān)于 SRE 理念

SRE 回顧

SRE 是由三個(gè)單詞組成的，我先簡(jiǎn)單解釋一下：

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

我個(gè)人更認(rèn)同 E 是工程和工程化，比如我們不叫 SRE 崗位，但做的事情是提升業(yè)務(wù)可靠性的“工程”，甚至事情不是我們單獨(dú)在做，而是和業(yè)務(wù)研發(fā)聯(lián)合來(lái)做。

• 第二個(gè) R。Reliability，意思是可靠性，表達(dá)在業(yè)務(wù)上、工程上就是質(zhì)量，理解為對(duì)外部最終用戶的質(zhì)量和價(jià)值。
• 第三個(gè) S。Site/Service，即運(yùn)維對(duì)象、網(wǎng)站服務(wù)、業(yè)務(wù)服務(wù)和線上的各種服務(wù)。

SRE 理念

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

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

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

SRE 給出的答案是：

***，擁抱風(fēng)險(xiǎn)。并且把風(fēng)險(xiǎn)識(shí)別出來(lái)，用 SLI/SLO 加以評(píng)估、度量、量化出來(lái)，最終達(dá)到消除風(fēng)險(xiǎn)的目的。

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

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

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

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

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

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

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

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

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

虎牙直播的 SRE 實(shí)踐

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

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

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

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

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

卡頓分析

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

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

SLI 卡頓定義

卡頓分為以下四種情況：

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

卡頓率 SLI 定義

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

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

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

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

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

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

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

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

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

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

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

全鏈路監(jiān)控

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

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

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

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

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

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

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

這樣通過(guò)定期 Review CDN 的質(zhì)量，進(jìn)行定期總結(jié)和評(píng)估對(duì)比，我們?cè)僖源藶楦鶕?jù)，看看質(zhì)量調(diào)整和效果的情況。

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

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

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

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

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

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

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

建立了全鏈路的監(jiān)控系統(tǒng)，實(shí)現(xiàn)了秒級(jí)發(fā)現(xiàn)流級(jí)別的卡頓情況，也提升了監(jiān)控的覆蓋率，同時(shí)是自動(dòng)化、實(shí)時(shí)性、可觀測(cè)的。

通過(guò)建立質(zhì)量模型，運(yùn)用卡頓率和穩(wěn)定性可以隨時(shí)評(píng)估主播、平臺(tái)、線路的質(zhì)量，可以Review質(zhì)量。

和 CDN 廠商一起持續(xù)發(fā)現(xiàn)和優(yōu)化質(zhì)量。

把能力推到一線值班。把能力推到一線值班 ，以前運(yùn)維是沒(méi)有音視頻Oncall能力的，只有資深的音視頻研發(fā)工程師可以處理問(wèn)題，現(xiàn)在一線值班，我們業(yè)務(wù)運(yùn)維可以當(dāng)做二線，只處理一些更重要的問(wèn)題。

案例 2：點(diǎn)播成功率

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

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

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

接下來(lái)介紹虎牙帶寬調(diào)度的一個(gè)實(shí)踐，會(huì)從調(diào)度的原因、方法和評(píng)估三方面進(jìn)行介紹。

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

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

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

• 主播調(diào)度
• 觀眾調(diào)度
• 靜態(tài)調(diào)度
• 動(dòng)態(tài)調(diào)度
• 無(wú)縫切換能力調(diào)度

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

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

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

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

SRE 理念的一些實(shí)踐

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

以 SRE 的姿勢(shì)接維

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

具體來(lái)說(shuō)有如下幾點(diǎn)：

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

運(yùn)維研發(fā)會(huì)議

運(yùn)維研發(fā)會(huì)議，我們?cè)囘^(guò)了，效果很不錯(cuò)。時(shí)間上來(lái)說(shuō)是每周一次，有兩級(jí)的領(lǐng)導(dǎo)在場(chǎng)，包括研發(fā)團(tuán)隊(duì)的同學(xué)、具體業(yè)務(wù)研發(fā)的領(lǐng)導(dǎo)和上一級(jí)業(yè)務(wù)領(lǐng)導(dǎo)在場(chǎng)。

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

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

事后報(bào)告

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

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

轉(zhuǎn)型 SRE

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

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

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

如何轉(zhuǎn)型 SRE

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

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