SRE Study Notes - Opening, CH1

SRE: Site Reliability Engineering
How Google Runs Production Systems
Rick Hwang @ 91APP
2017/07/05
1

幾個問題
● 系統上線前要做些什麼事？
● 系統上線過程要做什麼事？
● 系統上線後要做些什麼事？
● 系統上線後哪些事最重要？
4

換個對象
● 買車前要做些什麼事？
● 買車過程要做什麼事？
● 買車後要做些什麼事？
● 交車後哪些事最重要？
5

● Site
○ *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下，在指定的時間內，成功持續執行某個功能的機率。
● Engineering:
○ 工程方法、軟體工程、流程
Site Reliability Engineering
8

● 重點在可靠性 (Reliability)
● 基本概念：任何系統如果沒有人能夠穩定的使用，就沒有存
在的意義。
Site Reliability Engineering
9

Site Reliability Engineer
● 是一種角色 (Role)、職務，像是 Manager, Developer, Tester/QA, SysOps,
DevOps Engineer
10

● 討論 Principles、Practice、Management
○ 不是單純談技術，而是用講故事的方式，探討系統維運需要面對的
問題
● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護
(Maintain)
為什麼選讀這本書？
12

SDLC
(Software Development LifeCycle)
13
看見全
局?

https://www.slideshare.net/warfan/devops-53161280
15

Provisioning
Observation
Pipeline
Maintain
Deployment
Plan Development Test Operation
16By Rick Hwang
Source: Software Development Lifecycle

系統維運的五個重要任務
● Provisioning
● Deployment
● Observation, and Monitor
● Maintenance
● Pipeline (Chain Tasks for CI / CD)
17
Ref: 淺談系統監控與 CloudWatch 的應用

● 討論 Principles、Practice、Management
● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護
(Maintain)
Again：為什麼選讀這本書？
18

另外：作者 - Benjamin Treynor Sloss
19
Ben Treynor Sloss
SRE (名稱發明者), Google VP

https://www.indeed.com/q-Site-Reliability-Engineer-jobs.html 23

角色 - 職責、權責、技能、專業
● Site Reliability Engineer
● DevOps Engineer
● System Operator (SysOps)
● System Administroator
24
● System Engineer - 以上全包了

這本書，不會告訴你 ...
25

黑魔法？奇技淫巧？
帶給你迷思？
26

http://www.infoq.com/cn/news/2017/06/U-no-Google
27

站在巨人的肩膀
● 演算法, 資料結構, 計算機組織, 科幻概論
● Design Pattern, Thinking in Java
● Building Microservices
● Continuous Delivery, CC2E
● How Google Tests Software
● AWS Whitepapers
○ AWS Well-Architected Framework
○ Architecting for the Cloud: AWS Best Practices
○ ...
30

不要以為 ...
● 讀過 Google SRE 你就是系統維運之神
● 買了很貴的很棒的機器，就可以有很多流量，賺很多錢
● 不要以為用了 AWS、GCP、Azure 就 NoOps 了！系統就不會倒
● 有自動化測試就不用手動測試
● 導入 Scrum、看板就不會有衝突、能順利交付
● ...
31

前言 (Foreword)
● 系統維運本質上是人與計算機共同參與的一項系統性工程 - Principles of
Network and System Administration
● 系統管理工程師：他們很神秘，和公司內的體制與整個行業也格格不入
● IT 行業大多自我封閉，交流甚少
○ 整個軟體產業都在鼓吹厚顏無恥的 “Just show me the code”
○ ZYX as Code, ABC as an Service
● 這本書沒有萬靈丹，沒有什麼東西能解決一切的。
● 不斷自省
33

34
https://lkml.org/lkml/2000/8/25/132

序言 (Preface)
● 軟體工程花很多時間再討論開發過程，很少討論之後的維護過程。
○ Rick: 開發就是生孩子，維護是教育孩子；開發是 0-1，維運是 1-99
● 統計顯示，軟體系統 40%-90% 的成本是在開發之後的維護過程
● 錯誤的觀念：系統開發完之後，他就是『穩地的』
○ Rick: 所以社會問題很多，生了就不教了
● 應該有一個職務專注整個生命週期的管理，從設計、到部署、直到服務退役。
35

