Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SRE Study Notes - CH2,3,4

SRE Study Notes.

  • Login to see the comments

SRE Study Notes - CH2,3,4

  1. 1. 1
  2. 2. Chapter 2 The Production Environment at Google From the Viewpoint of an SRE 2 https://research.google.com/pubs/105254.html
  3. 3. 簡介 Google 資料中心 3
  4. 4. 資料中心 - 硬體 4 ● 軟體服務器 (Server) ● 物理服務器 (Machine) ○ 10 台物理服務器組成一個 Rack ● 數台 Rack 組成一個 Row ● 一個或多個 Row 組成一個 Cluster (叢集) ● 多個 Cluster 組成一個資料中心 (Datacenter) ● 多個相鄰的資料中心組成一個園區 (Campus)
  5. 5. 資料中心 - 硬體 5
  6. 6. 資料中心 - 硬體 6 ● Swtich 是 Google 自己做的 - 叫做 Jupiter ● 網路用 Clos 連接 ● B4 基於 SDN (OpenFlow 協議) 建置,覆蓋全球
  7. 7. 物理服務器的系統軟體 - Borg 7
  8. 8. 物理服務器的系統軟體 - Borg 8 ● Kubernates (K8s) 的前身 ● Borg 負責執行 Job ● 每個 Job 由一個或多個 Task 組成 ● Borg 自己的 DNS 系統:Borg Name Service (BNS) ● 負責分配資源給每個 Task,像是需要 2CPU + 2G RAM ● Borg 會自己處理故障的 Instance
  9. 9. 儲存 9 ● 提供簡單的儲存叢集服務 ● 概念類似於 Lustre, HDFS ● 實作:Bigtable 、Spanner
  10. 10. 網路 ● 基於 OpenFlow 協議的 SDN ● 沒有用高級的 Router ● 計算最佳路徑 ● Borg 也負責分配網路頻寬 (Bandwith Enforcer, BwE) 10
  11. 11. 其他在資料中心裡的系統軟體 ● Lock Service: Chubby - The Chubby lock service for loosely-coupled distributed systems ● Monitoring and Alerting: Borgmon ● Software Infrastructure: ○ Remote Procedure Call (RPC) -> Stubby -> gRPC ○ Protocal Buffer: gRPC 傳輸格式,簡稱 Protobuf ● Development Environment: ○ 圍繞基礎建設,建構完整的開發環境 ○ 工程師如果遇到工作項目之外的組建問題,可以修改這個問題,並且提出 CL (ChangeList) ○ CL 會被測試框架測試,如果破壞了其他工作,就會通報提交者。 ○ CL 通過測試,會自動部署正式環境 11
  12. 12. 12
  13. 13. Chapter 3 Embracing Risk (擁抱風險) 13
  14. 14. Agenda 14 ● 管理風險 ● 度量服務的風險 ● 服務的風險容忍度 ● 辨別消費者服務的風險容忍度 ● 基礎設施服務的風險容忍度 ● 使用錯誤預算的目的 ● 錯誤預算的構建過程 ● 好處
  15. 15. 管理風險 (Managing Risk) 15 『可靠性』成本提升不是線性增加,而可能是 100 倍。原因歸咎如下: ● 冗余物理服務器 / 計算資源的成本 ● 機會成本 明確的將維運風險和業務風險對應起來
  16. 16. 度量服務的風險 (Measuring Serivce Risk) ● 將所有淺在因素,縮減為單一性能指標 ● 難以度量的,像是:用戶不滿、信任、品牌口碑、媒體報導 ● 指標:計劃外停機 ● 風險承受力指標:計劃外停機時間的可接受水平 ○ 翻譯:能接受多久,非預期的停機時間? 16 一天 2.5M Request,一天要少於 250 個錯 不見得每個 Request 都是平等的 一年可用性 99.99% 最多可以停 52.56 分鐘
  17. 17. 17 SLA Downtime Day Hour Min 99% 1% 3.65 87.6 5,256 99.5% 0.5% 1.852 43.8 2,628 99.9% 0.1% 0.365 8.76 525.6 99.99% 0.01% 0.0365 0.876 52.56 99.999% 0.001% 0.00365 0.0876 5.256 99.9999% 0.0001% 0.000365 0.00876 0.5256
  18. 18. ● 辨別消費者服務的風險容忍度 ● 基礎設施服務的風險容忍度 ● 兩者都從三個面相看:可用性目標、故障類型、成本 服務的風險容忍度 (Risk Tolerance of Services) 18
  19. 19. 辨別消費者服務的風險容忍度 ● 可用性目標 ○ 使用者期望的服務水準是什麼? ○ 這項服務關係到收入? ○ 這是個有償服務、免費服務? ○ 市場上,競爭對手的服務水平為何? ○ 這項服務是針對消費者還是企業? 19
  20. 20. ● 故障的類型 ○ 持續的低故障率和偶爾發生的全網中斷哪一個比較糟? ○ Case A: 網站部分圖檔無法顯示 ○ Case B: 網站使用者 A 看到使用者 B 的資料 ● 接受計畫內的常規服務中斷 辨別消費者服務的風險容忍度 20 → 盡快找到問題修復網站。 → 馬上把網站關掉,直到問題處理好。
  21. 21. ● 成本 ○ 建構和維運多一個零的可用性,收益會增加多少? ○ 額外的收入可以抵消付出的成本? 辨別消費者服務的風險容忍度 21 增加 0.09% 成本只要 900
  22. 22. 基礎設施服務的風險容忍度 基礎設施會有多個用戶,每個用戶需求都不一樣。以 Bigtable 為例: ● 可用性目標水平 ○ Bigtable 關注的是吞吐量 (throughput) ,而非可靠性 ● 故障類型 ○ Low latency / High throughput 是兩種不同用戶的需求,這兩種用戶的成功、失敗是相反的 ● 成本 ○ 建立兩個 Cluster: Low latency + high throughput ○ high throughput: 利用率高, 成本為 low latency 10%-50% 22
  23. 23. 使用錯誤預算 (Error Budget) 的目的 ● 軟體對故障的容忍度 ● 測試 ● 部署頻率 ● 金絲雀測試 (Canary) 的持續時間和大小 23
  24. 24. ● 錯誤預算提供一個明確、客觀的指標,決定服務在單一季度中,能接受說多少不 可靠性。 ● 實際作法 ○ 產品管理定義 SLO,確立服務季度中正常運行的時間 ○ 系統的 uptime 透過中立第三方監控系統 ● 範例: ○ 季度運行目標:99.999% ○ 錯誤預算:0.001% ○ 某個問題用了 0.0002% ,相當於佔用了 20% 的錯誤預算 錯誤預算 (Error Budget) 的建構過程 24
  25. 25. 關鍵點 25 ● 管理服務的可靠性在於風險管理,而風險管理的成本很高 ● 100% 不會是正確的可靠性目標 ● 錯誤預算的調整可以激勵 SRE 和產品研發團隊,強調共同責任。
  26. 26. 26
  27. 27. Chapter 4 Service Level Objectives 服務品質目標 27 https://www.linkedin.com/in/marc-alvidrez-56560/
  28. 28. Agenda 28 ● 服務品質術語 ● 服務指標 (SLI) 在實踐中的應用 ● 服務目標 (SLO) 在實踐中的應用 ● 服務協議 (SLA) 在實踐中的應用
  29. 29. 服務品質術語: SLI / SLO / SLA ● Service Level Indicator (SLI):服務品質具體的量化指標 ● Service Level Objectvie (SLO):SLI 的目標值、範圍值 ● Service Level Agreement (SLA) 29
  30. 30. 服務品質具體的量化指標,像是: ○ request latency ○ error rate ○ system throughput: request per second (RPS), query per second (QPS) ○ availability: SRE 重視的 SLI ○ durability (持久性):資料能夠完整保存間 Service Level Indicator (SLI) 30
  31. 31. 服務品質目標值、範圍值: ● latency < 500ms ● error rate < 1 RPS ● throughput > 100 RPS Service Level Objective (SLO) 31 ITIL: SLT (Service Level Target)
  32. 32. 32 https://en.wikipedia.org/wiki/Service_level_objective
  33. 33. 故事:Chubby 計畫性內停機 ● Chubby is Google’s lock service for loosely coupled distributed systems. ● 每個地理位置的服務都仰賴 Chubby ● Chubby 故障的頻率很低,導致其他人都以為他不會掛 ● 但是 SRE 知道 Chubby 出問題會影響很多服務 ● 解法: ○ SRE 保證達到一定的 SLO,但不會大幅度超越 ○ 每季度,真實故障沒有將 SLO 可用指標降低,SRE 就會安排死給你看可控性故障,將服務停 機! ○ 找出對 Chubby 不合理的依賴 ○ 強迫每個服務負責人要面對分散式系統的天生缺陷 33
  34. 34. 服務與用戶之間一個明確的、或不明確的協議,描述在達到或者沒有達到 SLO 之後 的後果。 ● 後果:財務方面的 -- 罰款、退款 ● 所以如果沒有定義『後果』,那就是在討論 SLO,而不是 SLA ● SLA 通常是與業務產品的決策有關 ● SRE 通常不會參與 SLA 的規劃 ● SRE 會參與 SLI 的制定、SLO 的量測 Service Level Agreement (SLA) 34
  35. 35. 服務指標 (SLI) 在實踐中的應用 35
  36. 36. 維運人員和最終用戶關心什麼 ● 不需要把所有的指標 (Metric) 都定義為 SLI ● 代表性的健康指標 4~5 個就夠了 ● SLI 常見的歸類 ○ User-facing serving systems: availability, latency, throughput ■ 所有人都關心的 ○ Storage systems: latency, availability, durability ○ Big data systems: data pipeline, throughtput, end-to-end latency ○ Correctness (正確性) 36
  37. 37. 指標的蒐集 ● borgmon (第十章) ● Prometheus ● 其他日誌分析系統 - ELK, Grafana, CloudWatch Log …. 37
  38. 38. Aggregation ● 蒐集指標,需要有原始度量 (Measure) 的資料 ● 應該每秒採樣 (Sample)?還是每分鐘? ● SRE 傾向分析百分比的數據,而不是平均值 ● 長尾效應比平均數更有特點 38
  39. 39. 指標標準化 標準化常見的 SLI,避免每次都重新評估 ● Aggregation intervals: “Averaged over 1 minute” ● Aggregation regions: “All the tasks in a cluster” ● How frequently measurements are made: “Every 10 seconds” ● Which requests are included: “HTTP GETs from black-box monitoring jobs” ● How the data is acquired: “Through our monitoring, measured at the server” ● Data-access latency: “Time to last byte” 39
  40. 40. 服務目標 (SLO) 在實踐中的應用 40
  41. 41. 目標的定義 ● SLO 具體定義 (可以有多個) ○ 90% Get RPC < 1ms ○ 99% Get RPC < 10ms ○ 99.9% Get RPC < 100ms ● 如果同時有批次處理用戶,以及即時用戶,SLO 可以是: ○ 批次: 95% Set RPC < 1s ○ 即時: (99% Set RPC + RPC Loading < 1K) < 10m ● 再次強調: SLO 100% 是不合理,也是高成本的 41
  42. 42. SLO 的選擇 ● Don’t pick a target based on current performance ○ 不能只看眼前,要從全局出發 ● Keep it simple ○ 太複雜的匯總,會難以理解,同時會掩蓋系統性的變化 ● Avoid absolutes (絕對值) ○ 要求擴展系統而沒有增加任何 latency ,或者永遠 Available 都是不切實際的 ● Have as few SLOs as possible ○ 選擇足夠的 SLO 覆蓋系統屬性 ● Perfection can wait (不完美也很美) ○ 隨著時間了解系統之後,進行 SLO 定義與調整。 42
  43. 43. 服務協議 (SLA) 實踐中的應用 ● SLA 需要業務單位、法務單位選擇適合的『後果』條款 ● 在 SLA 起草過程中,SRE 可以幫助理解 SLA 的 SLO 達標機率及難度 43
  44. 44. Summary ● SLA 是用來評量『後果』條款的標準,最常用的是 ○ availability 99.99% year ○ durability 99.9999999% year ● SLA 由多個 SLO 組成 44
  45. 45. Q & A AWS S3 的 11 個 9 是代表什麼? ● SLA ● SLO ● SLI 45

×