Site Reliability Engineering (SRE, 網站可靠性工程)


SRE 全名是 Site Reliability Engineering 網站可靠性工程,是 Google 提倡的系統管理實踐之道、指導思想,這個名詞同時也是 軟體工程師 (Software Engineer) 的角色,可以類比於傳統的維運工程師或系統工程師,但是 SRE 是用 計算機科學軟體工程 手段,實踐 大型系統維運分散式系統 的設計與開發。

Updated 2023/07/19: 個人著作 《SRE 實踐與開發平台指南》 於 2023/08 上市,內容整理個人過去數年實踐的經驗與總結。


推薦閱讀

這本書我個人分成以下幾個部分,讀者可以依據個人身份、角色、經驗,選擇有興趣的部分:

  • 一、指導原則:這段是描述 SRE 時會提到的關鍵原則
  • 二、事件管理:該如何面對異常事件、管理、從失敗中學習
  • 三、工程實踐:用軟體工程來看待系統維運
  • 四、管理與訓練:管理者如何在團隊中實踐 SRE 的精神。
  • 五、箴言:書本有很多讓人省思的箴言,值得深思

一、指導原則

這本書 Part 2 談 SRE 的指導原則,也是大部分在描述 SRE 的文章、或者職缺描述 (Job Description, JD) 時,一定會有的原則,這些原則包含了:

  • 擁抱風險、錯誤預算 (Error Budget):重點在於激勵團隊共同承擔責任,從錯誤中學習,這點跟 DevOps 精神是一致的。
  • 服務水準目標:討論 SLIs, SLOs, SLAs 等概念
  • 減少瑣事:用 50% 的時間,開發自動化維運工作
  • 監控分散式系統
  • 自動化、簡單化:自動化可能的問題以及其必要性
  • 發行工程 (Release Engineering):可以說是對應到 持續交付 (Continuous Delivery) 的概念
  • 軟體工程實踐維運工作:這也是 SRE 跟一般維運工程師、系統工程師不一樣,重點在於 Ops as Code 的概念

這段是認識 SRE 想法的入門心法,要如何讓團隊理解 SRE,這些章節提供了很多指導原則。

二、事件管理

書本 Part 3 具體實踐 針對 事件管理 有很多著墨,我以時間點來看整理事件的 ,團隊應該做什麼?下圖是我整理的想法,也是 SRE 書中提到的概念:

詳細參閱:演講:從緊急事件 談 SRE 應變能力的培養:我在 DevOpsDays Taipei 2018 分享的心得

書本章節先後次序剛好是時間軸次序,整理如下:

異常事件處理非常仰賴紮實的軟體工程、團隊協作能力、應變管理,在各種領域都有類似的案例。特別用了其他領域的經驗,整理了類似的想法給大家參考:

如果你的時間有限、如果你不是技術背景,那麼推薦閱讀這些章節!會讓你有醍醐灌頂的感覺!

三、工程實踐

SRE 很強調用 計算機科學軟體工程 實踐維運工作。書裡 Part 3 具體實踐有一半的章節都在談論這些屬於硬技能的工程實踐,特別是 分散式系統 (Distributed Systems),包含了以下:

  • 前端伺服器的負載平衡、資料中心內部的附載平衡
  • 處理系統超載 (QPS, Rate Limit)、處理連鎖反應
  • 分散式系統:分散式一致化提高可靠性、分散式排程任務、資料處理管線、資料讀寫一致性 (CAP theorem)、分散式共識
  • 可靠的進行大規模發行 (Launch Coordination Engineers, LCE)

其中對於 負載平衡 (Load Balancer) 有很多技術、原理的著墨,特別是在 分散式架構 盛行的年代,很多人不會注意到 分散式系統謬論Rate Limit and Throttling分散式共識Message Bus … 等核心問題。

想要深入了解大型分散式系統是如何運作、背後的原理,想要成為架構師、規劃出能面對大流量的系統,這些章節是必讀的!

