前言 xxxi

序言 xxxv

站點可靠性工程師(SRE, Site Reliability Engineering)。

使用示例代碼

補充材料可以到http://g.co/SREBook下載。

第Ⅰ部分　概覽

第1 章　介紹 2

系統管理員模式 2

研發部門最關注的是如何能夠更快速地構建 和發布新功能。運維部門更關注的是如何能在他們值班期間避免發生 故障。由于絕大部分生產故障都是由于部署某項變更導致的—不管是 部署新版本，還是修改配置，甚至有時只是因為改變了用戶的某些行 為造成了負載流量的配比變化而導致故障。這兩個部門的目標從本質 上來說是互相矛盾的。

運維團隊常常宣稱，任何變更 上線前必須經過由運維團隊制定的流程，這有助于避免事故的發生。

而開發團隊吃過苦頭 之后也很快找到了自己的應對辦法：開發團隊宣稱他們不再進行大規 模的程序更新，而是逐漸轉為功能開關調整、增量更新，以及補丁化。采用這些名詞的唯一目的，就是為了繞過運維部門設立的各種流 程，從而能更快地上線新功能。

Google 的解決之道：SRE 4

SRE 這種模型是Google嘗試著從根本上避免產生這種矛盾的結 果。SRE團隊通過雇傭軟件工程師，創造軟件系統來維護系統運行以替 代傳統模型中的人工操作。

SRE團隊成員 具有如下特點：
（a）對重復性、手工性的操作有天然的排斥感。
（b）有足夠的技術能力快速開發出軟件系統以替代手工操作。

SRE 方法論 6

一般來說， SRE團隊要承擔以下幾類職責：可用性改進，延遲優化，性能優化，效 率優化，變更管理，監控，緊急事務處理以及容量規劃與管理。

確保長期關注研發工作 6

在保障服務SLO 的前提下最大化迭代速度 7

如果100% 不是一個正確的可靠性目標，那么多少才是呢？這其實 并不是一個技術問題，而是一個產品問題。要回答這個問題，必須考 慮以下幾個方面：

• 基于用戶的使用習慣，服務可靠性要達到什么程度用戶才會滿 意？
• 如果這項服務的可靠程度不夠，用戶是否有其他的替代選擇？
• 服務的可靠程度是否會影響用戶對這項服務的使用模式？

公司的商業部門或者產品部門必須建立起一個合理的可靠性目 標。一旦建立，“錯誤預算”就是“1-可靠性目標”。如果一個服務 的可靠性目標是99.99%，那么錯誤預算就是 0.01%。這意味著產品研 發部門和SRE部門可以在這個范圍內將這個預算用于新功能上線或者產 品的創新等任何事情。

監控系統 8

但是這樣的報警策略并不是非常有效：一個需 要人工閱讀郵件和分析警報來決定目前是否需要采取某種行動的系統 從本質上就是錯誤的。
一個監控系統應該只有三類輸出。

• 緊急警報（alert）意味著收到警報的用戶需要立即執行某種操作
• 工單（ticket）意味著接受工單的用戶應該執行某種操作，
• 日志（logging）但是日志信息依然被收集起來以 備調試和事后分析時使用。

應急事件處理 8

可靠性是MTTF（平均失敗時間）和MTTR（平均恢復時間）的函數。
但是長久看來一個手持“運維寶 典”經過多次演習的on-call工程師才是正確之路。

變更管理 9

SRE的經驗告訴我們，大概 70% 的生產事故由某種部署的變更而 觸發。

• 采用漸進式發布機制。
• 迅速而準確地檢測到問題的發生。
• 當出現問題時，安全迅速地回退改動。

需求預測和容量規劃 9
資源部署 10
效率與性能 10
小結 10

第2 章　Google 生產環境：SRE 視角 11

硬件 11
管理物理服務器的系統管理軟件 13
管理物理服務器 13
存儲 14
網絡 15
其他系統軟件 16
分布式鎖服務 16
監控與警報系統 16

軟件基礎設施 17

通常來說，一個軟件服務器從該服務的前端（frontend）接收RPC 請求，同時將另外一些RPC發往該服務器的后端（backend）。一般來 說，前端被稱為客戶端（client），后端被稱為服務端（server）。

研發環境 17

莎士比亞搜索：一個示范服務 18

批處理部分可以用MapReduce框架完成，三個階段的實現分別如下 所示。

• Mapping 階段：該程序遍歷所有的莎士比亞的文字，將其分成 具體的單詞。這項任務可以利用多實例并行加速。
• Shuffle 階段：該程序將上一階段產生的所有單詞和位置等進 行排序。
• Reduce 階段：將上一階段產生的單詞或位置等按單詞合并， 產生一個新的單詞或位置列表。

用戶請求的處理過程 18

后端服務器將其回復給Shakespeare前端服務器，前端服務 器最終根據這個數據結構構建HTML回復給最終用戶。

任務和數據的組織方式 19

第Ⅱ部分　指導思想

第3 章　擁抱風險 23

管理風險 23

可靠性進一步 提升的成本并不是線性增加的—可靠性的下一個改進可能比之前的改 進成本增加100倍。高昂的成本主要存在于以下兩個維度。

• 冗余物理服務器/計算資源的成本
• 機會成本。這些工程師不能再從事為終端用戶設計新功能和新產品的工作。

度量服務的風險 24

Google標準做法是通過一個客觀的指標來體現一個待優化的系統 屬性。
對于大多數服務而言，最直接的能夠代表風險承受能力的指標就 是對于計劃外停機時間的可接受水平。
公式3-1：基于時間的可用性
可用性=系統正常運行時間/（系統正常運行時間+停機時間）
舉例來說，一個可用性目標為99.99%的 系統最多在一年中停機52.56分鐘，就可以達到預計的可用性目標；詳 情參見附錄A。

公式3-2：合計可用性
可用性=成功請求數/總的請求數
例如，一個每天可用性目標為99.99%的系統，一天要接受2.5M個 請求。它每天出現少于250個錯誤即可達到預計的可用性目標。

服務的風險容忍度 25
辨別消費者服務的風險容忍度 26
基礎設施服務的風險容忍度 28

使用錯誤預算的目的 30

下面列舉一些典型的緊張局勢。

