Google儲存SRE團隊負責人第一手經驗大公開

突然發現Gmail用戶能看到他人信件內容，若你是Gmail維運人員，會怎麼做？通知團隊負責人？立刻打電話詢問公司副總裁？訂披薩準備找問題？還是立刻關掉這個全球10億人使用的郵件服務？Google儲存服務SRE部門總監Melissa Binde說：「正確答案是立刻關掉Gmail。」

在Google負責服務維運工作的這類工程師通通稱為SRE（Site Reliability Engineer，網站可靠性工程師），Melissa Binde表示，不論擔任SRE這類職務的人是實習生，或是剛拿到第一份薪水的新進，只要為了保護Google，SRE維運人員「可以做任何決定的權力，甚至必須關閉整個Google.com網站，公司高層都會支持。」她說，這句話反映出Google對SRE一職的重視和倚賴。

Melissa Binde率領的儲存SRE團隊，負責維運Google雲端平臺中與儲存相關的服務，例如GCS、Bigtable服務、SQL服務等，也包括了Google內部使用的Bigtable、分散式高擴充檔案系統Colossus等多項Google全球性分散式儲存系統。換句話說，SRE團隊正是維持Google每天正常提供各項服務的幕後功臣。

SRE團隊需支援Google全球的雲端業務

但究竟Google所創立的SRE是個什麼樣的職務？Melissa Binde解釋，其實SRE就像是近來火熱的DevOps，但兩者仍然略有不同。

DevOps工程師是為了解決開發團隊和維運團隊的矛盾而出現的新角色，不過，目前各界對DevOps內涵仍眾說紛紜，出現了各式各樣的詮釋或定義，而Melissa Binde表示：「對Google來說，SRE就是由軟體工程師來負責維運工作的設計和執行。」

由熟悉軟體的軟體工程師來負責系統維運，更能掌握軟體、系統間的交互運作關係，更重要的是，Google的SRE團隊，不是照本宣科地執行維運，更要同時負責「設計和優化維運工作。」

Google賦予SRE團隊三大工作目標，包括了確保正式環境的可靠性、水平擴展性及效能表現。為了實現這些目標，SRE得想辦法讓負責系統的運作更自動化與視覺化，也得打造儀表板以時時監控這些系統的效能表現。例如SRE可以更換Google服務底層的資料庫，來改善服務的延遲，或開發許多自動化程式加速系統部署，或是設計軟體機器人（Software robot），來進行跨系統資料傳遞、自動關閉特定機器，甚至是關閉整座資料中心。Google的SRE團隊不會集中在一處，Google全球各地據點都有分配SRE團隊，來支援雲端業務。

找出合適人才，是Google建立SRE團隊的第一步

如何打造出這樣的SRE團隊？Melissa Binde透露，有4件事很重要。

第一是人員組成。她說，所有SRE成員，人人都得通過軟體面試才能加入，尤其必須通過非抽象大型系統（Non-abstract large system）設計的測驗，甚至「SRE要比開發人員還更了解開發。」

擅長開發的SRE參與維運機制的設計後，更能改善維運工作，舉例來說，許多軟體在開發階段常有些過於理想的假設，像是系統呼叫必定不會失敗，但是一旦在正式環境中大規模部署時則幾乎是一定會發生系統呼叫失敗的情況，後者就是SRE要負責解決的問題。

分配固定開發團隊配額給SRE團隊

第二是組織層級。為了讓開發團隊也能對SRE有貢獻，當開發團隊打造出來的服務大受歡迎，導致維運工作超量時， Google的開發團隊可以將自己的人力配額（Headcount）貢獻給SRE團隊，讓SRE團隊可以招募更多人力，來確保服務維運的品質，才能讓開發團隊繼續推出更多新功能。不過，SRE也有權拒絕這樣的配額轉移。

