[[142279]]

嘉賓介紹

王璞，數(shù)人科技創(chuàng)始人。2002年獲得北京航空航天大學(xué)力學(xué)學(xué)士學(xué)位，2007年獲得北京大學(xué)計(jì)算機(jī)碩士學(xué)位，2011年獲得美國(guó)George Mason University計(jì)算機(jī)博士學(xué)位，研究方向機(jī)器學(xué)習(xí)，發(fā)表十余篇機(jī)器學(xué)習(xí)以及數(shù)據(jù)挖掘相關(guān)論文。畢業(yè)后在硅谷先后供職StumbleUpon、Groupon和Google三家公司，負(fù)責(zé)海量數(shù)據(jù)處理、分布式計(jì)算以及大規(guī)模機(jī)器學(xué)習(xí)相關(guān)工作。2014年回國(guó)創(chuàng)辦數(shù)人科技，基于Mesos和Docker構(gòu)建分布式計(jì)算平臺(tái)，為企業(yè)客戶(hù)提供高性能分布式PaaS解決方案。

引言

SRE是Site Reliability Engineer的簡(jiǎn)稱(chēng)，從名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整個(gè)Google服務(wù)的穩(wěn)定性。SRE不接觸底層硬件如服務(wù)器，這也是高逼格的由來(lái)：

Google 數(shù)據(jù)中心的硬件層面的維護(hù)工作是交給technician來(lái)做的，technician一般不需要有大學(xué)學(xué)歷。

SWE是SoftWare Egineer的簡(jiǎn)稱(chēng)，即軟件工程師（負(fù)責(zé)軟件服務(wù)的開(kāi)發(fā)、測(cè)試、發(fā)布）。

SWE更新的程序代碼（下文稱(chēng)為server），只有在SRE同意后才能上線發(fā)布。因此，SRE在Google工程師團(tuán)隊(duì)中地位非常高！我們下面將分別介紹。

備注：我本人是SWE，本文是從SWE的角度看SRE，我的老朋友@孫宇聰同學(xué)是原Google SRE，他會(huì)從另一個(gè)角度來(lái)闡述此主題，敬請(qǐng)期待哦！

1. SRE 職責(zé)

SRE在Google不負(fù)責(zé)某個(gè)服務(wù)的上線、部署，SRE主要是保障服務(wù)的可靠性和性能，同時(shí)負(fù)責(zé)數(shù)據(jù)中心資源分配，為重要服務(wù)預(yù)留資源。

如上文所受，和SRE想對(duì)應(yīng)的是SWE（軟件開(kāi)發(fā)工程師），負(fù)責(zé)具體的開(kāi)發(fā)工作。

舉個(gè)例子，我之前在Google的互聯(lián)網(wǎng)廣告部門(mén)，我們team負(fù)責(zé)的server是收集用戶(hù)數(shù)據(jù)用于廣告精準(zhǔn)投放，這個(gè)server的開(kāi)發(fā)、測(cè)試、上線部署等工作，都是由SWE來(lái)完成。

SRE不負(fù)責(zé)server的具體實(shí)現(xiàn)，SRE主要負(fù)責(zé)在server出現(xiàn)宕機(jī)等緊急事故時(shí)，做出快速響應(yīng)，盡快恢復(fù)server，減少服務(wù)掉線帶來(lái)的損失。

備注：這里的server是指服務(wù)器端程序，而不是物理服務(wù)器。在Google，SWE和SRE都無(wú)權(quán)接觸物理服務(wù)器。

2. SRE 要求

因?yàn)镾RE的職責(zé)是保障服務(wù)的穩(wěn)定和性能，所以在SRE接手某個(gè)server之前，對(duì)server的性能和穩(wěn)定性都有一定的要求，比如server出現(xiàn)報(bào)警的次數(shù)不能超過(guò)一定的頻率，server對(duì)CPU、內(nèi)存的消耗不能超過(guò)預(yù)設(shè)的指標(biāo)。

只有server完全滿(mǎn)足SRE的要求以后，SRE才會(huì)接手這個(gè)server：

當(dāng)server出現(xiàn)問(wèn)題時(shí)，SRE會(huì)先緊急修復(fù)，恢復(fù)服務(wù)，然后SRE會(huì)和SWE溝通，最終SWE來(lái)徹底修復(fù)server的bug。

同時(shí)，對(duì)server的重大更新，SWE都要提前通知SRE，做好各種準(zhǔn)備工作，才能發(fā)布新版server：

為了能讓SRE能接手server，SWE要根據(jù)SRE的要求，對(duì)server做大量的調(diào)優(yōu)。首先SRE會(huì)給出各種性能指標(biāo)，比如，服務(wù)響應(yīng)延遲、資源使用量等等，再者SRE會(huì)要求SWE給出一些server評(píng)測(cè)結(jié)果，諸如壓力測(cè)試結(jié)果、端到端測(cè)試結(jié)果等等，同時(shí)，SRE也會(huì)幫助SWE做一些性能問(wèn)題排查。