• 軟件對故障的容忍度
• 測試。而過于強調測試可能會失 去市場先機。
• 發布頻率。每一次發布都是有風險的。我們應該花多少時間在減少風險上？
• 金絲雀測試（Canary）的持續時間和大小。我們要等多久，而 且測試范圍有多大？

相反，我們的目標是定義一個雙方都同意的客觀指標，該指標可 以用來指導談判的方向。一項決策越是基于數據做出的，常常就越 好。

錯誤預算的構建過程 31

我們的實際做法如下：

• 產品管理層定義一個SLO，確定一項服務在每個季度預計的正 常運行時間。
• 實際在線時間是通過一個中立的第三方來測算的：我們的監控 系統。
• 這兩個數字的差值就是這個季度中剩余的不可靠性預算。
• 只要測算出的正常在線時間高于SLO，也就是說，只要仍然有 剩余的錯誤預算，就可以發布新的版本。

好處 32

第4 章　服務質量目標 34

服務質量指標（SLI）、服務質量目標 （SLO），以及服務質量協議（SLA）。

服務質量術語 34

指標 34

SLI是指服務質量指標（indicator）—該服務的某項服務質量的 一個具體量化指標。

目標 35

SLO是服務質量目標（Objective）：服務的某個SLI的目標值，或 者目標范圍。

協議 36

SLA是服務質量協議（Agreement）：指服務與用戶之間的 一個明確的，或者不明確的協議，描述了在達到或者沒有達到SLO之后 的后果。

指標在實踐中的應用 37
運維人員和最終用戶各關心什么 37
指標的收集 37
匯總 38
指標的標準化 39

目標在實踐中的應用 39

目標的定義 40

目標的選擇 40

• 不要僅以目前的狀態為基礎選擇目標。但是僅僅按照當前系統的 標準制定目標，而不從全局出發，可能會導致團隊被迫長期運維一個 過時的系統，沒有時間去推動架構重構等任務。
• 保持簡單
• 避免絕對值
• SLO越少越好
• 不要追求完美

控制手段 42
SLO 可以建立用戶預期 42
協議在實踐中的應用 43

第5 章　減少瑣事 44

瑣事的定義 44

每件瑣 事都滿足下列一個或多個屬性：

• 手動性
• 重復性的
• 可以被自動化的
• 戰術性的
• 沒有持久價值
• 與服務同步線性增長

為什么瑣事越少越好 45

SRE的一個公開目標是保持每個SRE的工作時間中運維工作（即瑣 事）的比例低于50%。SRE至少花50%的時間在工程項目上，以減少未來 的瑣事或增加服務功能。

什么算作工程工作 46

工程工作（Engineering）是一種新穎的、本質上需要主觀判斷的 工作。它是符合長期戰略的，會對你的服務進行長久性的改善的工 作。
典型的SRE活動分為如下幾類。

• 軟件工程。編寫或修改代碼
• 系統工程。的架構、設計和生產環境方面的 咨詢工作。
• 瑣事
• 流程負擔。與運維服務不直接相關的行政工作。例如招聘

瑣事繁多是不是一定不好 47

在許多瑣事有害的原因中，有如下因素需要考慮：

• 職業停滯
• 士氣低落。過多的瑣事會導致過度勞累、厭倦和不滿。

做瑣事會對SRE組織的整體發展造成損害， 原因如下：

• 造成誤解
• 進展緩慢
• 開創先例。如果SRE過于愿意承擔瑣事，研發同事就更傾向于加入更多的瑣事
• 促進摩擦產生
• 違反承諾。及轉入SRE的老員工會 有被欺騙的感覺
  小結 48

第6 章　分布式系統的監控 49

術語定義 49

• 監控（monitoring）。收集、處理、匯總，并且顯示關于某個系統的實時量化數據
• 監控臺頁面（dashboard）。提供某個服務核心指標一覽服務的應用程序（一般是基于Web 的）。
• 警報（alert）。 目標對象是某個人發向某個系統地址的一個通知。
• 根源問題（root cause）。 指系統（軟件或流程）中的某種缺陷。

為什么要監控 50

對監控系統設置合理預期 51

一般來說，Google趨向于使用簡單和快速的監控系統配合高效的 工具進行事后分析。我們會避免任何“魔法”系統—例如試圖自動學 習閾值或者自動檢測故障原因的系統。
監控系統信噪比應該很高，發出緊急警報的組件需要非 常簡單而且可靠。產生警報的監控系統規則應該非常容易理解，同時 代表一個清晰的故障場景。

現象與原因 52

監控系統應該解決兩個問題：什么東西出故障了，以及為什么出 故障。
“什么東西出故障了”即為現象（symptom）:“為什么”則代表 了原因（可能只是中間原因，并不是根源問題）。
“現象”和“原因”的區分是構建信噪比高的監控系統時最重要 的概念。

黑盒監控與白盒監控 53

4 個黃金指標 53

如果我們只能監控用戶可見系統的4個指標，那么就 應該監控這4個。

• 延遲。 服務處理某個請求所需要的時間。
• 流量。 使用系統中的某個高層次的指標針對系統負載需求所進行的度 量。
• 錯誤。 請求失敗的速率，要么是顯式失?。ɡ鏗TTP 500），要么是隱 式失敗（例如HTTP 200 回復中包含了錯誤內容）
• 飽和度。 服務容量有多“滿”。通常是系統中目前最為受限的某種資源的 某個具體指標的度量。（在內存受限的系統中，即為內存；在I/O受限 的系統中，即為I/O）。

關于長尾問題 54

區分平均值的“慢”和長尾值的“慢”的一個最簡單辦法是將請 求按延遲分組計數（可以用來制作直方圖）：延遲為0～10ms之間的請 求數量有多少，30～100ms之間，100～300ms之間等。

度量指標時采用合適的精度 55
簡化，直到不能再簡化 55
將上述理念整合起來 56
監控系統的長期維護 57
Bigtable SRE ：警報過多的案例 57
Gmail ：可預知的、可腳本化的人工干預 58
長跑 59
小結 59

第7 章　Google 的自動化系統的演進 60

自動化的價值 60

一致性 60

平臺性 61

一個平臺同時也將錯誤集中化了。

修復速度更快 61

可以降低一些常見故障的平均修復時間（MTTR）。

行動速度更快 62
節省時間 62
自動化對Google SRE 的價值 62
自動化的應用案例 63
Google SRE 的自動化使用案例 63
自動化分類的層次結構 64
讓自己脫離工作：自動化所有的東西 66

