引言數據庫
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主要是保障服務的可靠性和性能，同時負責數據中心資源分配，爲重要服務預留資源。oop
如上文所受，和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通常優先級很高，離線任務優先級比較低，我的開發測試任務優先級最低。