[[142279]]

嘉賓介紹

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

引言

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

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

SWE是SoftWare Egineer的簡稱，即軟件工程師（負責軟件服務(wù)的開發(fā)、測試、發(fā)布）。

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

備注：我本人是SWE，本文是從SWE的角度看SRE，我的老朋友@孫宇聰同學是原Google SRE，他會從另一個角度來闡述此主題，敬請期待哦！

1. SRE 職責

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

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

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

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

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

2. SRE 要求

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

只有server完全滿足SRE的要求以后，SRE才會接手這個server：

當server出現(xiàn)問題時，SRE會先緊急修復(fù)，恢復(fù)服務(wù)，然后SRE會和SWE溝通，最終SWE來徹底修復(fù)server的bug。

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

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

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

我舉個具體的例子來說明，在Google，SWE是如何跟SRE配合工作來上線server的。

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

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

當時對server代碼重構(gòu)之后，server有個性能指標一直達不到SRE的要求。這個指標是contention，也就是多線程情況下，對競爭資源的等待延遲。重構(gòu)server之后，contention這項指標變得很高，說明多線程情況下，對競爭資源的等待變長。

我們排查很久找不到具體原因，因為SWE沒有在代碼中顯式使用很多mutex，然后請SRE出面幫忙。

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

找到兩個方面的原因：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 運維未來發(fā)展方向

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

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

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

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

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

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

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

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

問題1：SRE參與軟件基礎(chǔ)項目的開發(fā)嗎？

SRE一般不做開發(fā)。比如Google的BigTable有專門的開發(fā)團隊，也有專門的SRE團隊保障BigTable server的性能和穩(wěn)定性。

問題2：一般運維工具，或者監(jiān)控，告警工具，哪個團隊開發(fā)？

SRE用的大型管理工具應(yīng)該是專門的團隊開發(fā)，比如Borgmon是Google的監(jiān)控報警工具，很復(fù)雜，應(yīng)該是專門的團隊開發(fā)，SRE會大量使用Borgmon。

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

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

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

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

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

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

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

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

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

重要提示：除非事先獲得授權(quán)，請在本公眾號發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識，請必須全文轉(zhuǎn)載，并包括本行及如下二維碼。