舒緩疼痛：將自動化應用到集群上線中 67

使用Prodtest 檢測不一致情況 68
冪等地解決不一致情況 69

專業化傾向 71

最可用的工具通常是由那些每天使用它們的人寫成的。

以服務為導向的集群上線流程 72

集群上線自動化進化遵循這樣一個路徑：
1.操作人員觸發手動操作（無自動化）。
2.操作人員編寫，系統特定的自動化。
3.外部維護的通用自動化。
4.內部維護，系統特定的自動化。
5.不需要人為干預的自治系統。

Borg ：倉庫規模計算機的誕生 73
可靠性是最基本的功能 74
建議 75

第8 章　發布工程 76

發布工程（Release Engineering）簡單來說，這個學科專注于構建和交付軟件。發布工程師通常對源代碼管理、編譯器、構建配置語 言、自動化構建工具、包管理器和安裝器等非常了解（甚至是這方面 的專家）。

發布工程師的角色 76

發布工程哲學 77

自服務模型 77

發布工程師 開發工具，制定最佳實踐，以便讓產品研發團隊可以自己掌控和執行 自己的發布流程。

追求速度 77

還有的團隊采用一種“測試通過 即發布”（Push On Green）的發布模型

密閉性 77

構建工具必須確保一致性和可重復性。構建 過程使用指定版本的構建工具（編譯器），同時使用指定版本的依賴 庫（第三方類庫）。編譯過程是自包含的，不依賴于編譯環境之外的 其他服務。

強調策略和流程 78

• 批準源代碼改動—通過源代碼倉庫中的配置文件決定。
• 批準初始的集成請求
• 實際部署某個發布版本。

持續構建與部署 78
構建 78
分支 79
測試 79
打包 79
Rapid 系統 80
部署 81
配置管理 81
小結 82
不僅僅只對Google 有用 83
一開始就進行發布工程 83

第9 章　簡單化 85

軟件系統本質上是動態的和不穩定的。

系統的穩定性與靈活性 85
乏味是一種美德 86

我絕對不放棄我的代碼 86

源代碼控制 系統中的更改反轉很容易，數百行的注釋代碼則會造成干擾和混亂 （尤其是當源文件繼續演進時）；那些由于功能開關沒有啟用而沒有 被執行的代碼，就像一個定時炸彈一樣等待爆炸。

“負代碼行”作為一個指標 87

最小 API 87

法國詩人 Antoine de Saint Exupery 曾寫道，“不是在不能添 加更多的時候，而是沒有什么可以去掉的時候，才能達到完美?！边@個原則同樣適用于軟件的設計和構建。
書寫一個明確的、最小的API 是管理軟件系統管理簡單性必要的 部分。我們向API消費者提供的方法和參數越少，這些API就越容易理 解

模塊化 87
發布的簡單化 88
小結 88

第Ⅲ部分　具體實踐

監控

在第10章將討論有關警報系統的設計哲學和工具。

應急事件處理

在第11章中，將詳細解釋我們是如 何平衡on-call輪值與其他工作的。
在第12章中，我們提供了一套結構化方案來解決問題的第一步： 找到問題所在。
在第13章和第14章中，我們討論了如何通過 合理的流程有效地減小事故的影響范圍，以緩解整個部門由生產事故 帶來的壓力。

事后總結和問題根源分析

第15章，描述了如何建立起“無指責”、“對事不對人”的團隊 文化
第16章，在這個基礎上，我們簡要描述了一個內部工具，事故跟 蹤系統。

測試

保證軟件在發布到生產環境中時 不會出現某些類型的問題。在第17章中詳細描述了相關的最佳實踐。

容量規劃

在第18章中，我們給出了一個具體的工具開發實踐案例。SRE 利 用Google 內部工具Auxon，自動化進行服務容量規劃。
在第19章中，我們討論了用戶請求是如何發送到數 據中心的。在第20章和第21章中，我們詳細描述了數據中心中的負載 均衡體系是保障服務可靠度的關鍵。 最后，在第22章中，我們討論了如何從系統設計層面與戰術層面 應對“連鎖故障”。

軟件研發

在第23章中，我們解釋了Google許多系統的核心組件—“分布式 共識”系統（Paxos的新說法），在第 24章中，我們描述了SRE是如何設計和部署一個跨數據中心的定時任務 系統的。第25章描述了批量數據處理系統的幾種形態：從定時運行的 MapReduce程序，到實時數據處理系統。
在第26章中，我們詳細描述了數據一致性的重要性

產品設計

在第27章中，我們描述了處于整個可靠度金字塔模型頂端 的產品設計理念。

第10 章　基于時間序列數據進行有效報警 93

Borgmon 的起源 94
應用軟件的監控埋點 95
監控指標的收集 96

時間序列數據的存儲 97

些數據都是以類似 （timestamp,value）的格式存儲在一個按時間排序的鏈表里，該鏈表稱為Ti m eseries。

標簽與向量 98
Borg 規則計算 99
報警 104
監控系統的分片機制 105
黑盒監控 106
配置文件的維護 106
十年之后 108

第11 章　on-call 輪值 109

介紹 109
on-call 工程師的一天 110

on-call 工作平衡 111

數量上保持平衡 111

多地團隊相比之下有以下兩點優勢：

• 長時間執行夜間任務對人的健康不利（參見文獻[Dur05]）。 多地團隊可以利用“日出而作，日落而息”（Follow the sun）的輪 值制度使整個團隊避免夜間值班。

質量上保持平衡 111
補貼措施 112
安全感 112
避免運維壓力過大 114
運維壓力過大 114
奸詐的敵人—運維壓力不夠 115
小結 115

第12 章　有效的故障排查手段 116

理論 117

針對某系統的 一些觀察結果和對該系統運行機制的理論認知，我們不斷提出一個造成系統問題的假設，進而針 對這些假設進行測試和排除。

[!NOTE]
常見的陷阱
造成低效的故障排查過程的原因通常集中在定位（triage）、檢查和診斷環節上，主要由于對 系統不夠了解而導致。下面列舉了一系列常見的陷阱，讀者應該小心避免：

