引言
SRE是Site Reliability Engineer的簡稱，從名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整個(gè)Google服務(wù)的穩(wěn)定性。SRE不接觸底層硬件如服務(wù)器，這也是高逼格的由來：
Google 數(shù)據(jù)中心的硬件層面的維護(hù)工作是交給technician來做的，technician一般不需要有大學(xué)學(xué)歷。
SWE是SoftWare Egineer的簡稱，即軟件工程師（負(fù)責(zé)軟件服務(wù)的開發(fā)、測(cè)試、發(fā)布）。
SWE更新的程序代碼（下文稱為server），只有在SRE同意后才能上線發(fā)布。因此，SRE在Google工程師團(tuán)隊(duì)中地位非常高！我們下面將分別介紹。
備注：我本人是SWE，本文是從SWE的角度看SRE，我的老朋友@孫宇聰同學(xué)是原Google SRE，他會(huì)從另一個(gè)角度來闡述此主題，敬請(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（軟件開發(fā)工程師），負(fù)責(zé)具體的開發(fā)工作。
舉個(gè)例子，我之前在Google的互聯(lián)網(wǎng)廣告部門，我們team負(fù)責(zé)的server是收集用戶數(shù)據(jù)用于廣告精準(zhǔn)投放，這個(gè)server的開發(fā)、測(cè)試、上線部署等工作，都是由SWE來完成。
SRE不負(fù)責(zé)server的具體實(shí)現(xiàn)，SRE主要負(fù)責(zé)在server出現(xiàn)宕機(jī)等緊急事故時(shí)，做出快速響應(yīng)，盡快恢復(fù)server，減少服務(wù)掉線帶來的損失。
備注：這里的server是指服務(wù)器端程序，而不是物理服務(wù)器。在Google，SWE和SRE都無權(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ù)不能超過一定的頻率，server對(duì)CPU、內(nèi)存的消耗不能超過預(yù)設(shè)的指標(biāo)。
只有server完全滿足SRE的要求以后，SRE才會(huì)接手這個(gè)server：
當(dāng)server出現(xiàn)問題時(shí)，SRE會(huì)先緊急修復(fù)，恢復(fù)服務(wù)，然后SRE會(huì)和SWE溝通，最終SWE來徹底修復(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做一些性能問題排查。
所以SRE在Google地位很高，SWE為了讓server成功上線，都想法跟SRE保持好關(guān)系。
我舉個(gè)具體的例子來說明，在Google，SWE是如何跟SRE配合工作來上線server的。
我們team對(duì)所負(fù)責(zé)的server進(jìn)行了代碼重構(gòu)，重構(gòu)之后，要經(jīng)過SRE同意，才能夠上線重構(gòu)后的server。
為此，我們team的SWE要向SRE證明，重構(gòu)后的server對(duì)資源的開銷沒有增加，即CPU、內(nèi)存、硬盤、帶寬消耗沒有增加，重構(gòu)后的server性能沒有降低，即端到端服務(wù)響應(yīng)延遲、QPS、對(duì)壓力測(cè)試的響應(yīng)等這些性能指標(biāo)沒有降低：
當(dāng)時(shí)對(duì)server代碼重構(gòu)之后，server有個(gè)性能指標(biāo)一直達(dá)不到SRE的要求。這個(gè)指標(biāo)是contention，也就是多線程情況下，對(duì)競爭資源的等待延遲。重構(gòu)server之后，contention這項(xiàng)指標(biāo)變得很高，說明多線程情況下，對(duì)競爭資源的等待變長。
我們排查很久找不到具體原因，因?yàn)镾WE沒有在代碼中顯式使用很多mutex，然后請(qǐng)SRE出面幫忙。
SRE使用Google內(nèi)部的圖形化profiling工具，cpprof，幫我們查找原因。
找到兩個(gè)方面的原因：
tc_malloc在多線程情況下頻繁請(qǐng)求內(nèi)存，造成contention變高；
大量使用hash_map，hash_map沒有預(yù)先分配足夠內(nèi)存空間，造成對(duì)底層tc_malloc調(diào)用過多。
3. SRE 工作內(nèi)容
簡而言之，Google的SRE不是做底層硬件維護(hù)，而是負(fù)責(zé)Google各種服務(wù)的性能和穩(wěn)定性。換句話說，Google的SRE保證軟件層面的性能和穩(wěn)定性，包括軟件基礎(chǔ)構(gòu)架和應(yīng)用服務(wù)。
SRE需要對(duì)Google內(nèi)部各種軟件基礎(chǔ)構(gòu)架(Infrastructure)非常了解，而且SRE一般具有很強(qiáng)的排查問題、debug、快速恢復(fù)server的能力。
我列舉一些常見的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ù)庫；
ECatcher：日志收集檢索系統(tǒng)；
Stubby：Google的RPC實(shí)現(xiàn)；
Proto Buffer：數(shù)據(jù)序列化存儲(chǔ)協(xié)議以及RPC協(xié)議；
Chubby：提供類似Zookeeper的服務(wù)。
Google還有更多的軟件基礎(chǔ)構(gòu)架系統(tǒng)：Megastore、Spanner、Mustang等等，我沒有用過，所以不熟悉。
4. 運(yùn)維未來發(fā)展方向
我個(gè)人覺得，在云計(jì)算時(shí)代，運(yùn)維工程師會(huì)慢慢向Google的SRE這種角色發(fā)展，遠(yuǎn)離底層硬件，更多靠近軟件基礎(chǔ)架構(gòu)層面，幫助企業(yè)客戶打造強(qiáng)大的軟件基礎(chǔ)構(gòu)架。
企業(yè)客戶有了強(qiáng)大的軟件基礎(chǔ)構(gòu)架以后，能夠更好應(yīng)對(duì)業(yè)務(wù)的復(fù)雜多變的需求，幫助企業(yè)客戶快速發(fā)展業(yè)務(wù)。
另外我個(gè)人觀點(diǎn)，為什么Google的產(chǎn)品給人感覺技術(shù)含量高？
并不見得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程師能力強(qiáng)多少，主要是因?yàn)镚oogle的軟件基礎(chǔ)構(gòu)架(詳見上文）非常強(qiáng)大，有了很強(qiáng)大的基礎(chǔ)構(gòu)架，再做出強(qiáng)大的產(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)架來保證。
————我是分割線————
下面就是本次分享的互動(dòng)環(huán)節(jié)整理：
問題1：SRE參與軟件基礎(chǔ)項(xiàng)目的開發(fā)嗎？
SRE一般不做開發(fā)。比如Google的BigTable有專門的開發(fā)團(tuán)隊(duì)，也有專門的SRE團(tuán)隊(duì)保障BigTable server的性能和穩(wěn)定性。
問題2：一般運(yùn)維工具，或者監(jiān)控，告警工具，哪個(gè)團(tuán)隊(duì)開發(fā)？
SRE用的大型管理工具應(yīng)該是專門的團(tuán)隊(duì)開發(fā)，比如Borgmon是Google的監(jiān)控報(bào)警工具，很復(fù)雜，應(yīng)該是專門的團(tuán)隊(duì)開發(fā)，SRE會(huì)大量使用Borgmon。
問題3：基礎(chǔ)軟件架構(gòu)有可以參考的開源產(chǎn)品嗎？
Google內(nèi)部常見的軟件基礎(chǔ)構(gòu)架都有開源對(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，等等。
問題4：還有SRE會(huì)約束一些項(xiàng)目的性能指標(biāo)，比如CPU和內(nèi)存的使用閾值，這些值是從哪里得來的？或者說根據(jù)哪些規(guī)則來定制的？
SRE負(fù)責(zé)Google的數(shù)據(jù)中心資源分配，所以一些重要server的資源是SRE預(yù)留分配好的。對(duì)CPU、內(nèi)存等資源的分配，SRE按照歷史經(jīng)驗(yàn)以及server的業(yè)務(wù)增長預(yù)期來制定。
此外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è)人開發(fā)測(cè)試任務(wù)優(yōu)先級(jí)最低。
京公網(wǎng)安備 11010502049343號(hào)