● SRE 是 Engineer - 一個職務角色
● SRE 關注的是可靠性
○ 可靠性：某個系統能夠在指定環境下，成功持續執行某個功能的機率
○ 可靠性就是安全性，越早關住越好
● 任何系統沒有人可以穩定的使用，就沒存在的意義
● SRE 是 Google VP (維運副總) 發明的
○ 他的位置是副總
最重要的事
36

Apollo 7
● 登陸月球計畫，軟體工程師 - Margaret Hamilton (MIT 教授)
● 按下 DSKY 鍵，系統就崩潰
○ NASA 高層覺得機率太小，不需要修
○ NASA 飛行員覺得不可能犯如此低級的錯，哈哈哈
○ Margaret 在手冊著名：不可以跑 P01 程序，並寫下異常處理方法
● Apollo 8 執行任務
○ 飛行員意外觸發 P01
○ 問題在有限時間被排除了
● Margaret：『無論一個軟體系統運行原理掌握得多麽徹底，也不能阻止人犯意外
的錯誤。』
○ “Software Engineer” 一詞是 Margaret 推廣定義的
37

Chapter 1: Introduction
40
Ben Treynor Sloss
SRE (名稱發明者), Google VP

Hope is not a stategy.
不能把運氣當做策略
41

系統管理員 (System Admin)
● 系統管理員的工作是？
○ 就是打雜，做 Developer 不想做的？是這樣？
● 系統管理員日常工作與產品研發相差甚遠
○ 不只遠，是天文單位才能衡量的
○ 補充一個：產品開發和產品測試相差也很遠！
● 傳統的作分法：開發部門 (Dev)、維運部門 (Ops)
○ 應該還有產品部門、測試部門
○ 合稱四大天王：PM、Dev、Test、Ops
42

Dev & Ops 分離團隊的問題
直接成本
● 系統管理依賴人工處理，隨著系統複雜度增加、部署規模變大
間接成本 - 溝通問題
● 研發與維運人員背景、技術能力不同
● 工作目標不同：對可靠度的理解要求不同
● 部門之間的信任與尊重問題 - 常常上演，最後演變成政治問題
44

Dev & Ops 的分歧：版本更新、配置變更
● 研發部門：快速構建與發佈
● 維運部門：如何在值班期間避免發生故障
○ 大部分的問題，都是部署之後導致的
○ 不管是部署新的版本，還是配置的變更
45

● 研發部門：隨時隨地發佈新功能，沒有任何阻攔
○ the development teams want to launch new features and see them
adopted by users.
● 維運部門：一但在 Production 正常運作，就不要進行任何變動
○ the ops teams want to make sure the service doesn’t break while they
are holding the pager. Because most outages are caused by some kind
of change—a new configuration, a new feature launch, or a new type of
user traffic—the two teams’ goals are fundamentally in tension
Dev & Ops 想要的
46

Google 的解決之道：SRE
SRE is what happens when you ask a software engineer to design an operations team.
(翻譯：自己開發、自己維運 )
● SRE 有兩種工程師：
1. 團隊中 50% ~ 60% 是標準的軟體工程師。就是通過 Google 面試的人
2. 40% ~ 60% 滿足基本的軟件工程師 (85% ~ 99%)，但同時具有一定程度的其他技能的工程師，
主要是 UNIX 內部系統和網路 (Layer 1 - 3) 的知識
● SRE 成員的特點：
○ 對於重複、手工性的操作有天然的排斥感
○ 有足夠的技術能力快速開發軟件系統，取代手工
● SRE 團隊 50% 的精力放在開發工作上
● 將常見的維運工作，交給產品研發部門操作，或者從產品研發部門抽調人力參與團隊輪值工作。
○ 只有管理階層主動維護 SRE 團隊的工作平衡，SRE 才能有精力做開發工作
● 整個產品研發部門，都有機會參與大規模維運部署活動
47