所以SRE在Google地位很高，SWE為了讓server成功上線，都想法跟SRE保持好關(guān)系。

我舉個(gè)具體的例子來(lái)說(shuō)明，在Google，SWE是如何跟SRE配合工作來(lái)上線server的。

我們team對(duì)所負(fù)責(zé)的server進(jìn)行了代碼重構(gòu)，重構(gòu)之后，要經(jīng)過(guò)SRE同意，才能夠上線重構(gòu)后的server。

為此，我們team的SWE要向SRE證明，重構(gòu)后的server對(duì)資源的開(kāi)銷(xiāo)沒(méi)有增加，即CPU、內(nèi)存、硬盤(pán)、帶寬消耗沒(méi)有增加，重構(gòu)后的server性能沒(méi)有降低，即端到端服務(wù)響應(yīng)延遲、QPS、對(duì)壓力測(cè)試的響應(yīng)等這些性能指標(biāo)沒(méi)有降低：

當(dāng)時(shí)對(duì)server代碼重構(gòu)之后，server有個(gè)性能指標(biāo)一直達(dá)不到SRE的要求。這個(gè)指標(biāo)是contention，也就是多線程情況下，對(duì)競(jìng)爭(zhēng)資源的等待延遲。重構(gòu)server之后，contention這項(xiàng)指標(biāo)變得很高，說(shuō)明多線程情況下，對(duì)競(jìng)爭(zhēng)資源的等待變長(zhǎng)。

我們排查很久找不到具體原因，因?yàn)镾WE沒(méi)有在代碼中顯式使用很多mutex，然后請(qǐng)SRE出面幫忙。

SRE使用Google內(nèi)部的圖形化profiling工具，cpprof，幫我們查找原因。

找到兩個(gè)方面的原因：

• tc_malloc在多線程情況下頻繁請(qǐng)求內(nèi)存，造成contention變高；

• 大量使用hash_map，hash_map沒(méi)有預(yù)先分配足夠內(nèi)存空間，造成對(duì)底層tc_malloc調(diào)用過(guò)多。

3. SRE 工作內(nèi)容

簡(jiǎn)而言之，Google的SRE不是做底層硬件維護(hù)，而是負(fù)責(zé)Google各種服務(wù)的性能和穩(wěn)定性。換句話(huà)說(shuō)，Google的SRE保證軟件層面的性能和穩(wěn)定性，包括軟件基礎(chǔ)構(gòu)架和應(yīng)用服務(wù)。

SRE需要對(duì)Google內(nèi)部各種軟件基礎(chǔ)構(gòu)架(Infrastructure)非常了解，而且SRE一般具有很強(qiáng)的排查問(wèn)題、debug、快速恢復(fù)server的能力。

我列舉一些常見(jiàn)的Google軟件基礎(chǔ)構(gòu)架的例子：

• Borg：分布式任務(wù)管理系統(tǒng)；

• Borgmon：強(qiáng)大的監(jiān)控報(bào)警系統(tǒng)；

• BigTable：分布式Key/Value存儲(chǔ)系統(tǒng)；

• Google File System：分布式文件系統(tǒng)；

• PubSub：分布式消息隊(duì)列系統(tǒng)；

• MapReduce：分布式大數(shù)據(jù)批處理系統(tǒng)；

• F1：分布式數(shù)據(jù)庫(kù)；

• ECatcher：日志收集檢索系統(tǒng)；

• Stubby：Google的RPC實(shí)現(xiàn)；

• Proto Buffer：數(shù)據(jù)序列化存儲(chǔ)協(xié)議以及RPC協(xié)議；

• Chubby：提供類(lèi)似Zookeeper的服務(wù)。

Google還有更多的軟件基礎(chǔ)構(gòu)架系統(tǒng)：Megastore、Spanner、Mustang等等，我沒(méi)有用過(guò)，所以不熟悉。

4. 運(yùn)維未來(lái)發(fā)展方向

我個(gè)人覺(jué)得，在云計(jì)算時(shí)代，運(yùn)維工程師會(huì)慢慢向Google的SRE這種角色發(fā)展，遠(yuǎn)離底層硬件，更多靠近軟件基礎(chǔ)架構(gòu)層面，幫助企業(yè)客戶(hù)打造強(qiáng)大的軟件基礎(chǔ)構(gòu)架。

企業(yè)客戶(hù)有了強(qiáng)大的軟件基礎(chǔ)構(gòu)架以后，能夠更好應(yīng)對(duì)業(yè)務(wù)的復(fù)雜多變的需求，幫助企業(yè)客戶(hù)快速發(fā)展業(yè)務(wù)。

另外我個(gè)人觀點(diǎn)，為什么Google的產(chǎn)品給人感覺(jué)技術(shù)含量高？