• 關注了錯誤的系統現象，或者錯誤地理解了系統現象的含義。這樣會在錯誤的方向上浪費 時間。
• 將問題過早地歸結為極為不可能的因素，或者念念不忘之前曾經發生過的系統問題， 認為一旦發生過一次，就有可能再次發生。
• 試圖解決與當前系統問題相關的一些問題，卻沒有認識到這些其實只是巧合，或者這些問 題其實是由于當前系統的問題造成的。

最后，我們要記住，相關性（correlation）不等于因果關系（causation）。一些同時出現的 現象，例如集群中的網絡丟包現象和硬盤損壞現象可能是由同一個原因造成的，比如說供電故 障。但是網絡丟包現象并不是造成硬盤損壞現象的原因，

實踐 119

故障報告 119

有效的故障報告應該寫清預期是什么，實際的結果是什么，以及如何重現。

定位 119
檢查 120

診斷 122

簡化和縮略

如果系統有配套的測試用例，那么調試起來就會 很容易。甚
問題分解（Divide & Conquer）也是一個非常有用的通用解決方案。最好的辦法通常是從系統的一端開始，逐個檢查每一個組 件，直到系統最底層。這樣的策略非常適用于數據處理流水線。在大型系統中，逐個檢查可能太 慢了，可以采用對分法（bisection）將系統分為兩部分，確認問題所在再重復進行。

“什么”“哪里”和“為什么”

那么找出系統目前正在執行“什么”，然后通過詢問該系統“為什么”正在做這些操作， 以及系統的資源都被用在了“哪里”可以幫助你了解系統為什么出錯。

最后一個修改

計算機系統有慣性存在：我們發現，一個正常工作的計算機系統會維持工作，直到某種外力 因素出現
通過將系統的環 境改變與系統性能和行為進行對比，可能比較有用。例如，在服務的監控頁面上，你可以將系統 的錯誤率圖表和新版本的部署起始時間和結束時間標記在一起，

有針對性地進行診斷

雖然前面論述的通用性工具在很多問題上都很有用，但是針對具體系統開發的診斷工具和診 斷系統會更有用。

測試和修復 124

在設計測試時，有一些考量必須時刻記住。

• 一個理想的測試應該具有互斥性，通過執行這個測試，可以將一組假設推翻
• 先測試最可能的情況：按照可能發生的順序執行測試，先測試網絡連通性，再檢查是否是最近的配置文件改變導致用戶無法訪問某機器可能更合 理。
• 某項測試可能產生有誤導性的結果。
• 執行測試可能會帶來副作用。
• 某些測試無法得出準確的結論，只是建議性的。

將你的想法明確地記錄下來，包括你執行了哪些測試，以及結果是什么。良好的文檔可以讓你記住曾經發生過什么，可避免重復執行。

神奇的負面結果 125

負面結果不應該被忽略，或者被輕視。 意識到自己的錯誤通常意義更大：一個明確的負面結 果可以給某些最難的設計問題畫上句號。一個團隊經常同時有兩個看起來可行的設計方向可供選 擇
一項試驗中出現的負面結果是確鑿的。 這些結果確切地告訴了我們有關生產環境中的信息、 設計理念對錯或者現有系統的性能極限。
工具和方法可能超越目前的試驗，為未來的工作提供幫助。 將 這些測試寫成腳本有助于保證在下一個項目中你不會忘記和錯過好的優化點。
公布負面結果有助于提升整個行業的數據驅動風氣。

治愈 126

下一步，我們想要證明這 就是問題根源。在生產環境中試圖通過重現一個原因而明確地證明它就是問題的原因是很困難 的。因為如下幾個原因，我們經常只能發現可能的原因。

• 系統復雜度。很有可能有多個因素共同作用導致系統問題。它們必須處于一個特定狀態下問題才會發生。
• 在生產環境中重現某個問題也許是不可能的。要么因為將系統置于某種問題狀態過于復 雜，或者是系統過于重要，不能再出問題。

你是如何定位問題的， 和你是如何修復問題的，如何防止再次發生等寫下來。這就是事后總結。

案例分析 127
使故障排查更簡單 130
小結 130

第13 章　緊急事件響應 131

當系統出現問題時怎么辦 131
測試導致的緊急事故 132
細節 132
響應 132
事后總結 132
變更部署帶來的緊急事故 133
細節 133
事故響應 134
事后總結 134
流程導致的嚴重事故 135
細節 135
災難響應 136
事后總結 136
所有的問題都有解決方案 137

向過去學習，而不是重復它 138

為事故保留記錄 138

歷史就是學習 其他人曾經犯的錯誤。提出關鍵的問題。時刻尋找如何能在戰術及戰略上避 免這項事故的發生。

提出那些大的，甚至不可能的問題：假如…… 138

我們應該提出一些大的、沒有 確切答案的問題。假如整棟大樓的電源壞了怎么辦？

鼓勵主動測試 138
小結 138

第14 章　緊急事故管理 140

如果事先沒有針對可能發生的緊急事故進行過演習，那么當事故 發生時，一切管理理念都起不了作用。

無流程管理的緊急事故 140
對這次無流程管理的事故的剖析 141
過于關注技術問題 141
溝通不暢 141
不請自來 142

緊急事故的流程管理要素 142

嵌套式職責分離 142

在事故處理中，讓每個人清楚自己的職責是非常重要的。
以下是系統中可以分配給某個人的角色。

• 事故總控（incident command）。他們負責組建事故處 理團隊，按需求和優先級將一些任務分配給團隊成員。
• 事務處理團隊（operational work）。負 責指揮團隊具體執行合適的事務來解決問題。
• 發言人（communication）。該人是本次事故處理團隊的公眾發言人。他的職責包括向事故處 理團隊和所有關心的人發送周期性通知（通常以電子郵件形式）
• 規劃負責人（planning）。負責處理一些持續性 工作，例如填寫Bug報告記錄系統，給事務處理團隊訂晚餐，安排職責 交接記錄。

控制中心 143

可以設立一個“作戰室”（war room），將處 理問題的全部成員挪到該地辦公。

實時事故狀態文檔 143

事故總控負責人最重要的職責就是要維護一個實時事故文檔。

明確公開的職責交接 143

超出工作時間以后，事故總控負責人的職責能夠明確、公開地進 行交接是很重要的。

一次流程管理良好的事故 144

什么時候對外宣布事故 144

如果下面任何一條滿足條件，這次事故應該被及時宣布。

