Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
SRE: Site Reliability Engineering
How Google Runs Production Systems
Rick Hwang @ 91APP
2017/07/05
1
2
Opening
3
幾個問題
● 系統上線前要做些什麼事?
● 系統上線過程要做什麼事?
● 系統上線後要做些什麼事?
● 系統上線後哪些事最重要?
4
換個對象
● 買車前要做些什麼事?
● 買車過程要做什麼事?
● 買車後要做些什麼事?
● 交車後哪些事最重要?
5
能動就好?
6
7
● Site
○ *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下,在指定的時間 內,成功持續執行某個功能的機率。
● Engineer...
● 重點在可靠性 (Reliability)
● 基本概念:任何系統如果沒有人能夠穩定的使用,就沒有存
在的意義。
Site Reliability Engineering
9
Site Reliability Engineer
● 是一種角色 (Role)、職務,像是 Manager, Developer, Tester/QA, SysOps,
DevOps Engineer
10
11
● 討論 Principles、Practice、Management
○ 不是單純談技術,而是用講故事的方式,探討系統維運需要面對的
問題
● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護
(Maintai...
SDLC
(Software Development LifeCycle)
13
看見全
局?
14
Keyword: DevOps
https://www.slideshare.net/warfan/devops-53161280
15
Provisioning
Observation
Pipeline
Maintain
Deployment
Plan Development Test Operation
16By Rick Hwang
Source: Software Dev...
系統維運的五個重要任務
● Provisioning
● Deployment
● Observation, and Monitor
● Maintenance
● Pipeline (Chain Tasks for CI / CD)
17
R...
● 討論 Principles、Practice、Management
● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護
(Maintain)
Again:為什麼選讀這本書?
18
另外:作者 - Benjamin Treynor Sloss
19
Ben Treynor Sloss
SRE (名稱發明者), Google VP
看看外面
20
21
22
https://www.indeed.com/q-Site-Reliability-Engineer-jobs.html 23
角色 - 職責、權責、技能、專業
● Site Reliability Engineer
● DevOps Engineer
● System Operator (SysOps)
● System Administroator
24
● Sys...
這本書,不會告訴你 ...
25
黑魔法?奇技淫巧?
帶給你迷思?
26
http://www.infoq.com/cn/news/2017/06/U-no-Google
27
28
讀完了,下課!
29
站在巨人的肩膀
● 演算法, 資料結構, 計算機組織, 科幻概論
● Design Pattern, Thinking in Java
● Building Microservices
● Continuous Delivery, CC2E
●...
不要以為 ...
● 讀過 Google SRE 你就是系統維運之神
● 買了很貴的很棒的機器,就可以有很多流量,賺很多錢
● 不要以為用了 AWS、GCP、Azure 就 NoOps 了!系統就不會倒
● 有自動化測試就不用手動測試
● 導入...
32
前言 (Foreword)
● 系統維運本質上是人與計算機共同參與的一項系統性工程 - Principles of
Network and System Administration
● 系統管理工程師:他們很神秘,和公司內的體制與整個行業也格...
34
https://lkml.org/lkml/2000/8/25/132
序言 (Preface)
● 軟體工程花很多時間再討論開發過程,很少討論之後的維護過程。
○ Rick: 開發就是生孩子,維護是教育孩子;開發是 0-1,維運是 1-99
● 統計顯示,軟體系統 40%-90% 的成本是在開發之後的維護過程
●...
● SRE 是 Engineer - 一個職務角色
● SRE 關注的是可靠性
○ 可靠性:某個系統能夠在指定環境下,成功持續執行某個功能的機率
○ 可靠性就是安全性,越早關住越好
● 任何系統沒有人可以穩定的使用,就沒存在的意義
● SRE ...
Apollo 7
● 登陸月球計畫,軟體工程師 - Margaret Hamilton (MIT 教授)
● 按下 DSKY 鍵,系統就崩潰
○ NASA 高層覺得機率太小,不需要修
○ NASA 飛行員覺得不可能犯如此低級的錯,哈哈哈
○ M...
38
Part I Introduction
39
Chapter 1: Introduction
40
Ben Treynor Sloss
SRE (名稱發明者), Google VP
Hope is not a stategy.
不能把運氣當做策略
41
系統管理員 (System Admin)
● 系統管理員的工作是?
○ 就是打雜,做 Developer 不想做的?是這樣?
● 系統管理員日常工作與產品研發相差甚遠
○ 不只遠,是天文單位才能衡量的
○ 補充一個:產品開發和產品測試相差也很遠...
43
Dev & Ops 分離團隊的問題
直接成本
● 系統管理依賴人工處理,隨著系統複雜度增加、部署規模變大
間接成本 - 溝通問題
● 研發與維運人員背景、技術能力不同
● 工作目標不同:對可靠度的理解要求不同
● 部門之間的信任與尊重問題 - ...
Dev & Ops 的分歧:版本更新、配置變更
● 研發部門:快速構建與發佈
● 維運部門:如何在值班期間避免發生故障
○ 大部分的問題,都是部署之後導致的
○ 不管是部署新的版本,還是配置的變更
45
● 研發部門:隨時隨地發佈新功能,沒有任何阻攔
○ the development teams want to launch new features and see them
adopted by users.
● 維運部門:一但在 Prod...
Google 的解決之道:SRE
SRE is what happens when you ask a software engineer to design an operations team.
(翻譯:自己開發、自己維運 )
● SRE ...
● 人員的招聘:
○ SRE 需要和產品研發部門競爭
○ 同時要求多項技能,市場上同樣背景的人太少
● 會寫程式的人,不見得懂系統,懂系統不見得懂網路
● 懂系統不見得會規劃系統,懂網路不見得會規劃網路
SRE 的挑戰與問題
48
49
System Admin & Operator
System Developer
Network Engineer
DevOps or SRE?
書本的解釋:SRE 是 DevOps 的實踐方式
以下是 Rick 的註解:
● DevOps Engineer 必須參與產品開發,熟悉軟體開發流程
○ 跟 Developer, Tester 一樣,參與整個產品的...
SRE 方法論
承擔以下職責:可用性改進、延遲優化、性能優化、效率優化、變更管理、監控、緊急事
故處理、容量規劃與管理
In general, an SRE team is responsible for the availability, l...
SRE 方法論
● 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● 在保障服務 SLO 的前提下,最大化迭代速度 (Pursuing Maximum Change
Velocity ...
確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● SRE 團隊的維運工作,限制在 50% 以內。
● 管理人員 (Leader or Manager) 經常性地分配團隊成員的時間
○ ...
在保障服務 SLO 的前提下,最大化迭代速度
(Pursuing Maximum Change Velocity Without Violating a Service’s SLO)
● 錯誤預算 (error budget):任何產品都不是、...
錯誤預算
● SRE 團隊目標不再是 “零事故”
● 解決研發團隊與 SRE 團隊的組織衝突
● 使用錯誤預算最大化新功能上線的速度,同時保障服務質量,例如:
○ 技術戰略:A/B Test、
● ”事故“ 不見得是壞事,而是流程中必須有的,兩...
監控系統 (Monitoring)
● 服務品質和可用性的主要手段
● 監控系統要有三個輸出:
○ 警急報警 (Alert):收到通知,要立即處理的,而且要避免再次出現
○ 工單 (Ticket):接到通知要處理的,但不是立即性的
○ 日誌 (...
緊急事件處理 (Emergency Response)
● 可靠性 = Function(MTTF, MTTR)
○ MTTF (Mean Time To Failure): 平均失敗時間
○ MTTR (Mean Time to Repair...
幾個提醒 - Rick
● 維運手冊紀錄的東西,是死的步驟,了解系統運作原理後,做出的判斷是活的
● 如果步驟有二十、三十個,這是要縮減的,出問題的當下,要能夠一目瞭然
● 如果維運都自動化了。。。會有的問題:
○ 最後大家知道能動了,但不知道...
變更管理 (Change Management)
Production 70% 的問題,來自於某種部署變更造成的。變更管理最佳實踐原則:
● 採用漸進式部署機制 (Implementing progressive rollouts)
● 快速而...
補充:變更管理的定義 - Rick
● CI / CD 改變算不算變更管理?
● 網路環境改變算不算?
● API、Libraries
● 作業系統版本、Patch
60
需求預測與容量規劃
(Demand Forecasting and Capacity Planning)
● 有一個準確自然增長的預測模型
○ 用戶增加,使用量上升,資源需求也上升
● 規劃中必須有準確的非自然增長的需求來源統計
○ 新功能的發...
資源部署 (Provisioning)
● 變更管理 (Change Management) 與容量規劃 (Capacity Planning) 的結合
● 資源部署與配置必須能夠非常迅速的完成
○ 資源通常是昂貴的
● 增加容量:自動新增 I...
補充: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
accom...
Q & A
66
SRE 方法論有哪些?舉例兩個
67
● 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● 在保障服務 SLO 的前提下,最大化迭代速度 (Pursuing Maximum Chang...
舉例 Dev & Ops 常見的問題
68
Próxima SlideShare
Cargando en…5
×

SRE Study Notes - Opening, CH1

SRE Study Notes.

SRE Study Notes - Opening, CH1

  1. 1. SRE: Site Reliability Engineering How Google Runs Production Systems Rick Hwang @ 91APP 2017/07/05 1
  2. 2. 2
  3. 3. Opening 3
  4. 4. 幾個問題 ● 系統上線前要做些什麼事? ● 系統上線過程要做什麼事? ● 系統上線後要做些什麼事? ● 系統上線後哪些事最重要? 4
  5. 5. 換個對象 ● 買車前要做些什麼事? ● 買車過程要做什麼事? ● 買車後要做些什麼事? ● 交車後哪些事最重要? 5
  6. 6. 能動就好? 6
  7. 7. 7
  8. 8. ● Site ○ *.google.com ○ gmail, driver, calendar, cloud ... ● Reliability: ○ 某個系統在指定的環境下,在指定的時間 內,成功持續執行某個功能的機率。 ● Engineering: ○ 工程方法、軟體工程、流程 Site Reliability Engineering 8
  9. 9. ● 重點在可靠性 (Reliability) ● 基本概念:任何系統如果沒有人能夠穩定的使用,就沒有存 在的意義。 Site Reliability Engineering 9
  10. 10. Site Reliability Engineer ● 是一種角色 (Role)、職務,像是 Manager, Developer, Tester/QA, SysOps, DevOps Engineer 10
  11. 11. 11
  12. 12. ● 討論 Principles、Practice、Management ○ 不是單純談技術,而是用講故事的方式,探討系統維運需要面對的 問題 ● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護 (Maintain) 為什麼選讀這本書? 12
  13. 13. SDLC (Software Development LifeCycle) 13 看見全 局?
  14. 14. 14 Keyword: DevOps
  15. 15. https://www.slideshare.net/warfan/devops-53161280 15
  16. 16. Provisioning Observation Pipeline Maintain Deployment Plan Development Test Operation 16By Rick Hwang Source: Software Development Lifecycle
  17. 17. 系統維運的五個重要任務 ● Provisioning ● Deployment ● Observation, and Monitor ● Maintenance ● Pipeline (Chain Tasks for CI / CD) 17 Ref: 淺談系統監控與 CloudWatch 的應用
  18. 18. ● 討論 Principles、Practice、Management ● 如何構建 (Build)、部署 (Deploy)、監控 (Monitor)、維護 (Maintain) Again:為什麼選讀這本書? 18
  19. 19. 另外:作者 - Benjamin Treynor Sloss 19 Ben Treynor Sloss SRE (名稱發明者), Google VP
  20. 20. 看看外面 20
  21. 21. 21
  22. 22. 22
  23. 23. https://www.indeed.com/q-Site-Reliability-Engineer-jobs.html 23
  24. 24. 角色 - 職責、權責、技能、專業 ● Site Reliability Engineer ● DevOps Engineer ● System Operator (SysOps) ● System Administroator 24 ● System Engineer - 以上全包了
  25. 25. 這本書,不會告訴你 ... 25
  26. 26. 黑魔法?奇技淫巧? 帶給你迷思? 26
  27. 27. http://www.infoq.com/cn/news/2017/06/U-no-Google 27
  28. 28. 28
  29. 29. 讀完了,下課! 29
  30. 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. 31. 不要以為 ... ● 讀過 Google SRE 你就是系統維運之神 ● 買了很貴的很棒的機器,就可以有很多流量,賺很多錢 ● 不要以為用了 AWS、GCP、Azure 就 NoOps 了!系統就不會倒 ● 有自動化測試就不用手動測試 ● 導入 Scrum、看板 就不會有衝突、能順利交付 ● ... 31
  32. 32. 32
  33. 33. 前言 (Foreword) ● 系統維運本質上是人與計算機共同參與的一項系統性工程 - Principles of Network and System Administration ● 系統管理工程師:他們很神秘,和公司內的體制與整個行業也格格不入 ● IT 行業大多自我封閉,交流甚少 ○ 整個軟體產業都在鼓吹厚顏無恥的 “Just show me the code” ○ ZYX as Code, ABC as an Service ● 這本書沒有萬靈丹,沒有什麼東西能解決一切的。 ● 不斷自省 33
  34. 34. 34 https://lkml.org/lkml/2000/8/25/132
  35. 35. 序言 (Preface) ● 軟體工程花很多時間再討論開發過程,很少討論之後的維護過程。 ○ Rick: 開發就是生孩子,維護是教育孩子;開發是 0-1,維運是 1-99 ● 統計顯示,軟體系統 40%-90% 的成本是在開發之後的維護過程 ● 錯誤的觀念:系統開發完之後,他就是『穩地的』 ○ Rick: 所以社會問題很多,生了就不教了 ● 應該有一個職務專注整個生命週期的管理,從設計、到部署、直到服務退役。 35
  36. 36. ● SRE 是 Engineer - 一個職務角色 ● SRE 關注的是可靠性 ○ 可靠性:某個系統能夠在指定環境下,成功持續執行某個功能的機率 ○ 可靠性就是安全性,越早關住越好 ● 任何系統沒有人可以穩定的使用,就沒存在的意義 ● SRE 是 Google VP (維運副總) 發明的 ○ 他的位置是副總 最重要的事 36
  37. 37. Apollo 7 ● 登陸月球計畫,軟體工程師 - Margaret Hamilton (MIT 教授) ● 按下 DSKY 鍵,系統就崩潰 ○ NASA 高層覺得機率太小,不需要修 ○ NASA 飛行員覺得不可能犯如此低級的錯,哈哈哈 ○ Margaret 在手冊著名:不可以跑 P01 程序,並寫下異常處理方法 ● Apollo 8 執行任務 ○ 飛行員意外觸發 P01 ○ 問題在有限時間被排除了 ● Margaret:『無論一個軟體系統運行原理掌握得多麽徹底,也不能阻止人犯意外 的錯誤。』 ○ “Software Engineer” 一詞是 Margaret 推廣定義的 37
  38. 38. 38
  39. 39. Part I Introduction 39
  40. 40. Chapter 1: Introduction 40 Ben Treynor Sloss SRE (名稱發明者), Google VP
  41. 41. Hope is not a stategy. 不能把運氣當做策略 41
  42. 42. 系統管理員 (System Admin) ● 系統管理員的工作是? ○ 就是打雜,做 Developer 不想做的?是這樣? ● 系統管理員日常工作與產品研發相差甚遠 ○ 不只遠,是天文單位才能衡量的 ○ 補充一個:產品開發和產品測試相差也很遠! ● 傳統的作分法:開發部門 (Dev)、維運部門 (Ops) ○ 應該還有產品部門、測試部門 ○ 合稱四大天王:PM、Dev、Test、Ops 42
  43. 43. 43
  44. 44. Dev & Ops 分離團隊的問題 直接成本 ● 系統管理依賴人工處理,隨著系統複雜度增加、部署規模變大 間接成本 - 溝通問題 ● 研發與維運人員背景、技術能力不同 ● 工作目標不同:對可靠度的理解要求不同 ● 部門之間的信任與尊重問題 - 常常上演,最後演變成政治問題 44
  45. 45. Dev & Ops 的分歧:版本更新、配置變更 ● 研發部門:快速構建與發佈 ● 維運部門:如何在值班期間避免發生故障 ○ 大部分的問題,都是部署之後導致的 ○ 不管是部署新的版本,還是配置的變更 45
  46. 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. 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. 48. ● 人員的招聘: ○ SRE 需要和產品研發部門競爭 ○ 同時要求多項技能,市場上同樣背景的人太少 ● 會寫程式的人,不見得懂系統,懂系統不見得懂網路 ● 懂系統不見得會規劃系統,懂網路不見得會規劃網路 SRE 的挑戰與問題 48
  49. 49. 49 System Admin & Operator System Developer Network Engineer
  50. 50. DevOps or SRE? 書本的解釋:SRE 是 DevOps 的實踐方式 以下是 Rick 的註解: ● DevOps Engineer 必須參與產品開發,熟悉軟體開發流程 ○ 跟 Developer, Tester 一樣,參與整個產品的開發流程,跟著產品專案時程跑 ○ 本身也是 Developer,而且有 Operator 經驗 ● SRE ○ 專注在系統可靠度,跟展品專案時程跑 ○ Google 的最佳實踐方法與管理精神 50
  51. 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. 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. 53. 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering) ● SRE 團隊的維運工作,限制在 50% 以內。 ● 管理人員 (Leader or Manager) 經常性地分配團隊成員的時間 ○ 採取暫時性措施,將過多的維運工作,轉回開發團隊處理 ● 處理維運工作的準則:8-12 小時的 on-call,最多處理兩個緊急事件 ○ 確保工程師有足夠時間處理緊急事件,並寫完成 異常報告 ● 所有的異常都要有事後總結,無論有沒觸發警報 ○ 如果異常事件沒有觸發報警,那揭露監控系統的漏洞與問題 ○ 報告要包含:事故發生、發現、解決的過程、根本原因、預防或者優化方法 53
  54. 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. 55. 錯誤預算 ● SRE 團隊目標不再是 “零事故” ● 解決研發團隊與 SRE 團隊的組織衝突 ● 使用錯誤預算最大化新功能上線的速度,同時保障服務質量,例如: ○ 技術戰略:A/B Test、 ● ”事故“ 不見得是壞事,而是流程中必須有的,兩個團隊一起處理的 55
  56. 56. 監控系統 (Monitoring) ● 服務品質和可用性的主要手段 ● 監控系統要有三個輸出: ○ 警急報警 (Alert):收到通知,要立即處理的,而且要避免再次出現 ○ 工單 (Ticket):接到通知要處理的,但不是立即性的 ○ 日誌 (Logging):事後分析的日誌,正常形況,沒人會去看 56
  57. 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. 58. 幾個提醒 - Rick ● 維運手冊紀錄的東西,是死的步驟,了解系統運作原理後,做出的判斷是活的 ● 如果步驟有二十、三十個,這是要縮減的,出問題的當下,要能夠一目瞭然 ● 如果維運都自動化了。。。會有的問題: ○ 最後大家知道能動了,但不知道為什麼會動 ○ CI / CD 能動了,但你知道過程做了些什麼? ○ 每個自動化,都要能 夠 Step by Step 被執行,執行後也要可以確認每個的狀態 ○ Step 跟 Step 可以分段執行 (設計 Pipeline Task 時會遇到的) 58
  59. 59. 變更管理 (Change Management) Production 70% 的問題,來自於某種部署變更造成的。變更管理最佳實踐原則: ● 採用漸進式部署機制 (Implementing progressive rollouts) ● 快速而準確定位問題點 (Quickly and accurately detecting problems) ● 出現問題時,可以安全地恢復 (Rolling back changes safely when problems arise) 59
  60. 60. 補充:變更管理的定義 - Rick ● CI / CD 改變算不算變更管理? ● 網路環境改變算不算? ● API、Libraries ● 作業系統版本、Patch 60
  61. 61. 需求預測與容量規劃 (Demand Forecasting and Capacity Planning) ● 有一個準確自然增長的預測模型 ○ 用戶增加,使用量上升,資源需求也上升 ● 規劃中必須有準確的非自然增長的需求來源統計 ○ 新功能的發布、商業推廣、其他商業面的因素 ● 必須要有週期性的壓力測試 SRE 要主導容量規劃與資源部署。 61
  62. 62. 資源部署 (Provisioning) ● 變更管理 (Change Management) 與容量規劃 (Capacity Planning) 的結合 ● 資源部署與配置必須能夠非常迅速的完成 ○ 資源通常是昂貴的 ● 增加容量:自動新增 Instnace 或者整個 Cluster ● 群集配置:網路、複雜平衡、Configuration 62
  63. 63. 補充:Provisioning Source: Resource Provisioning and DevOps 63
  64. 64. 效率與性能 (Efficiency and Performance) ● 資源的使用率 ● 影響使用率的因素: ○ 用戶需求(流量) ○ 可用容量和軟體的資源使用率 ● 透過合理部署和配置容量,以及預測模型,可以提升資源的使用率。 64
  65. 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. 66. Q & A 66
  67. 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. 68. 舉例 Dev & Ops 常見的問題 68

    Sé el primero en comentar

    Inicia sesión para ver los comentarios

  • kakashiliu

    Nov. 2, 2017
  • freezejonny

    Nov. 6, 2017
  • JustinChang31

    Dec. 14, 2017
  • CheyiLin4

    May. 1, 2018
  • AnnaYen1

    May. 6, 2018
  • kemditkb

    May. 18, 2018
  • superos

    May. 27, 2018
  • keithhung

    Jul. 1, 2018
  • GelisWu

    Jul. 15, 2018
  • jingtw

    Mar. 8, 2019
  • roberthutw

    Mar. 9, 2019
  • allanbian

    Mar. 9, 2019
  • fineaisa

    Mar. 9, 2019
  • IanLi1

    Mar. 17, 2019

SRE Study Notes.

Vistas

Total de vistas

4.886

En Slideshare

0

De embebidos

0

Número de embebidos

2.899

Acciones

Descargas

48

Compartidos

0

Comentarios

0

Me gusta

14

×