SRE 是什麼，不是什麼 - GetIt01

SRE，Site Reliability Engineering 的縮寫。

其中site 是指website，可以翻譯為網站可靠性工程。

這個工種是Google 在10 年前創造的，他們剛出了一本講SRE 的書，以下 ... 標籤：SRESiteReliabilityEngineer SRE是什麼，不是什麼 02-02 SRE，SiteReliabilityEngineering的縮寫。

其中site是指website，可以翻譯為網站可靠性工程。

這個工種是Google在10年前創造的，他們剛出了一本講SRE的書，以下簡稱《SRE》。

相應的，做這份工作的人叫SiteReliabilityEngineer——網站可靠性工程師，縮寫也是SRE。

類比：SoftwareEngineering軟體工程，SoftwareEngineer軟體工程師，縮寫SWE。

例句：我在Google的頭兩年是當SRE，現在換成了SWE。

SRE到底是幹什麼的 這基本上是我面試的每個應聘SRE職位的人都會問的問題，三句兩句說不清楚，但願讀完本文之後您能有個大概的了解，也消除一些誤解。

SRE是一個比較新的職位，目前只有少數業界領先的互聯網公司才有這個position（職位），包括Google、Facebook、Twitter、Dropbox、Uber等等，其中後面幾家的SRE部門多是Google離職的SRE參與創建的。

（辨析：前一句的兩個SRE分別是什麼的縮寫？）在Google招聘網站上可以搜到SRE的jobdescription，這裡列出兩個供參考： https://www.google.com/about/careers/search#!t=jo&jid=84745001& https://www.google.com/about/careers/search#!t=jo&jid=86645001& 為了方便讀者，我放一個截屏：Usenix迄今已經舉辦了三次SRE會議（SREcon），從會議網站可以找到具體議程： SREcon14Program|USENIX SREcon15Program SREcon16Program 我估計讀完以上這些材料，大家還是不明白SRE具體是做什麼的。

在遇到新事物的時候，人們習慣用舊事物作類比，「哦，SRE不就是Google給XXX起的名字嘛。

」像番茄、胡椒、洋蔥這些名字就是這麼來的，番茄和茄子區別有多大不用我說吧。

SRE具體工作內容 一說到SoftwareDeveloper，人們腦子裡就能反映出編碼、調試、測試、修bug、刷知乎等具體工作內容。

那SRE呢？SRE的首要工作任務是保證SLA。

SLA是service-levelagreement的縮寫，沒有貼切的中文翻譯，我們繼續用縮寫好了。

SLA一般指的是系統的功能指標，比方說系統可用性（availability）達到99.99%；對於95%的請求，響應延遲（latency）低於200毫秒等等。

《SRE》第4章會具體講SLA、SLO、SLI的含義及用法。

我個人把SRE工作內容分為以下幾個方面： 容量規劃與實施 要回答兩個基本問題：要支持每秒X個請求的流量，需要多少台機器？給你Y台機器，如何部署服務棧（servingstack）使其服務容量（capacity）最大，即每秒支持的請求數最多。

servingstack由很多服務程序（server）構成，各個server有各自的資源需求（每個進程用多少內存，多少CPU）。

每個server有多個replica，我們要算出各個server的replica的合理數目，讓計算資源得到充分利用。

SRE開發了專門的工具來做這件事件，因為我們不想對全球多個數據中心都分別手算一遍。

server的性能會隨時間變化（新版本通常會變慢，因為加了更多的功能），我們要及時調整replica的數目。

每個server的性能變化不一樣，replica的數目要「配平」。

部署新的服務集群（servingcluster） 每年都有新的數據中心（DataCenter）上線，也有舊的數據中心下線，那麼我們的servingstack也會跟著遷移。

「部署」不是去機房安裝機器，實際上工作這麼多年，我一次也沒有見過跑我寫的服務程序的機器。

新的數據中心通常會有新一代的硬體，我們的容量規劃工具要能適應多種的硬體類型（CPU數目、內存大小）。

冗餘與容錯 在Google，我們有數據中心級別的容錯，任何一個數據中心可以隨時下線維護，對外服務不受影響。

進一步說，我們的容量規劃要做到允許兩個數據中心同時下線。

比方說某個數據中心正在例行下線維護，這時另外一個數據中心受突發事件影響必須立刻下線，那麼我們的系統還要能正常提供服務。

負載均衡 《SRE》第19、20章。

上線新的服務（on-boardingservice） 《SRE》第32章。

監控（Monitoring） 不是一天到晚盯著dashboard看，而是編寫合適的監控與報警規則，讓我們能快速找到故障根源。

幾個最基本的監控指標： 流量traffic,eg.queriespersecond 延遲latency 錯誤率errorratio 資源使用率utilization 見《SRE》第6章。

值班（on-call） 這其實是最少的工作，如果一個SRE團隊有8個人，每人每次值班一周，那麼平均2個月才輪到一次，占1/8的工作量。

值班的時候，如果沒有突發事件，還是該幹嘛幹嘛。

而且GoogleSRE是全球團隊，不用值夜班，到了下午把工作交接給地球另一邊的同事就行了。

見《SRE》第11章。

救火（Firefighting） 這是SRE最刺激的工作內容，見《SRE》第12~15章。

SRE不是什麼 SRE不在數據中心上班，不搬機器。

SRE不是系統管理員，不會幫你重置用戶密碼，也不安裝操作系統或升級安全補丁。

SRE不是測試工程師，不管持續集成和發布新版本。

SRE不是運維，不過我其實不了解國內的運維具體是做什麼的。

會繼續補充本文內容…… 推薦閱讀： ※國內程序員怎樣競爭Google總部的工作機會，需要滿足哪些條件？※「開發靠Google，運維靠Baidu」的說法靠譜嗎？※SRE就是程序測試員么？ TAG:SRESiteReliabilityEngineer| 一點新知 GetIt01