● 人員的招聘：
○ SRE 需要和產品研發部門競爭
○ 同時要求多項技能，市場上同樣背景的人太少
● 會寫程式的人，不見得懂系統，懂系統不見得懂網路
● 懂系統不見得會規劃系統，懂網路不見得會規劃網路
SRE 的挑戰與問題
48

49
System Admin & Operator
System Developer
Network Engineer

DevOps or SRE?
書本的解釋：SRE 是 DevOps 的實踐方式
以下是 Rick 的註解：
● DevOps Engineer 必須參與產品開發，熟悉軟體開發流程
○ 跟 Developer, Tester 一樣，參與整個產品的開發流程，跟著產品專案時程跑
○ 本身也是 Developer，而且有 Operator 經驗
● SRE
○ 專注在系統可靠度，跟展品專案時程跑
○ Google 的最佳實踐方法與管理精神
50

SRE 方法論
承擔以下職責：可用性改進、延遲優化、性能優化、效率優化、變更管理、監控、緊急事
故處理、容量規劃與管理
In general, an SRE team is responsible for the availability, latency, performance, e
ciency, change management, monitoring, emergency response, and capacity
planning of their service(s)
此方法論也規範了如何與產品研發部門、測試部門、終端用戶進行有效溝通。
51

SRE 方法論
● 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● 在保障服務 SLO 的前提下，最大化迭代速度 (Pursuing Maximum Change
Velocity Without Violating a Service’s SLO)
● 監控系統 (Monitoring)
● 緊急事件處理 (Emergency Response)
● 變更管理 (Change Management)
● 需求預測與容量規劃 (Demand Forecasting and Capacity Planning)
● 資源部署 (Provisioning)
● 效率與性能 (Efficiency and Performance)
52

確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● SRE 團隊的維運工作，限制在 50% 以內。
● 管理人員 (Leader or Manager) 經常性地分配團隊成員的時間
○ 採取暫時性措施，將過多的維運工作，轉回開發團隊處理
● 處理維運工作的準則：8-12 小時的 on-call，最多處理兩個緊急事件
○ 確保工程師有足夠時間處理緊急事件，並寫完成異常報告
● 所有的異常都要有事後總結，無論有沒觸發警報
○ 如果異常事件沒有觸發報警，那揭露監控系統的漏洞與問題
○ 報告要包含：事故發生、發現、解決的過程、根本原因、預防或者優化方法
53

在保障服務 SLO 的前提下，最大化迭代速度
(Pursuing Maximum Change Velocity Without Violating a Service’s SLO)
● 錯誤預算 (error budget)：任何產品都不是、也不應該做到 100% 可靠。
○ 對終端用戶來講 100% 和 99.999% 是沒差的
○ 終端用戶到服務器之間，有很多系統，綜合起來要 99.999%
● 可靠性目標 (100%) 不是技術性問題，而是產品問題，要考慮以下問題：
○ 基於用戶使用習慣，可靠性到多少才會讓客戶滿意？
○ 如果可靠性不夠，有沒有取代方案？
○ 服務的可靠是否影響用戶對產品的使用模式？
● 公司的商業部門或產品部門要有合理的可靠性目標：
○ 錯誤預算 = (1 - 可靠性目標)
○ 可靠性目標 = 99.99%
○ 錯誤預算 = (1 - 99.99%) = 0.01%
54

錯誤預算
● SRE 團隊目標不再是 “零事故”
● 解決研發團隊與 SRE 團隊的組織衝突
● 使用錯誤預算最大化新功能上線的速度，同時保障服務質量，例如：
○ 技術戰略：A/B Test、
● ”事故“ 不見得是壞事，而是流程中必須有的，兩個團隊一起處理的
55

監控系統 (Monitoring)
● 服務品質和可用性的主要手段
● 監控系統要有三個輸出：
○ 警急報警 (Alert)：收到通知，要立即處理的，而且要避免再次出現
○ 工單 (Ticket)：接到通知要處理的，但不是立即性的
○ 日誌 (Logging)：事後分析的日誌，正常形況，沒人會去看
56