Updated 2019/05/17: 由小弟翻譯的書 分散式系統設計 在 2019/05/20 上市。

四、管理與訓練

如何把 SRE 的概念放入既有的團隊是不容易的,如果你是團隊的 Leader、技術管理階層、企業經營者、產品經理,這些章節是可以好好研究的:

  • 可靠的進行大規模發行
  • 迅速培養 SRE 加入 on-call
  • SRE 與其他團隊的溝通與協作
  • SRE 參與模型的演進歷程
  • 其他行業的實踐經驗

DevOps 的精神強調團隊的垂直整合,而身為管理者的你,如何讓這樣的新觀念、想法落實到現場,落地到組織,讓團隊能夠自主學習,這些章節有詳細的說明。

五、箴言 (Slogan)

這本書很多章節開頭有一些意義深遠的 箴言 (Slogan),完整請參考『Slogan in SRE』的整理。如果想要快速、簡單的了解這本書的精神與想法,快速讀過這些句子,你大概知道這本書的想法。底下整理我個人很喜歡的句子:

  • Hope is not a strategy. (不能將運氣當作策略)
  • Be warned that being an expert is more than understanding how a system is supposed to work. Expertise is gained by investigating why a system doesn’t work. (值得警惕的是,理解一個系統如何工作,並不能使人成為專家。只有靠調查系統為何不能正常工作才行。)
  • Things break; that’s life. (東西早晚要壞的,這就是生活。)
  • If you haven’t tried it, assume it’s broken. (如果你還沒開始親自測試過某件東西,那麼就假設他是壞的。)
  • The cost of failure is education. (學習是避免失敗的最好辦法。)

這些只是其中一小部分,而我個人最喜歡的句子:

Things break; that’s life.

這句話在 AWS Whitepaper 也經常提到類似的概念,像是 Design for failure:不管是什麼東西,都會壞掉,設計架構時,就要思考壞了怎麼辦?同樣的, Chaos Engineering 也是同樣的概念。

另外一段話也是我很喜歡的:

值得警惕的是,理解一個系統如何工作,並不能使人成為專家。只有靠調查系統為何不能正常工作才行。

這段話呼應到我平常 鼓勵同事的話

沒什麼大神,雷踩多了,還活著的,就是大神。

這是一種推坑的概念,但是延伸想法平常的開發流程,就是要多做 系統性的測試


FAQ

Q1: DevOps 和 SRE 有啥不一樣?

Google 說 SRE 是 DevOps 的實踐,用程式碼表示就是:class SRE implements DevOps。我個人的看法:DevOps 是 理念原則,SRE 則是 實踐方法

DevOps 現在的我是用整個 企業經營 的角度來看 (高大上),也就是 Development 其實是產品開發週期,包含從需求、寫程式、測試、部署等段落,各式各樣的開發流程,不管是敏捷開發、還是我整理的 Software Development Lifecycle 都是在討論這段;而 Operation 則是企業整體的營運。從業務把客戶引入之後,開始使用產品,形成營收 (Incoming)、系統維運成本、企業經營成本、最後算出的淨利、毛利 … 等。Operation 我看的是 COO (營運長) 的概念,Development 我看的是 CPO (產品長) 的概念。

Q2: SRE 要會啥技能?

SRE 也是軟體工程師,他除了需要具備傳統系統工程師 (System Engineer) 的技能之外,同時要具備 軟體開發 的能力、分散式系統知識。至少會一種 script、一種 compiling language 是基本的,了解基礎的 計算機科學 知識,像是 OS、Algorithm、Data Structure、Computer Architecture、Networking … 都是必要的基礎專業。

Q3: SRE 跟傳統的 MIS、機房 OP 有什麼差異?

SRE 的主軸任務是維持系統的穩定服務,必須用程式自動化完成這些任務。自動化 代表著,要瞭解如何 軟體工程 達到目的,而不只是為了自動化而自動化。

Q4: SRE 這本書翻譯的好嗎?