• 是否需要引入第二個團隊來幫助處理問題？
• 這次事故是否正在影響最終用戶？
• 在集中分析一小時后，這個問題是否依然沒有得到解決？

如果平時不經常使用，事故流程管理的可靠性萎縮得很快。幸運的是，事故流程管理框架常常也適用于其他的跨時區、或 者跨團隊的常規運維變更實施。

小結 145
第15 章　事后總結：從失敗中學習 146
Google 的事后總結哲學 146
協作和知識共享 148
建立事后總結文化 149
小結以及不斷優化 151

第16 章　跟蹤故障 152

提高可靠性的唯一可靠的方法論是建立一個基線（baseline）， 同時不斷跟蹤改變。

Escalator 152

Outalator 153

聚合 154

加標簽 155

是提供了一種通用的標簽機制，以允許對報警增加 元數據信息。標簽基本上沒有格式要求，都是獨立的“單詞”。
標簽也可以被解析成一個鏈接（比如“bug:76543”將被解析成 Bug跟蹤系統的一個鏈接）。

分析 155
未預料到的好處 156

第17 章　測試可靠性 157

[!NOTE]
測試和平均修復時間的關系
系統通過某項測試或者一系列測試并不一定能證明系統是穩定 的，但是失敗的測試通常證明了系統不可靠。

軟件測試的類型 158

系統測試

冒煙測試（smoke test）
工程師在冒煙測試中可檢測非常簡單但是非常重要的系統行為。 如果該測試不通過，那么其他更昂貴的測試可以不用運行了。

回歸測試（regression test）
另外一種系統測試可保證之前的Bug不會重現。

傳統測試 159
生產測試 160

創造一個構建和測試環境 163

當構建系統通知搞壞代碼的工 程師時，他們應該放下手中的一切其他任務，優先處理該問題。這樣 做的原因在于：

• 如果問題引入系統之后，又有新的變動，修復會更難。
• 不工作的代碼會對團隊造成影響，因為它們必須手動繞過這些 問題。
• 定時地每晚構建和每周構建將失去意義。
• 團隊響應緊急發布的能力將會受到嚴重影響，甚者非常復雜和 困難（例如，發現代碼中以及依賴中的安全漏洞等）。

大規模測試 165

測試大規模使用的工具 166
針對災難的測試 167
對速度的渴求 168
發布到生產環境 170
允許測試失敗 170

集成 172

使用現成的語法（如YAML）和一個經過大 量測試的分析器（例如Python的safe_load）可以將維護配置文件的成 本降低。

生產環境探針 173
小結 175

第18 章　SRE 部門中的軟件工程實踐 176

為什么軟件工程項目對SRE 很重要 176
Auxon 案例分析：項目背景和要解決的問題 177
傳統的容量規劃方法 177
解決方案：基于意圖的容量規劃 179

基于意圖的容量規劃 180

“意圖”是服務負責人對如何運維該服務的一個理性表達。從具 體的容量需求到背后理性原因的表達通常需要跳過幾個抽象級別。舉 例如下：
1.我需要50個CPU的資源，必須在集群X、Y、Z中，為服務Foo使 用。
這是一個具體的資源請求，但是，為什么我們需要這么多資源， 同時一定要在這三個集群中？
2.我需要50個CPU的資源，在地理區域YYYY中的任意三個集群 中，為服務Foo使用。
這項請求增加了更多的選擇自由度，也更容易被滿足，但是仍然 沒有解釋這項請求背后的原因，為什么我們需要這么多資源，以及為 什么需要三個集群？
3.我想要滿足Foo在每個地理區域的需求增長，同時保障N+2冗余 度。
現在有了更多的選擇自由度，同時我們可以更好地理解如果Foo沒 有獲得相應的資源，究竟會造成什么后果。
4.我們想要將Foo以99.999%的可靠度運行。
這是相對更抽象的一個需求，當容量得不到滿足時的后果也更清 楚了：可靠性會下降。而且我們從中獲得了更多的選擇自由度：也許 以N+2運行并不是足夠的，或者并不是最優化的情況，其他的某種部署 計劃是更合適的。

表達產品意圖的先導條件 181
Auxon 簡介 182
需求和實現：成功和不足 183
提升了解程度，推進采用率 185
團隊內部組成 187
在SRE 團隊中培養軟件工程風氣 187
在SRE 團隊中建立起軟件工程氛圍：招聘與開發時間 188
做到這一點 189
小結 190
第19 章　前端服務器的負載均衡 191
有時候硬件并不能解決問題 191
使用DNS 進行負載均衡 192
負載均衡：虛擬IP 194

第20 章　數據中心內部的負載均衡系統 197

理想情況 198

識別異常任務：流速控制和跛腳鴨任務 199

異常任務的簡單應對辦法：流速控制 199

一個可靠的識別異常任務的方法：跛腳鴨狀態 200

從一個客戶端的視角來看，某個后端任務可能處于下列任一種狀態中：

• 健康。
• 拒絕連接。
• 跛腳鴨狀態。 后端任務正在監聽端口，并且可以服務請求，但是已經明確要求客戶端停止發送請求。

當某個請求進入跛腳鴨狀態時，它會將這個狀態廣播給所有已經連接的客戶端。
允許任務處于這種半正常的跛腳鴨狀態的好處就是讓無縫停止任務變得更容易，

利用劃分子集限制連接池大小 201
選擇合適的子集 201
子集選擇算法一：隨機選擇 202
子集選擇算法二：確定性算法 204
負載均衡策略 206
簡單輪詢算法 206
最閑輪詢策略 209
加權輪詢策略 210

第21 章　應對過載 212

QPS 陷阱 213
給每個用戶設置限制 213
客戶端側的節流機制 214
重要性 216
資源利用率信號 217

處理過載錯誤 217

決定何時重試 218

們針對大量后端任務過載的情況有幾個方法來避免進行 重試。
第一，我們增加了每次請求重試次數限制，限制重試3次。
第二，我們實現了一個每客戶端的重試限制。每個客戶端都跟蹤 重試與請求的比例。一個請求在這個比例低于10%的時候才會重試。
第三個方法是客戶端在請求元數據中加入一個重試計數。直到計數器 為2 時，請求重試限制會導致不再重試該請求。

連接造成的負載 220
小結 221

第22 章　處理連鎖故障 223

