本文件讨论了Google的数据中心及其生产环境，着重介绍了关键的软硬件组件，如Borg和Chubby锁服务。它还探讨了风险管理的重要性，特别是如何通过错误预算和服务级别目标(SLO)来有效控制服务的可用性和稳定性。最后，文件定义了服务级别协议(SLA)及其在实践中的应用，强调了用以评估服务结果的标准。

1. 1

2. Chapter 2
The Production Environment at Google
From the Viewpoint of an SRE
2
https://research.google.com/pubs/105254.html

3. 簡介 Google 資料中心
3

4. 資料中心 - 硬體
4
● 軟體服務器 (Server)
● 物理服務器 (Machine)
○ 10 台物理服務器組成一個 Rack
● 數台 Rack 組成一個 Row
● 一個或多個 Row 組成一個 Cluster (叢集)
● 多個 Cluster 組成一個資料中心 (Datacenter)
● 多個相鄰的資料中心組成一個園區 (Campus)

5. 資料中心 - 硬體
5

6. 資料中心 - 硬體
6
● Swtich 是 Google 自己做的 - 叫做 Jupiter
● 網路用 Clos 連接
● B4 基於 SDN (OpenFlow 協議) 建置，覆蓋全球

7. 物理服務器的系統軟體 - Borg
7

8. 物理服務器的系統軟體 - Borg
8
● Kubernates (K8s) 的前身
● Borg 負責執行 Job
● 每個 Job 由一個或多個 Task 組成
● Borg 自己的 DNS 系統：Borg Name Service (BNS)
● 負責分配資源給每個 Task，像是需要 2CPU + 2G RAM
● Borg 會自己處理故障的 Instance

9. 儲存
9
● 提供簡單的儲存叢集服務
● 概念類似於 Lustre, HDFS
● 實作：Bigtable 、Spanner

10. 網路
● 基於 OpenFlow 協議的 SDN
● 沒有用高級的 Router
● 計算最佳路徑
● Borg 也負責分配網路頻寬 (Bandwith Enforcer, BwE)
10

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

13. Chapter 3
Embracing Risk (擁抱風險)
13

14. Agenda
14
● 管理風險
● 度量服務的風險
● 服務的風險容忍度
● 辨別消費者服務的風險容忍度
● 基礎設施服務的風險容忍度
● 使用錯誤預算的目的
● 錯誤預算的構建過程
● 好處

15. 管理風險 (Managing Risk)
15
『可靠性』成本提升不是線性增加，而可能是 100 倍。原因歸咎如下：
● 冗余物理服務器 / 計算資源的成本
● 機會成本
明確的將維運風險和業務風險對應起來

16. 度量服務的風險 (Measuring Serivce Risk)
● 將所有淺在因素，縮減為單一性能指標
● 難以度量的，像是：用戶不滿、信任、品牌口碑、媒體報導
● 指標：計劃外停機
● 風險承受力指標：計劃外停機時間的可接受水平
○ 翻譯：能接受多久，非預期的停機時間？
16
一天 2.5M Request，一天要少於 250 個錯
不見得每個 Request 都是平等的
一年可用性 99.99% 最多可以停 52.56 分鐘

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. ● 辨別消費者服務的風險容忍度
● 基礎設施服務的風險容忍度
● 兩者都從三個面相看：可用性目標、故障類型、成本
服務的風險容忍度 (Risk Tolerance of Services)
18

19. 辨別消費者服務的風險容忍度
● 可用性目標
○ 使用者期望的服務水準是什麼？
○ 這項服務關係到收入？
○ 這是個有償服務、免費服務？
○ 市場上，競爭對手的服務水平為何？
○ 這項服務是針對消費者還是企業？
19

20. ● 故障的類型
○ 持續的低故障率和偶爾發生的全網中斷哪一個比較糟？
○ Case A: 網站部分圖檔無法顯示
○ Case B: 網站使用者 A 看到使用者 B 的資料
● 接受計畫內的常規服務中斷
辨別消費者服務的風險容忍度
20
→ 盡快找到問題修復網站。
→ 馬上把網站關掉，直到問題處理好。

21. ● 成本
○ 建構和維運多一個零的可用性，收益會增加多少？
○ 額外的收入可以抵消付出的成本？
辨別消費者服務的風險容忍度
21
增加 0.09% 成本只要 900