SRE 簡、繁中文版譯者 孫宇聰,中國人,2007-2014 在 Google SRE Team。因為他本身就在 Google SRE 待過很長的時間,所以語意上不是問題,簡繁中文版我都有看過,閱讀上是可以接受與理解的。

Q5: 有哪些領域和 SRE 有關係?

這個問題有點意思,用這張圖來回答比較生動:

原文 點這裡,歡迎來喇低賽 XD

Q6: SRE 的概念會不會跟 敏捷開發 有衝突?

這些想法不會衝突。SRE 是強調用 軟體工程機算機科學 做維運任務。敏捷開發團隊具備高度的學習、彈性、自組織的特性,在這樣的條件之下,SRE 可以協助團隊更快速面對 真實的世界、給予團隊建議。團隊可以因此更的快地適應,更快地面對市場的挑戰!

對我個人來講,不管是敏捷、SRE、DevOps,目的都是 Getting Things Done,當這樣想的時候,做事的過程,自然而然就會有更 宏觀的視野 來面對。

相關文章:

Q7: SRE 這本書適合什麼人看?

如同章節的介紹,這本書很適合開發團隊各種角色一起閱讀討論。非工程背景、管理職適合閱讀 Part 1、CH12-16 事件管理部分、以及最後的管理與教育訓練。工程背景則建議完整閱讀整本書。

Q8: 哪裡有 SRE 相關資源以及討論?

Facebook 社群 DevOps TaiwanSite Reliability Engineering Taiwan 有很多讀書會的資料: SRE 讀書會筆記


結語

知道 SRE 這個又新又潮的詞,是在 2016 年的 媒體報導 文章開始,那時候我已經負責系統維運工作一段時間,每天面臨各式各樣系統管理、與維運的任務,處理各式各樣系統異常、寫了 n 篇異常報告,要監控、值班、要管理團隊、要學習 Cloud 相關知識,在這些日常維運的過程,同時因為 DevOps 一詞在社群鋪天蓋地的湧現,各種研討會、新技術如荒洪般的衝向我。這樣的衝擊、經歷,讓我不斷的在思考底下這些問題:

那段人生的歲月就在這些思考中起起伏伏、跌跌撞撞中度過,而 SRE 的出現讓我有了新的方向,特別是書本前言這段讓人非常有感的話:

軟體工程有的時候和育兒類似:雖然生育過程痛苦、艱辛,但是養育成人的過程才是真正耗費心力之處。傳統的軟體工程花費很多精力討論軟體開發的過程,而不是其後的維護過程。統計顯示,一套軟體系統的 40% ~ 90% 成本,其實是花費在建置之後,不斷維護的過程。

業界流行的一個說法:一套系統如果已經開發完成,部署在正式環境上,那麼他就是『穩定的』,不需要那麼多工程師花費精力去最佳化、維護。

我們認為這樣的說法是錯的,從這個角度來看,如果軟體工程主要專注於設計和建構軟體系統,那麼應該有另一個種職業專注於整個軟體系統的生命週期管理:從其設計一直到部署,經歷不斷改進,最後順利除役。這樣的職業必須具備非常廣泛的技能,並且和其他職業的專注點不同,Google 把這個職位稱為 網站可靠性工程師 (SRE, Site Reliability Engineering)

因為個人 Dev、QAOps 三段完整的經歷,有一些深刻的體悟與心得,加上書本開場這段話,讓我更深刻的體悟到 Dev & Ops 從來就不只是口號,而是具體且深刻的實踐,是動詞!SRE 告訴大家 Google 如何 ,站在巨人肩膀,讓大家有機會走得更穩、更強壯!

本文授權 DevOpsDays Taipei 2018天瓏網路書店 全文轉載


最難的事










相關文章 (站內)

SRE 相關

測試與自動化相關

維運、運維


延伸閱讀 (站外)

Google 官方資料

相關資料、書

相關 FB 社群



Comments

2018/08/03 12:43:00





  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