連鎖故障是由于正反饋循環（positive feedback）導致的不斷擴大規模的故障。連鎖故 障可能由于整個系統的一小部分出現故障而引發，進而導致系統其他部分也出現故障。例如，某 個服務的一個實例由于過載出現故障，導致其他實例負載升高，從而導致這些實例像多米諾骨牌 一樣一個一個全部出現故障。

連鎖故障產生的原因和如何從設計上避免 224

服務器過載 224
資源耗盡 225

服務不可用 228

某幾個后端任務產生 了錯誤，會導致負載均衡器不再向它們發送請求，進而使得其余軟件服務器的負載上升，從而再 次觸發滾雪球效應。

防止軟件服務器過載 228

當發送自動重試時，需要將如下部分考慮在內：

• 一定要使用隨機化的、指數型遞增的重試周期。可參見文獻[Bro15]中提到的文章 Exponential Backoff and Jitter（http://www.awsarchitectureblog.com/2015/03/backoff.html）。如果重試不是隨機 分布在重試窗口里的，那么系統出現的一個小故障（某個網絡問題）就可能導致重試請求同時出 現，這些請求可能會逐漸放大
• 限制每個請求的重試次數。不要將請求無限重試。

隊列管理 229
流量拋棄和優雅降級 230
重試 231
請求延遲和截止時間 234
慢啟動和冷緩存 236
保持調用棧永遠向下 238
連鎖故障的觸發條件 238
進程崩潰 239
進程更新 239
新的發布 239
自然增長 239
計劃中或計劃外的不可用 239
連鎖故障的測試 240
測試直到出現故障，還要繼續測試 240
測試最常用的客戶端 241
測試非關鍵性后端 242
解決連鎖故障的立即步驟 242
增加資源 242
停止健康檢查導致的任務死亡 242
重啟軟件服務器 242
丟棄流量 243
進入降級模式 243
消除批處理負載 244
消除有害的流量 244
小結 244

第23 章　管理關鍵狀態：利用分布式共識來提高可靠性 246

CAP 理論
CAP理論論述了一個分布式系統不可 能同時滿足以下三個要求：

• 每個節點上所見數據是一致的。
• 每個節點都可以訪問數據。
• 可以承受網絡分區問題。

該邏輯非常符合直覺：如果兩個節點無法通信（因為網絡出現了 分區問題），那么整個系統要么在一個或多個節點上無法處理數據訪 問請求，要么可以照常處理請求，但是無法保障每個節點的數據具有 一致性。

使用共識系統的動力：分布式系統協調失敗 248

案例1 ：腦裂問題 249

每組文件服務器有一個領頭者和一個跟隨者，兩組服務通過心跳 互相監控。如果某個文件服務器無法聯系到另外一個服務器，它會發 送一個 STONITH（當頭一槍）命令來強制關閉另外一個服務器，同時 成為文件的主服務者。這種機制是業界減少腦裂（split-brain）場景 發生的常規做法

案例2 ：需要人工干預的災備切換 249

某個外部系統檢 查主實例的健康度，如果主實例出現問題，將副實例提升為主實例。 如果主實例無法確定副實例的健康度，那么它就會將自己標記為不可 用，將問題升級給人工處理，以便避免案例1中的腦裂場景發生。

案例3 ：有問題的小組成員算法 249

分布式共識是如何工作的 250

當維護分布式軟件系統時，我們關 注的是異步式分布式共識（asynchronous distributed consensus） 在消息傳遞可能無限延遲的環境下的實現。

拜占庭式問題指的是當某個進程由于程序Bug或者惡意行為發送不正確 的消息的問題，這種問題相對來說處理成本更高，同時也更少見。

Paxos 概要：協議示例 251

Paxos 是基于提案（proposal）序列運行的，這些提案可能會被 “大多數（majority）”進程所接受，也可能會被拒絕。

在協議的第一階段，提案者（proposer）發送一個序列號給數個 接收者（acceptor）。每個接收者僅僅在沒有接受過帶有更高序列號 的提案情況下接受這個提案。提案者必須使用一個唯一的序列號（每個提案者從不相交的集 合中提取序列號，或者將自身的主機名加入到序列號中等）。

如果提案者從“大多數”接收者那里接收到了“同意”回復，它 便可以通過發送一個帶有值的提交信息（commit message）來嘗試提 交這個提案。

分布式共識的系統架構模式 251

可靠的復制狀態機 252

一個復制狀態機（replicated state machine,RSM）是一個能在 多個進程中用同樣順序執行同樣的一組操作的系統。

可靠的復制數據存儲和配置存儲 252

使用領頭人選舉機制實現高可用的處理系統 253

在這種類型的組件里，不像復制數據存儲那樣，共識算法并不處 于系統的關鍵路徑中，所以共識算法的吞吐量不是系統的主要問題。

分布式協調和鎖服務 253

屏障（barrier）在分布式計算中是一種原語，可以用來阻擋一組 進程繼續工作
屏障也可以用一個RSM系統來實現。
鎖（lock）是另外一個很有用的協調性原語，在實踐中，使用可續租約（renewable Lease）而不是無限時間鎖 是很有必要的，避免某個進程崩潰而導致鎖無限期被持有。

可靠的分布式隊列和消息傳遞 254
分布式共識系統的性能問題 255
復合式Paxos ：消息流過程詳解 257
應對大量的讀操作 258
法定租約 259
分布式共識系統的性能與網絡延遲 259
快速Paxos 協議：性能優化 260
穩定的領頭人機制 261
批處理 262
磁盤訪問 262
分布式共識系統的部署 263
副本的數量 263
副本的位置 265
容量規劃和負載均衡 266
對分布式共識系統的監控 270
小結 272

第24 章　分布式周期性任務系統 273

Cron 273

介紹 273

Cron系統在設計上允許系統管理員和普通系統用戶指定在某時某 刻運行某個指令。Cron可以執行很多種類型的任務

可靠性 274
Cron 任務和冪等性 274
大規模Cron 系統 275
對基礎設施的擴展 275
對需求的擴展 276
Google Cron 系統的構建過程 277
跟蹤Cron 任務的狀態 277
Paxos 協議的使用 277
領頭人角色和追隨者角色 278
保存狀態 281
運維大型Cron 系統 282
小結 283

第25 章　數據處理流水線 284

流水線設計模式的起源 284
簡單流水線設計模式與大數據 284

周期性流水線模式的挑戰 285

