SRE Study Notes - Opening, CH1 (20171116)

SRE Study Group: https://study-area.sre.tw/01_SRE/CH01/

Transcript

1. SRE: Site Reliability Engineering How Google Runs Production Systems Rick Hwang @ 91APP 2017/07/05 1
3. Opening 3
4. 幾個問題 • 系統上線前要做些什麼事？ • 系統上線過程要做什麼事？ • 系統上線後要做些什麼事？ • 系統上線後哪些事最重要？ 4
5. 換個對象 • 買車前要做些什麼事？ • 買車過程要做什麼事？ • 買車後要做些什麼事？ • 交車後哪些事最重要？ 5
6. 能動就好? 6
8. • Site ◦ *.google.com ◦ gmail, driver, calendar, cloud ... • Reliability: ◦ 某個系統在指定的環境下，在指定的時間 內，成功持續執行某個功能的機率。 • Engineering: ◦ 工程方法、軟體工程、流程 Site Reliability Engineering 8
9. • 重點在可靠性 (Reliability) • 基本概念：任何系統如果沒有人能夠穩定的使用，就沒有存 在的意義。 Site Reliability Engineering 9
10. Site Reliability Engineer • 是一種角色 (Role)、職務，像是 Manager, Developer, Tester/QA, SysOps, DevOps Engineer 10
12. • 討論 Principles、Practice、Management ◦ 不是單純談技術，而是用講故事的方式，探討系統維運需要面對的 問題 • 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護 (Maintain) 為什麼選讀這本書？ 12
13. SDLC (Software Development LifeCycle) 13 看見全 局?
14. 14 Keyword: DevOps
15. https://www.slideshare.net/warfan/devops-53161280 15
16. Provisioning Observation Pipeline Maintain Deployment Plan Development Test Operation 16 By Rick Hwang Source: Software Development Lifecycle
17. 系統維運的五個重要任務 • Provisioning • Deployment • Observation, and Monitor • Maintenance • Pipeline (Chain Tasks for CI / CD) 17 Ref: 淺談系統監控與 CloudWatch 的應用
18. • 討論 Principles、Practice、Management • 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護 (Maintain) Again：為什麼選讀這本書？ 18
19. 另外：作者 - Benjamin Treynor Sloss 19 Ben Treynor Sloss SRE (名稱發明者), Google VP
20. 看看外面 20
23. https://www.indeed.com/q-Site-Reliability-Engineer-jobs.html 23
24. 角色 - 職責、權責、技能、專業 • Site Reliability Engineer • DevOps Engineer • System Operator (SysOps) • System Administroator 24 • System Engineer - 以上全包了
25. 這本書，不會告訴你 ... 25
26. 黑魔法？奇技淫巧？ 帶給你迷思？ 26
27. http://www.infoq.com/cn/news/2017/06/U-no-Google 27
29. 讀完了，下課！ 29
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
34. 34 https://lkml.org/lkml/2000/8/25/132
35. 序言 (Preface) • 軟體工程花很多時間再討論開發過程，很少討論之後的維護過程。 ◦ Rick: 開發就是生孩子，維護是教育孩子；開發是 0-1，維運是 1-99 • 統計顯示，軟體系統 40%-90% 的成本是在開發之後的維護過程 • 錯誤的觀念：系統開發完之後，他就是『穩地的』 ◦ Rick: 所以社會問題很多，生了就不教了 • 應該有一個職務專注整個生命週期的管理，從設計、到部署、直到服務退役。 35
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
39. Part I Introduction 39
40. Chapter 1: Introduction 40 Ben Treynor Sloss SRE (名稱發明者), Google VP
41. Hope is not a stategy. 不能把運氣當做策略 41
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
49. 49 System Admin & Operator System Developer Network Engineer
50. DevOps or SRE? 書本的解釋：SRE 是 DevOps 的實踐方式 以下是 Rick 的註解： • DevOps Engineer 必須參與產品開發，熟悉軟體開發流程 ◦ 跟 Developer, Tester 一樣，參與整個產品的開發流程，跟著產品專案時程跑 ◦ 本身也是 Developer，而且有 Operator 經驗 • SRE ◦ 專注在系統可靠度，跟展品專案時程跑 ◦ Google 的最佳實踐方法與管理精神 50
51. 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
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
56. 監控系統 (Monitoring) • 服務品質和可用性的主要手段 • 監控系統要有三個輸出： ◦ 警急報警 (Alert)：收到通知，要立即處理的，而且要避免再次出現 ◦ 工單 (Ticket)：接到通知要處理的，但不是立即性的 ◦ 日誌 (Logging)：事後分析的日誌，正常形況，沒人會去看 56
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
60. 補充：變更管理的定義 - Rick • CI / CD 改變算不算變更管理？ • 網路環境改變算不算？ • API、Libraries • 作業系統版本、Patch 60
61. 需求預測與容量規劃 (Demand Forecasting and Capacity Planning) • 有一個準確自然增長的預測模型 ◦ 用戶增加，使用量上升，資源需求也上升 • 規劃中必須有準確的非自然增長的需求來源統計 ◦ 新功能的發布、商業推廣、其他商業面的因素 • 必須要有週期性的壓力測試 SRE 要主導容量規劃與資源部署。 61
62. 資源部署 (Provisioning) • 變更管理 (Change Management) 與容量規劃 (Capacity Planning) 的結合 • 資源部署與配置必須能夠非常迅速的完成 ◦ 資源通常是昂貴的 • 增加容量：自動新增 Instnace 或者整個 Cluster • 群集配置：網路、複雜平衡、Configuration 62
63. 補充：Provisioning Source: Resource Provisioning and DevOps 63
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
66. Q & A 66
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)
68. 舉例 Dev & Ops 常見的問題 68