緊急事件處理 (Emergency Response)
● 可靠性 = Function(MTTF, MTTR)
○ MTTF (Mean Time To Failure): 平均失敗時間
○ MTTR (Mean Time to Repair): 平均修復時間，系統恢復到正常的指標
● 人工介入的異常處理，只會延長恢復時間
● 可以自動恢復的系統，比起人工介入的可靠性要高
● 透過事前演練，將最佳實踐方法記錄維運手冊 (Playbook)，可使 MTTR 降低三
倍以上
○ 詳細記錄步驟以及方法
○ 有經驗的團隊，應該都會有經典案例，或者很多異常紀錄
Disaster Recovery (災難還原, DR)
● RPO (Recover Point Objective)
● RTO (Recover Time Objective)
57

幾個提醒 - Rick
● 維運手冊紀錄的東西，是死的步驟，了解系統運作原理後，做出的判斷是活的
● 如果步驟有二十、三十個，這是要縮減的，出問題的當下，要能夠一目瞭然
● 如果維運都自動化了。。。會有的問題：
○ 最後大家知道能動了，但不知道為什麼會動
○ CI / CD 能動了，但你知道過程做了些什麼？
○ 每個自動化，都要能夠 Step by Step 被執行，執行後也要可以確認每個的狀態
○ Step 跟 Step 可以分段執行 (設計 Pipeline Task 時會遇到的)
58

變更管理 (Change Management)
Production 70% 的問題，來自於某種部署變更造成的。變更管理最佳實踐原則：
● 採用漸進式部署機制 (Implementing progressive rollouts)
● 快速而準確定位問題點 (Quickly and accurately detecting problems)
● 出現問題時，可以安全地恢復 (Rolling back changes safely when problems
arise)
59

補充：變更管理的定義 - Rick
● CI / CD 改變算不算變更管理？
● 網路環境改變算不算？
● API、Libraries
● 作業系統版本、Patch
60

需求預測與容量規劃
(Demand Forecasting and Capacity Planning)
● 有一個準確自然增長的預測模型
○ 用戶增加，使用量上升，資源需求也上升
● 規劃中必須有準確的非自然增長的需求來源統計
○ 新功能的發布、商業推廣、其他商業面的因素
● 必須要有週期性的壓力測試
SRE 要主導容量規劃與資源部署。
61

資源部署 (Provisioning)
● 變更管理 (Change Management) 與容量規劃 (Capacity Planning) 的結合
● 資源部署與配置必須能夠非常迅速的完成
○ 資源通常是昂貴的
● 增加容量：自動新增 Instnace 或者整個 Cluster
● 群集配置：網路、複雜平衡、Configuration
62

補充：Provisioning
Source: Resource Provisioning and DevOps
63

效率與性能 (Efficiency and Performance)
● 資源的使用率
● 影響使用率的因素：
○ 用戶需求（流量）
○ 可用容量和軟體的資源使用率
● 透過合理部署和配置容量，以及預測模型，可以提升資源的使用率。
64

Chapter 1 結論
● SRE 代表管理大型、複雜服務的最佳實踐
● 簡單的想法：
○ as a software engineer, this is how I would want to invest my time to
accomplish a set of repetitive tasks
● SRE 是一套指導思想、方法論、激勵方法
● SRE 是一個專職的職務
65

SRE 方法論有哪些？舉例兩個
67
● 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● 在保障服務 SLO 的前提下，最大化迭代速度 (Pursuing Maximum Change
Velocity Without Violating a Service’s SLO)
● 監控系統 (Monitoring)
● 緊急事件處理 (Emergency Response)
● 變更管理 (Change Management)
● 需求預測與容量規劃 (Demand Forecasting and Capacity Planning)
● 資源部署 (Provisioning)
● 效率與性能 (Efficiency and Performance)

舉例 Dev & Ops 常見的問題
68

SRE Study Notes - Opening, CH1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SRE Study Notes - Opening, CH1

Similar to SRE Study Notes - Opening, CH1 (20)

More from Rick Hwang

More from Rick Hwang (20)

SRE Study Notes - Opening, CH1