周期性的數據流水線非常實用，Google也經常使用，為此還編寫 了一系列程序框架，例如MapReduce和Flume等。

工作分發不均造成的問題 285

處理大數據的一個關鍵思想是利用“令人羞愧的并發性” （embarrassingly parallel）算法將巨大的工 作集切割為一個個可以裝載在單獨的物理機器上的小塊。由于單個客戶已經是系統 的最小分塊單元，整個數據流水線的運行時間就至少等于處理最大的 客戶的工作分塊所需的時間。

分布式環境中周期性數據流水線的缺點 286
監控周期性流水線的問題 287
驚群效應 287
摩爾負載模式 288
Google Workflow 簡介 289
Workflow 是模型—視圖—控制器（MVC）模式 290
Workflow 中的執行階段 291
Workflow 正確性保障 291
保障業務的持續性 292
小結 294

第26 章　數據完整性：讀寫一致 295

數據完整性的強需求 296

提供超高的數據完整性的策略 297

大二進制對象，Binary Large Object，可參見 https://en.wikipedia.org/wiki/Binary_large_object。

備份與存檔 298
云計算環境下的需求 299
保障數據完整性和可用性：Google SRE 的目標 300
數據完整性是手段，數據可用性是目標 300
交付一個恢復系統，而非備份系統 301
造成數據丟失的事故類型 301
維護數據完整性的深度和廣度的困難之處 303
Google SRE 保障數據完整性的手段 304
24 種數據完整性的事故組合 304
第一層： 軟刪除 305
第二層：備份和相關的恢復方法 306
額外一層：復制機制 308
1T vs. 1E ：存儲更多數據沒那么簡單 309
第三層：早期預警 310
確保數據恢復策略可以正常工作 313
案例分析 314
Gmail—2011 年2 月：從GTape 上恢復數據（ 磁帶） 314
Google Music—2012 年3 月：一次意外刪除事故的檢測過程 315
SRE 的基本理念在數據完整性上的應用 319
保持初學者的心態 319
信任但要驗證 320
不要一廂情愿 320
縱深防御 320
小結 321
第27 章　可靠地進行產品的大規模發布 322
發布協調工程師 323
發布協調工程師的角色 324
建立發布流程 325
發布檢查列表 326
推動融合和簡化 326
發布未知的產品 327
起草一個發布檢查列表 327
架構與依賴 328
集成 328
容量規劃 328
故障模式 329
客戶端行為 329
流程與自動化 330
開發流程 330
外部依賴 331
發布計劃 331
可靠發布所需要的方法論 332
灰度和階段性發布 332
功能開關框架 333
應對客戶端濫用行為 334
過載行為和壓力測試 335
LCE 的發展 335
LCE 檢查列表的變遷 336
LCE 沒有解決的問題 337
小結 338

第Ⅳ部分　管理

任何一個想要建立有效SRE團隊的組織都需要格外關注培訓。一個用心設計、用心 執行的培訓課程，可以培訓SRE在復雜和快速變動的環境下有效應對。這樣的課程 可以在新員工剛入職的數周或數月內將多年積累的最佳實踐和最佳策略一次灌輸給 他們。請見本書第28章中的詳細描述。

任何一個參與運維的人都知道，運維大型服務通常會帶來很多中斷性任務：生產環 境出現問題，需要更新二進制文件，不停地咨詢請求等。在這樣多變的環境下有效 地管理這些中斷性任務是SRE必備的技能，詳情請見第29章。

如果這種多變的狀況持續過久，SRE團隊需要從運維過載的情況中恢復過來。我們 在第30章中詳細描述了一套應對流程。

第28 章　迅速培養SRE 加入on-call 341

新的SRE 已經招聘到了，接下來怎么辦 341
培訓初期：重體系，而非混亂 344
系統性、累積型的學習方式 345
目標性強的項目工作，而非瑣事 346

培養反向工程能力和隨機應變能力 347

反向工程：弄明白系統如何工作 347

工程師對他們從未見過的系統都很好奇—工作原理是什么。

統計學和比較性思維：在壓力下堅持科學方法論 347

進行系統故障調試的過程很像是一種游戲：“下列哪一個東西與其他 不同”？這里的“東西”可能是內核版本、CPU架構、

隨機應變的能力：當意料之外的事情發生時怎么辦 348
將知識串聯起來：反向工程某個生產環境服務 348
有抱負的on-call 工程師的5 個特點 349
對事故的渴望：事后總結的閱讀和書寫 349
故障處理分角色演習 350
破壞真的東西，并且修復它們 351
維護文檔是學徒任務的一部分 352
盡早、盡快見習on-call 353
on-call 之后：通過培訓的儀式感，以及日后的持續教育 354
小結 354

第29 章　處理中斷性任務 355

運維負載有許多類型，基本分為三大類：緊急警報、工單，以及 其他的持續性運維活動。

管理運維負載 356
如何決策對中斷性任務的處理策略 356

不完美的機器 357

流狀態 357

流狀態（flow state）進入這個狀態可以鼓勵員工真正地掌握和優化某個 他們負責的任務和項目。但是，如果有其他的事情打斷他們，他們就 會失去這個狀態。我們的目標是盡可能讓員工在這個狀態下工作。

認知流狀態：富有創造性和參與感

某個人在解決問題的過程中，充 分了解問題的起因和現狀，隱約感覺自己可以解決這個問題。

將一件事情做好 358

極化時間
為了限制干擾數量，我們應該減少上下文切換（指工作類型、環 境等的改變）。

實際一點的建議 359
減少中斷 361
第30 章　通過嵌入SRE 的方式幫助團隊從運維過載中恢復 363
第一階段：了解服務，了解上下文 364
確定最大的壓力來源 364
找到導火索 364
第二階段：分享背景知識 365
書寫一個好的事后總結作為示范 366
將緊急事件按類型排序 366
第三階段：主導改變 367
從基礎開始 367
獲取團隊成員的幫助 367
解釋你的邏輯推理過程 368
提出引導性問題 368
小結 369

第 31 章　SRE 與其他團隊的溝通與協作 370

溝通：生產會議 371

SRE發現有一種會議非常有用，我們稱之為生產會議 （production meeting）。生產會議的另一個主要目 標是，通過將在生產中獲取的知識應用到服務中來以便改善服務。

議程 372