并不見(jiàn)得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程師能力強(qiáng)多少，主要是因?yàn)?strong>Google的軟件基礎(chǔ)構(gòu)架(詳見(jiàn)上文）非常強(qiáng)大，有了很強(qiáng)大的基礎(chǔ)構(gòu)架，再做出強(qiáng)大的產(chǎn)品就很方便了。

Google內(nèi)部各種軟件基礎(chǔ)構(gòu)架，基本上滿(mǎn)足了各種常見(jiàn)分布式功能需求，極大地方便了SWE做業(yè)務(wù)開(kāi)發(fā)。

換句話(huà)說(shuō)，在Google做開(kāi)發(fā)，SWE基本上是專(zhuān)注業(yè)務(wù)邏輯，應(yīng)用服務(wù)系統(tǒng)(server)的性能主要由底層軟件基礎(chǔ)構(gòu)架來(lái)保證。

————我是分割線————

下面就是本次分享的互動(dòng)環(huán)節(jié)整理（真的非常精彩哦：）。

問(wèn)題1：SRE參與軟件基礎(chǔ)項(xiàng)目的開(kāi)發(fā)嗎？

SRE一般不做開(kāi)發(fā)。比如Google的BigTable有專(zhuān)門(mén)的開(kāi)發(fā)團(tuán)隊(duì)，也有專(zhuān)門(mén)的SRE團(tuán)隊(duì)保障BigTable server的性能和穩(wěn)定性。

問(wèn)題2：一般運(yùn)維工具，或者監(jiān)控，告警工具，哪個(gè)團(tuán)隊(duì)開(kāi)發(fā)？

SRE用的大型管理工具應(yīng)該是專(zhuān)門(mén)的團(tuán)隊(duì)開(kāi)發(fā)，比如Borgmon是Google的監(jiān)控報(bào)警工具，很復(fù)雜，應(yīng)該是專(zhuān)門(mén)的團(tuán)隊(duì)開(kāi)發(fā)，SRE會(huì)大量使用Borgmon。

問(wèn)題3：基礎(chǔ)軟件架構(gòu)有可以參考的開(kāi)源產(chǎn)品嗎？

Google內(nèi)部常見(jiàn)的軟件基礎(chǔ)構(gòu)架都有開(kāi)源對(duì)應(yīng)的版本，比如Zookeeper對(duì)應(yīng)Chubby，HDFS對(duì)應(yīng)Google File System，HBase對(duì)應(yīng)BigTable，Hadoop對(duì)應(yīng)MapReduce，等等。

問(wèn)題4：還有SRE會(huì)約束一些項(xiàng)目的性能指標(biāo)，比如CPU和內(nèi)存的使用閾值，這些值是從哪里得來(lái)的？或者說(shuō)根據(jù)哪些規(guī)則來(lái)定制的？

SRE負(fù)責(zé)Google的數(shù)據(jù)中心資源分配，所以一些重要server的資源是SRE預(yù)留分配好的。對(duì)CPU、內(nèi)存等資源的分配，SRE按照歷史經(jīng)驗(yàn)以及server的業(yè)務(wù)增長(zhǎng)預(yù)期來(lái)制定。

此外Google數(shù)據(jù)中心里運(yùn)行的任務(wù)有優(yōu)先級(jí)，高優(yōu)先級(jí)的任務(wù)會(huì)搶占低優(yōu)先級(jí)任務(wù)的資源，重要的server一般優(yōu)先級(jí)很高，離線任務(wù)優(yōu)先級(jí)比較低，個(gè)人開(kāi)發(fā)測(cè)試任務(wù)優(yōu)先級(jí)最低。

如何一起愉快地發(fā)展

高效運(yùn)維系列微信群是國(guó)內(nèi)高端運(yùn)維圈子、運(yùn)維行業(yè)垂直社交的典范?，F(xiàn)有會(huì)員800余名，其中運(yùn)維總監(jiān)及以上級(jí)別會(huì)員300多名。

“高效運(yùn)維”公眾號(hào)值得您的關(guān)注，作為高效運(yùn)維系列微信群的唯一官方公眾號(hào)，每周發(fā)表多篇干貨滿(mǎn)滿(mǎn)的原創(chuàng)好文：來(lái)自于系列群的討論精華、運(yùn)維講壇線上/線下活動(dòng)精彩分享及部分群友原創(chuàng)。“高效運(yùn)維”也是互聯(lián)網(wǎng)專(zhuān)欄《高效運(yùn)維最佳實(shí)踐》及運(yùn)維2.0官方公眾號(hào)。

提示：目前高效運(yùn)維兩個(gè)微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國(guó)個(gè)人微信號(hào) xiaotianguo 為好友，進(jìn)行申請(qǐng)；或申請(qǐng)加入我們技術(shù)交流群（技術(shù)討論為主，沒(méi)有主群那么多規(guī)矩，更熱鬧）。

重要提示：除非事先獲得授權(quán)，請(qǐng)?jiān)诒竟娞?hào)發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識(shí)，請(qǐng)必須全文轉(zhuǎn)載，并包括本行及如下二維碼。