More Related Content Similar to SRE Study Notes - Opening, CH1 (20) More from Rick Hwang (20) SRE Study Notes - Opening, CH18. ● Site
○ *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下,在指定的時間 內,成功持續執行某個功能的機率。
● Engineering:
○ 工程方法、軟體工程、流程
Site Reliability Engineering
8
24. 角色 - 職責、權責、技能、專業
● Site Reliability Engineer
● DevOps Engineer
● System Operator (SysOps)
● System Administroator
24
● System Engineer - 以上全包了
30. 站在巨人的肩膀
● 演算法, 資料結構, 計算機組織, 科幻概論
● 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
31. 不要以為 ...
● 讀過 Google SRE 你就是系統維運之神
● 買了很貴的很棒的機器,就可以有很多流量,賺很多錢
● 不要以為用了 AWS、GCP、Azure 就 NoOps 了!系統就不會倒
● 有自動化測試就不用手動測試
● 導入 Scrum、看板 就不會有衝突、能順利交付
● ...
31
33. 前言 (Foreword)
● 系統維運本質上是人與計算機共同參與的一項系統性工程 - Principles of
Network and System Administration
● 系統管理工程師:他們很神秘,和公司內的體制與整個行業也格格不入
● IT 行業大多自我封閉,交流甚少
○ 整個軟體產業都在鼓吹厚顏無恥的 “Just show me the code”
○ ZYX as Code, ABC as an Service
● 這本書沒有萬靈丹,沒有什麼東西能解決一切的。
● 不斷自省
33
36. ● SRE 是 Engineer - 一個職務角色
● SRE 關注的是可靠性
○ 可靠性:某個系統能夠在指定環境下,成功持續執行某個功能的機率
○ 可靠性就是安全性,越早關住越好
● 任何系統沒有人可以穩定的使用,就沒存在的意義
● SRE 是 Google VP (維運副總) 發明的
○ 他的位置是副總
最重要的事
36
37. Apollo 7
● 登陸月球計畫,軟體工程師 - Margaret Hamilton (MIT 教授)
● 按下 DSKY 鍵,系統就崩潰
○ NASA 高層覺得機率太小,不需要修
○ NASA 飛行員覺得不可能犯如此低級的錯,哈哈哈
○ Margaret 在手冊著名:不可以跑 P01 程序,並寫下異常處理方法
● Apollo 8 執行任務
○ 飛行員意外觸發 P01
○ 問題在有限時間被排除了
● Margaret:『無論一個軟體系統運行原理掌握得多麽徹底,也不能阻止人犯意外
的錯誤。』
○ “Software Engineer” 一詞是 Margaret 推廣定義的
37
42. 系統管理員 (System Admin)
● 系統管理員的工作是?
○ 就是打雜,做 Developer 不想做的?是這樣?
● 系統管理員日常工作與產品研發相差甚遠
○ 不只遠,是天文單位才能衡量的
○ 補充一個:產品開發和產品測試相差也很遠!
● 傳統的作分法:開發部門 (Dev)、維運部門 (Ops)
○ 應該還有產品部門、測試部門
○ 合稱四大天王:PM、Dev、Test、Ops
42
44. Dev & Ops 分離團隊的問題
直接成本
● 系統管理依賴人工處理,隨著系統複雜度增加、部署規模變大
間接成本 - 溝通問題
● 研發與維運人員背景、技術能力不同
● 工作目標不同:對可靠度的理解要求不同
● 部門之間的信任與尊重問題 - 常常上演,最後演變成政治問題
44
45. Dev & Ops 的分歧:版本更新、配置變更
● 研發部門:快速構建與發佈
● 維運部門:如何在值班期間避免發生故障
○ 大部分的問題,都是部署之後導致的
○ 不管是部署新的版本,還是配置的變更
45
46. ● 研發部門:隨時隨地發佈新功能,沒有任何阻攔
○ 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
47. 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
48. ● 人員的招聘:
○ SRE 需要和產品研發部門競爭
○ 同時要求多項技能,市場上同樣背景的人太少
● 會寫程式的人,不見得懂系統,懂系統不見得懂網路
● 懂系統不見得會規劃系統,懂網路不見得會規劃網路
SRE 的挑戰與問題
48
50. DevOps or SRE?
書本的解釋:SRE 是 DevOps 的實踐方式
以下是 Rick 的註解:
● DevOps Engineer 必須參與產品開發,熟悉軟體開發流程
○ 跟 Developer, Tester 一樣,參與整個產品的開發流程,跟著產品專案時程跑
○ 本身也是 Developer,而且有 Operator 經驗
● SRE
○ 專注在系統可靠度,跟展品專案時程跑
○ Google 的最佳實踐方法與管理精神
50
52. 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
53. 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● SRE 團隊的維運工作,限制在 50% 以內。
● 管理人員 (Leader or Manager) 經常性地分配團隊成員的時間
○ 採取暫時性措施,將過多的維運工作,轉回開發團隊處理
● 處理維運工作的準則:8-12 小時的 on-call,最多處理兩個緊急事件
○ 確保工程師有足夠時間處理緊急事件,並寫完成 異常報告
● 所有的異常都要有事後總結,無論有沒觸發警報
○ 如果異常事件沒有觸發報警,那揭露監控系統的漏洞與問題
○ 報告要包含:事故發生、發現、解決的過程、根本原因、預防或者優化方法
53
54. 在保障服務 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
55. 錯誤預算
● SRE 團隊目標不再是 “零事故”
● 解決研發團隊與 SRE 團隊的組織衝突
● 使用錯誤預算最大化新功能上線的速度,同時保障服務質量,例如:
○ 技術戰略:A/B Test、
● ”事故“ 不見得是壞事,而是流程中必須有的,兩個團隊一起處理的
55
57. 緊急事件處理 (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
58. 幾個提醒 - Rick
● 維運手冊紀錄的東西,是死的步驟,了解系統運作原理後,做出的判斷是活的
● 如果步驟有二十、三十個,這是要縮減的,出問題的當下,要能夠一目瞭然
● 如果維運都自動化了。。。會有的問題:
○ 最後大家知道能動了,但不知道為什麼會動
○ CI / CD 能動了,但你知道過程做了些什麼?
○ 每個自動化,都要能 夠 Step by Step 被執行,執行後也要可以確認每個的狀態
○ Step 跟 Step 可以分段執行 (設計 Pipeline Task 時會遇到的)
58
59. 變更管理 (Change Management)
Production 70% 的問題,來自於某種部署變更造成的。變更管理最佳實踐原則:
● 採用漸進式部署機制 (Implementing progressive rollouts)
● 快速而準確定位問題點 (Quickly and accurately detecting problems)
● 出現問題時,可以安全地恢復 (Rolling back changes safely when problems
arise)
59
61. 需求預測與容量規劃
(Demand Forecasting and Capacity Planning)
● 有一個準確自然增長的預測模型
○ 用戶增加,使用量上升,資源需求也上升
● 規劃中必須有準確的非自然增長的需求來源統計
○ 新功能的發布、商業推廣、其他商業面的因素
● 必須要有週期性的壓力測試
SRE 要主導容量規劃與資源部署。
61
62. 資源部署 (Provisioning)
● 變更管理 (Change Management) 與容量規劃 (Capacity Planning) 的結合
● 資源部署與配置必須能夠非常迅速的完成
○ 資源通常是昂貴的
● 增加容量:自動新增 Instnace 或者整個 Cluster
● 群集配置:網路、複雜平衡、Configuration
62
64. 效率與性能 (Efficiency and Performance)
● 資源的使用率
● 影響使用率的因素:
○ 用戶需求(流量)
○ 可用容量和軟體的資源使用率
● 透過合理部署和配置容量,以及預測模型,可以提升資源的使用率。
64
65. 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
67. 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)