[[142279]]

嘉賓介紹

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

引言

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

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

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

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

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

1. SRE 職責

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

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

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

SRE不負責server的具體實現，SRE主要負責在server出現宕機等緊急事故時，做出快速響應，盡快恢復server，減少服務掉線帶來的損失。

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

2. SRE 要求

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

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

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

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

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

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

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

我們team對所負責的server進行了代碼重構，重構之后，要經過SRE同意，才能夠上線重構后的server。

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

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

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

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

找到兩個方面的原因：

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

• 大量使用hash_map，hash_map沒有預先分配足夠內存空間，造成對底層tc_malloc調用過多。

3. SRE 工作內容

簡而言之，Google的SRE不是做底層硬件維護，而是負責Google各種服務的性能和穩定性。換句話說，Google的SRE保證軟件層面的性能和穩定性，包括軟件基礎構架和應用服務。

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

我列舉一些常見的Google軟件基礎構架的例子：

• Borg：分布式任務管理系統；

• Borgmon：強大的監控報警系統；

• BigTable：分布式Key/Value存儲系統；

• Google File System：分布式文件系統；

• PubSub：分布式消息隊列系統；

• MapReduce：分布式大數據批處理系統；

• F1：分布式數據庫；

• ECatcher：日志收集檢索系統；

• Stubby：Google的RPC實現；

• Proto Buffer：數據序列化存儲協議以及RPC協議；

• Chubby：提供類似Zookeeper的服務。

Google還有更多的軟件基礎構架系統：Megastore、Spanner、Mustang等等，我沒有用過，所以不熟悉。

4. 運維未來發展方向

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

企業客戶有了強大的軟件基礎構架以后，能夠更好應對業務的復雜多變的需求，幫助企業客戶快速發展業務。

另外我個人觀點，為什么Google的產品給人感覺技術含量高？

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

Google內部各種軟件基礎構架，基本上滿足了各種常見分布式功能需求，極大地方便了SWE做業務開發。

換句話說，在Google做開發，SWE基本上是專注業務邏輯，應用服務系統(server)的性能主要由底層軟件基礎構架來保證。

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

下面就是本次分享的互動環節整理（真的非常精彩哦：）。

問題1：SRE參與軟件基礎項目的開發嗎？

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

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

SRE用的大型管理工具應該是專門的團隊開發，比如Borgmon是Google的監控報警工具，很復雜，應該是專門的團隊開發，SRE會大量使用Borgmon。

問題3：基礎軟件架構有可以參考的開源產品嗎？

Google內部常見的軟件基礎構架都有開源對應的版本，比如Zookeeper對應Chubby，HDFS對應Google File System，HBase對應BigTable，Hadoop對應MapReduce，等等。

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

SRE負責Google的數據中心資源分配，所以一些重要server的資源是SRE預留分配好的。對CPU、內存等資源的分配，SRE按照歷史經驗以及server的業務增長預期來制定。

此外Google數據中心里運行的任務有優先級，高優先級的任務會搶占低優先級任務的資源，重要的server一般優先級很高，離線任務優先級比較低，個人開發測試任務優先級最低。

如何一起愉快地發展

高效運維系列微信群是國內高端運維圈子、運維行業垂直社交的典范。現有會員800余名，其中運維總監及以上級別會員300多名。

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

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

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