• 即將到來的生產環境變化
• 性能指標
• 故障。這個部分會討論那些值得寫事后總結的問題
• 緊急警報。這部分有兩個隱含的問題：這個警報發出的 時間、內容等是否合適？這個警報應該是緊急警報嗎？如果對于后一 個問題的答案是否定的，那么就應該去掉這個警報。
• 之前的待辦事項。像其他任何會議一樣追蹤這些改 進：將待辦事項分配給具體的人，并跟蹤進展情況。

出席人員 373

你會發現需要參加這個會議的團隊，或者很多忙碌而 重要的與會者需要你去逐個邀請。這里有一些技巧可以用來處理這些 情況：

• 不那么活躍的服務可能只需要產品研發團隊的一個代表出席， 或者僅僅是獲得產品研發團隊的一個承諾就夠了：承諾他們會閱讀和 評論會議日程。
• 那些忙碌卻重要的與會者可以通過事先提供個人反饋和引導的 方式參加

SRE 的內部協作 374

專業化是實現這一目標的一種方法，比如，團隊X只會 為產品Y服務。專業化有很多優勢，因為它能夠大幅提高技術熟練度。 但同時專業化也是有弊端的，因為它會導致局部化，忽視大局。我們 要有一個清晰的團隊章程來定義一個團隊將要做什么—更重要的是不 會做什么—但這并不總是那么容易。

團隊構成 375

高效工作的技術 375

書面溝通能力再強，隨著時間的推移，人們對你 的印象也會逐漸淡薄成一個電子郵件地址，直到你再次出現進行直接 溝通。

SRE 內部的協作案例分析：Viceroy 376

Viceroy 的誕生 376
所面臨的挑戰 378

建議 379

舉辦一次峰會是一個解決設 計問題和目標的好機會。在中立性很重要的情況下，應該選擇在一個 中立的位置舉辦峰會，這樣可以讓與會者都沒有“主場優勢”。

SRE 與其他部門之間的協作 380
案例分析：將DFP 遷移到F1 380
小結 382

第32 章　SRE 參與模式的演進歷程 383

SRE 參與模式：是什么、怎么樣以及為什么 383
PRR 模型 384
SRE 參與模型 384
替代性支持 385

PRR ：簡單PRR 模型 386

當SRE接到來自研發團隊的生產運維接管要求時，他們需要評估該 服務的重要程度和目前團隊的可用性。如果該服務的確值得SRE支持，那么SRE 會與研發團隊一起啟動PRR評審流程。

參與 386

該 小組負責與研發團隊啟動討論。該討論涵蓋以下事項：

• 為該服務建立一個SLO/SLA。
• 為可能的、為了提高可靠性的破壞性設計變更制定計劃。
• 制定交接計劃和培訓計劃。

分析 387

在這個階段中，SRE評審者將仔 細學習該服務的一切知識，開始對其生產方面的缺陷進行分析。SRE的 目標是度量該服務自身的成熟程度，以及SRE最關注的運維方面的情 況。

改進和重構 387

下一階段 按如下順序進行：

• 將每個改進建議按照其對服務可靠度的影響而排序，制定一個 優先級順序。
• 與研發團隊討論和協商這些建議，達成一個共識。
• SRE和產品研發團隊同時參與，并且協助對方進行重構，或者 實現額外的功能。此階段所需要的時間和資源在各個項目上有很大不 同。這主要取決于工程師花在重構上的時間，評估該服務成熟度和復 雜度的時間，以及無數的其他因素。

培訓 388

這些SRE會組織一系列的培訓課程和練習。其中包括：

• 設計概述
• 對系統中各種請求的處理流進行深入探討
• 生產環境部署模式的描述
• 對系統運維各個方面的手動練習

“接手”服務 388
持續改進 388
簡單PRR 模型的演進：早期參與模型 389
早期參與模型的適用對象 389
早期參與模型的優勢 390
不斷發展的服務：框架和SRE 平臺 391
經驗教訓 391
影響SRE 的外部因素 392
結構化的解決方案：框架 392
新服務和管理優勢 394
小結 395

第Ⅴ部分　結束語

第33 章　其他行業的實踐經驗 398
有其他行業背景的資深SRE 399
災難預案與演習 400
從組織架構層面堅持不懈地對安全進行關注 401
關注任何細節 401
冗余容量 401
模擬以及進行線上災難演習 402
培訓與考核 402
對詳細的需求收集和系統設計的關注 402
縱深防御 403
事后總結的文化 403
將重復性工作自動化，消除運維負載 404
結構化和理性的決策 406
小結 407
第34 章　結語 408

附錄A　系統可用性 411

水平	每年	每季度	每月	每周	每天	每小時
90%	36.5 days	9 days	3 days	16.8 hours	2.4 hours	6 minutes
95%	18.25 days	4.5 days	1.5 days	8.4 hours	1.2 hours	3 minutes
99%	3.65 days	21.6 hours	7.2 hours	1.68 hours	14.4 minutes	36 seconds
99.5%	1.83 days	10.8 hours	3.6 hours	50.4 minutes	7.20 minutes	18 seconds
99.9%	8.76 hours	2.16 hours	43.2 minutes	10.1 minutes	1.44 minutes	3.6 seconds
99.95%	4.38 hours	1.08 hours	21.6 minutes	5.04 minutes	43.2 seconds	1.8 seconds
99.99%	52.6 minutes	12.96 minutes	4.32 minutes	60.5 seconds	8.64 seconds	0.36 seconds
99.999%	5.26 minutes	1.30 minutes	25.9 seconds	6.05 seconds	0.87 seconds	0.04 seconds

附錄B　生產環境運維過程中的最佳實踐 412

附錄C　事故狀態文檔示范 417

[!NOTE]
摘要：
事故處理組織架構：（參與人）

• 目前事故總負責人：jennifer
• ─ 運維負責人：docbrown
• ─ 計劃負責人：jennfier
• ─ 溝通負責人：jennifer

代辦列表以及已提交的工單：

事故時間線（倒序排列，時區為UTC）：
2015-10-21 15:28 UTC jennifer
─ 全球服務容量提升為2倍。

附錄D　事后總結示范 419

[!NOTE]
摘要：
根源問題:
觸發條件：
解決方案：

附錄E　發布協調檢查列表 423
附錄F　生產環境會議記錄示范 425
參考文獻 427
索引 439