22. 基礎設施服務的風險容忍度
基礎設施會有多個用戶，每個用戶需求都不一樣。以 Bigtable 為例：
● 可用性目標水平
○ Bigtable 關注的是吞吐量 (throughput) ，而非可靠性
● 故障類型
○ Low latency / High throughput 是兩種不同用戶的需求，這兩種用戶的成功、失敗是相反的
● 成本
○ 建立兩個 Cluster: Low latency + high throughput
○ high throughput: 利用率高, 成本為 low latency 10%-50%
22

23. 使用錯誤預算 (Error Budget) 的目的
● 軟體對故障的容忍度
● 測試
● 部署頻率
● 金絲雀測試 (Canary) 的持續時間和大小
23

24. ● 錯誤預算提供一個明確、客觀的指標，決定服務在單一季度中，能接受說多少不
可靠性。
● 實際作法
○ 產品管理定義 SLO，確立服務季度中正常運行的時間
○ 系統的 uptime 透過中立第三方監控系統
● 範例：
○ 季度運行目標：99.999%
○ 錯誤預算：0.001%
○ 某個問題用了 0.0002% ，相當於佔用了 20% 的錯誤預算
錯誤預算 (Error Budget) 的建構過程
24

25. 關鍵點
25
● 管理服務的可靠性在於風險管理，而風險管理的成本很高
● 100% 不會是正確的可靠性目標
● 錯誤預算的調整可以激勵 SRE 和產品研發團隊，強調共同責任。

26. 26

27. Chapter 4
Service Level Objectives
服務品質目標
27
https://www.linkedin.com/in/marc-alvidrez-56560/

28. Agenda
28
● 服務品質術語
● 服務指標 (SLI) 在實踐中的應用
● 服務目標 (SLO) 在實踐中的應用
● 服務協議 (SLA) 在實踐中的應用

29. 服務品質術語: SLI / SLO / SLA
● Service Level Indicator (SLI)：服務品質具體的量化指標
● Service Level Objectvie (SLO)：SLI 的目標值、範圍值
● Service Level Agreement (SLA)
29

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. 服務品質目標值、範圍值：
● latency < 500ms
● error rate < 1 RPS
● throughput > 100 RPS
Service Level Objective (SLO)
31
ITIL: SLT (Service Level Target)

32. 32
https://en.wikipedia.org/wiki/Service_level_objective

33. 故事：Chubby 計畫性內停機
● Chubby is Google’s lock service for loosely coupled distributed systems.
● 每個地理位置的服務都仰賴 Chubby
● Chubby 故障的頻率很低，導致其他人都以為他不會掛
● 但是 SRE 知道 Chubby 出問題會影響很多服務
● 解法：
○ SRE 保證達到一定的 SLO，但不會大幅度超越
○ 每季度，真實故障沒有將 SLO 可用指標降低，SRE 就會安排死給你看可控性故障，將服務停
機！
○ 找出對 Chubby 不合理的依賴
○ 強迫每個服務負責人要面對分散式系統的天生缺陷
33

34. 服務與用戶之間一個明確的、或不明確的協議，描述在達到或者沒有達到 SLO 之後
的後果。
● 後果：財務方面的 -- 罰款、退款
● 所以如果沒有定義『後果』，那就是在討論 SLO，而不是 SLA
● SLA 通常是與業務產品的決策有關
● SRE 通常不會參與 SLA 的規劃
● SRE 會參與 SLI 的制定、SLO 的量測
Service Level Agreement (SLA)
34

35. 服務指標 (SLI) 在實踐中的應用
35

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. 指標的蒐集
● borgmon (第十章)
● Prometheus
● 其他日誌分析系統 - ELK, Grafana, CloudWatch Log ….
37

38. Aggregation
● 蒐集指標，需要有原始度量 (Measure) 的資料
● 應該每秒採樣 (Sample)？還是每分鐘？
● SRE 傾向分析百分比的數據，而不是平均值
● 長尾效應比平均數更有特點
38

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. 服務目標 (SLO) 在實踐中的應用
40

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. 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. 服務協議 (SLA) 實踐中的應用
● SLA 需要業務單位、法務單位選擇適合的『後果』條款
● 在 SLA 起草過程中，SRE 可以幫助理解 SLA 的 SLO 達標機率及難度
43

44. Summary
● SLA 是用來評量『後果』條款的標準，最常用的是
○ availability 99.99% year
● SLA 由多個 SLO 組成
44

45. Q & A
● SLA
● SLO
● SLI
45