不過，SRE團隊的直屬主管必須和開發團隊分開，SRE團隊的直屬副總和開發團隊直屬副總是兩個人，如此一來，「當線上環境還未備妥前，SRE團隊也能有權拒絕開發團隊的要求。」Melissa Binde表示，因為「SRE不是群隨傳隨到的猴子。」

減少維運人員雜事干擾，專注於手上專案任務

第三是好的工作環境。為了避免SRE受到雜事干擾，Melissa Binde表示，必須讓SRE過半數時間能專注於負責的專案工作，減少SRE受到會議、工單、待命任務等工作的干擾。如果SRE團隊手中有太多的專案要處理，除了可以請求開發團隊提供更多配額外，也可以將手上專案轉給開發團隊接手。

另外，Google也採取12小時的待命（On-Call）輪班制度，而非更長的18小時或24小時待命制度。

另一方面，儘管SRE團隊成員的加入頗有難度，也需經過主管同意，但所有SRE成員都是自願加入而非受指派而成為SRE，SRE團隊成員如果厭倦了從事維運工作，也可隨時轉入開發團隊。正因此，「SRE團隊也一直處在人來人往的狀態，隨時會有新成員加入，舊成員離開。」Melissa Binde表示，這些新血也能帶給SRE團隊新的思維。

守住系統高可靠性，開發團隊也能盡情推新功能

Dev和Ops常見的衝突是，開發團隊想盡可能嘗試新功能，但Ops擔心新功能影響既有服務的穩定性而力阻，雙方經常各執一詞而爭執不下。Melissa Binde表示：「我們用數學來解決這個問題。」Google明確地建立了一個可以兼顧推新功能和服務穩定性的規則，稱為「犯錯預算」（error budget）的概念。

Melissa Binde舉例，若某項服務承諾的SLA可用性是99.9%，那麼開發團隊就等於擁有0.1％的嘗試錯誤空間，「這個0.1％就是開發團隊在這項服務上可用的犯錯預算。」只要整體影響服務中斷的時間沒有超過0.1％，開發團隊可以盡情嘗試新功能。當然，「若開發團隊在開發過程常常失敗，得不斷重啟服務，也會更快地用光這個預算。」Melissa Binde說。

不過，犯錯預算用完了，Google仍提供開發團隊一個緩衝機制，稱為銀色子彈（Silver Bullet）。如果開發團隊耗盡了錯誤預算，但非常希望推出某項新功能，則可以使用銀色子彈來說服VP，放手讓開發團隊進行。Melissa Binde笑說，雖然這樣的儀式看起來很笨，「但其實威力強大。」

出錯後撰寫事後報告，避免錯誤一再重複

明確界定出開發團隊可犯錯的空間，讓開發與維運的爭執點有法可循之外，Google也非常重視出錯後的事後檢討，但不是為了究責，而是為了避免錯誤再度發生。例如若有新人上傳的程式碼導致一項服務中斷時，Melissa Binde認為，更應該檢討的是開發流程的程式碼審核（code review）、測試及快速回復（rollback）工具的問題。她解釋，這些程序應該要有能力阻止開發者上傳錯誤的程式碼，不該讓人為疏失蔓延到正式環境中。

而Google也會要求開發者在事後檢討報告中，除了詳細交待事故原因，更必須提出預防方法，以及發生類似事件時該如何緩和來降低受影響人數的對策。

Melissa Binde表示，這樣的思維正是Google企業文化中的不究責事後檢討（blameless post mortems）。她認為，解決意外最好的方式，就是了解事情始末，如果隨便找人背黑鍋，只會讓情況越來越惡化。

Google SRE團隊維運心法大全  Google網頁可靠性團隊儲存部門總監Melissa Binde同時也大力推薦這本由Google SRE團隊撰寫的SRE心法大全，裡面匯聚70名SRE團隊成員，總共累積500工作年的一手維運經驗，分享他們如何幫助Google更快完成部署、建置程序，「我對這本厚到不行的書，感到相當興奮。」