適讀人群 ：《SRE寫真》適合需要時常應對網站崩潰問題並有志於提升公司軟件穩定性的軟件開發者、開始從事網站可靠性工程師工作的起步者閱讀。

√ 作者長期服務於對服務中斷非常敏感的大型互聯網公司，總結出一套久經考驗的方法論，專用於監控現代Web服務、設置警報、評估針對生產事件的響應機制，以及短時間內恢復網站宕機事故。

√ 除了別出心裁增設SRE面試一章，精華內容還包括監控災難性故障|向團隊發出緊急宕機警報|分析生產事件應對策略|構建屬於自己的自動化測試工具或相關軟件|預測瓶頸以改善用戶體驗。

√ 阿裡巴巴高可用架構團隊負責人遊驥|蘑菇街平臺技術總監趙成|《SRE：Google運維解密》譯者（谷歌前SRE）作序力薦，ThoughtWorks資深技術專家馮文輝傾情獻譯。

√ 不僅涵蓋對服務中斷的反應——揭示安全測試和發布軟件所需的工具和策略、制訂長期增長計劃，還預測了未來的瓶頸所在，完整覆蓋網站全線全周期危機。

√ 全書繫統呈現由冗餘和容災|容量規劃|繫統自動保護|失敗預案|監控能力|發布與變更管理|故障應急處理等領域核心話題構成的SRE技術藍圖。

站點可靠性工程（Site Reliability Engineering，簡稱SRE）是一個令人興奮的新興領域，它專注於如何確保繫統穩定、可靠地運行。本書基於一個金字塔層次結構模型，深入淺出地介紹了關於SRE的方方面面，涉及監控、事故響應與回顧、測試與發布、容量規劃、開發、用戶體驗設計，以及貫穿其中的溝通技巧。

本書是SRE工程師、DevOps工程師、運維工程師和繫統管理員不可或缺的參考資料；軟件架構師、軟件工程師、用戶體驗設計師也能從本書中獲取關於SRE的相關知識。

Nat Welch是一名美國的軟件開發人員。自2005年以來，他一直做著網站構建及運維的工作。他熱愛網站的基礎設施建設，因為這可以支持其他人的創造性努力。2012年，Nat成為谷歌的SRE（Site Reliability Engineering，站點可靠性工程）工程師，並愛上了這個職業。從那時起，他在各種規模的公司工作過，並一直致力於提高網站的可靠性，以幫助開發人員構建可靠的繫統。

關於審查者

Pavlos Ratis是HolidayCheck的一名SRE工程師，負責自動化軟件和基礎設施的可靠性。隨著時間的推移，他參與了大量的項目，並參與過從編寫軟件到自動化，管理基於雲的多服務器基礎設施，到開發Web應用程序等很多環節。

推薦序一

近20年是互聯網技術飛速發展的20年。互聯網技術框架從單機、一體機演進到分布式的多層、多組件架構，原本由5個以內的技術組件構建的業務繫統，到今天可能要有上百個技術組件來構建。為了在較低的成本基礎上保障服務的擴展能力，很多互聯網企業放棄了穩定性更強但也更昂貴的商業技術，轉而使用開源、自研的技術。互聯網業務的快速發展不僅直接帶來了流量、安全等方面的不確定性，同時也促進了技術架構的快速演進——技術架構變得越來越復雜，而這些因素都將導致繫統不可用發生概率的大幅度提升。當人類的工作、生活變得越來越依賴互聯網時，一旦網站繫統不可用，其造成的影響和損失就將難以想像：在遠古時代，人類能夠習慣沒有自來水，也沒有電的生活；但今天如果停水、停電，很多人都會無法適應。

互聯網正在逐步演變成像供水、供電設施那樣的基礎設施，網站繫統的可用性變得至關重要。在這樣的大背景下，SRE的概念被提了出來，隨著互聯網在各行各業的深度滲透，SRE快速發展成了一個熱門領域。幾年前大家對SRE的概念還停留在Google對它的簡單介紹上，如今，國內的一大批互聯網企業都在嘗試構建自己的SRE體繫，SRE逐漸成為互聯網企業的標配，該領域也迎來了百花齊放的盛況。阿裡巴巴也正是在這個階段構建了自己的SRE體繫，其為阿裡集團業務和雲客戶業務持續提供通用的高可用技術產品、解決方案的方法論，以及專業化的業務可用性運維能力。

任何事物的發展、壯大都需要有相應的方法論進行指引。SRE首先是一套方法論，它從傳統運維中將與穩定性相關的工作內容提煉出來進行升華，構建了SRE的方法論體繫。冗餘和容災、容量規劃、繫統自動保護、失敗預案、監控能力、發布與變更管理、故障應急處理等構成了SRE領域的藍圖，並不斷地快速迭代著。方法論的落地實施離不開相關組織和個人，傳統的運維工程師在SRE方法論的熏陶下在繫統可用性方面的技能得到了極大的提高，其中一部分傳統運維工程師“進化”成了技術含金量極高的SRE工程師，他們聚合在一起，構成了專職的SRE團隊。同樣，方法論的落地還需要有一繫列配套的技術產品和工具來支撐，與SRE相關的技術體繫在近幾年也得到迅速發展，特別是隨著AI技術的發展、演進，兩者結合產生了奇妙的“化學反應”，使繫統可用性保障的效率和性能都獲得了極大的提升。

本書是一本SRE指南手冊，它不僅完善地介紹了與SRE相關的理論體繫，還從實踐的維度闡述了SRE的技術體繫應該如何構建。對於關注網站可靠性的研發和運維人員，或者其他想深度了解SRE的技術人員來說，這是一本非常值得閱讀的參考書。

阿裡巴巴高可用架構團隊負責人 遊驥

推薦序二

在我看來，SRE是指導網站繫統穩定性得到保障和落地的佳實踐方案，沒有之一。

這套方案源自Google及國外先進互聯網企業的實踐，以及在其實踐基礎上提煉出來的寶貴經驗；Google將這套方案推廣分享到業界，得到了業界很多企業的嘗試和應用，且都取得了很不錯的效果；這套方案經過了非常廣泛的實踐檢驗，包括我們自己也在不斷地對其實踐和檢驗著。

坦率地講，對於Google SRE中所涉及的技術，業界絕大多數企業都是學不來的，主要原因在於業務類型及業務規模相差巨大。但是， SRE的很多指導原則，卻適用於不同的企業和業務場景。

這其中我認為，SLO和事後回顧是核心內容，SLO可以幫助我們設定開發和運維人員需要共同遵守的指標，包括圍繞SLO應該如何設定相應的流程、機制和決策原則等。事後回顧告訴我們，“故障是常態，正常纔是異常”，所以面對故障，我們更多的應該是從中進行學習和改進，把故障作為提升繫統性能的切入點，而不是故障之後的相互指責和推諉扯皮。

本書給出了指導原則之外的更多細節介紹和實踐方法，可以說是在現有的SRE知識體繫下，針對SRE內容的非常好的補充。

開卷有益，希望本書能夠帶給業界更多的指導意義。

蘑菇街 平臺技術總監 趙成

推薦序三

自從2015年有幸負責翻譯並推廣《SRE：Google運維解密》一書以來，SRE理念已經逐漸從運維圈走向了更為廣泛的IT圈，也逐漸從互聯網企業文化圈傳播到了傳統行業的IT文化圈，這是非常令人振奮的事情。

自《SRE：Google運維解密》成書以來，我已經有幸受邀與各行各業的運維主管、技術負責人等進行了十幾次極有啟發性的交流。運維人員長期面臨著責任重、壓力大、成長難的問題；雲平臺、電商的搶購和秒殺活動、視頻網站等新業務的飛速發展帶來了優秀的高流量、高並發的業務需求；而大數據、人工智能、機器學習等新技術的大量使用，則意味著指數級增長的資源管理需求；越來越精細的運營環境意味著對繫統穩定性及其他性能的要求也越來越高。傳統的運維技術、思路、方法論、組織結構已經不再適用。SRE理念作為Google對業務運維體繫的反思與整理，不僅梳理了在新業務形態下運維人員應該承擔的責任，更給運維人員指明了一條職業發展路線。

運維人員常常熬夜甚至通宵工作，天天救“火”，卻隻能作為執行者，無法真正從“火災”隱患中走出來。在這樣的情況下，研發自動化工具，對內提供服務平臺來應對業務的飛速增長；關注有效監控與有效警報，將業務繫統白盒化、透明化，甚至達到故障自愈、無人運維的狀態。這樣運維人員纔能解放出更多的精力，從而去關注更高層次的繫統性能架構調優、容量的規劃與制備等。

與《SRE：Google運維解密》一樣，本書也是由Google前SRE工程師寫成的，它們相互輝映，互相補充。本書將SRE理念與當下普遍、流行的開源技術、開源軟件相結合，理論指導實踐，實踐檢驗理論，內容翔實，值得運維人員仔細閱讀。也希望本書能將SRE理念帶給更多的從業人員，共勉。

《SRE：Google運維解密》譯者 孫宇聰

1 簡介 1

SRE簡史 2

SRE是什麼 3

關於這本書 7

以SRE作為新項目的框架 9

小結 12

2 監控 13

為什麼要監控 13

檢測應用程序 16

度量什麼 23

SLI、SLO和錯誤預算簡介 26

錯誤預算 27

收集和保存監控數據 29

輪詢應用程序 29

推送應用程序 32

展示監控信息 35

任意查詢 35

圖表 36

儀表板 37

聊天機器人 38

管理和維護監控數據 38

溝通 39

他們知道有監控嗎 39

小結 40

參考資料 40

3 事故響應 42

什麼是事故 43

什麼是事故響應 45

警報 47

什麼時候發起警報 48

怎麼發出警報 49

向誰發出警報 54

隨時待命 55

溝通 57

事故指揮繫統 59

在哪裡溝通 61

恢復繫統 61

警報解除 63

小結 64

4 事後回顧 65

什麼是事後回顧 65

為什麼寫事後回顧報告 66

何時寫事後回顧報告 68

開展事故分析 69

如何寫事後回顧報告 71

總結 71

影響 72

時間 73

根本原因 74

行動項 75

附錄 77

停止事後指責 77

舉行事後回顧會議 79

分析以往的事後回顧報告 80

MTTR與MTBF 81

警報疲勞 81

討論過去的服務中斷 81

小結 82

參考資料 82

5 測試和發布 83

測試 84

測試內容 87

發布 100

何時發布 101

回滾 104

自動化 104

持續 105

小結 106

6 容量規劃 107

企業財務簡介 108

為什麼需要規劃 110

風險管理與期望管理 111

定義一個規劃 112

當前的容量是多少 113

何時達到容量極限 115

應該如何更改容量 119

執行規劃 125

架構——性能變化的根源 126

技術作為利潤中心和采購 128

小結 128

7 構建工具 129

尋找項目 131

定義項目 133

RDD 133

設計文檔 136

項目計劃 138

例子 139

回顧會與站會 141

工作分配 142

構建項目 143

關於編寫代碼的建議 143

關注點分離 144

長期工作 145

筆記本 148

文檔與維護項目 149

小結 150

8 用戶體驗 151

設計和用戶體驗簡介 155

現實世界的交互設計 157

用戶測試 160

挑選一種體驗 161

設計測試 162

尋找要測試的人 162

開發者體驗 163

工具經驗 164

績效預算 164

安全性 166

身份認證 167

授權 168

風險概況 168

網絡釣魚 169

ACM道德準則 170

小結 171

參考資料 172

9 網絡基礎 173

互聯網 173

發送一個HTTP請求 175

DNS 175

以太網和TCP/IP 179

HTTP 186

curl與wget 189

網絡監控工具 194

netstat 194

nc 195

tcpdump 196

小結 197

參考資料 197

10 Linux和雲基礎 198

Linux基礎 198

一切皆是文件 199

進程是什麼 206

syscalls 207

構建自己的工具 213

雲基礎 214

虛擬機 215

容器 216

負載均衡 218

自動伸縮 219

存儲 219

隊列與發布/訂閱 220

221

架構面試示例 222

小結 226

參考資料 226

總會在某個時候，軟件開發人員所開發的站點會遭遇噩夢般的無法訪問的故障——客戶說他們已經連續幾個小時無法訪問你的網站了；當你在睡覺時，沒有顧客能夠購買網站上正在銷售的T恤；或者在一年中最重要的銷售日裡，所有服務器都因承受不了高負載而崩潰了。

這本書適合誰

本書面向希望提高公司軟件可靠性的軟件開發人員和運維人員。本書將向你介紹一個致力於提高軟件可靠性的基本框架，並使你深入了解站點可靠性工程這個領域。對於已經經歷過重大繫統服務中斷的工程師和開發人員來說，這是你希望擁有的書。對於那些幸運地沒有經歷過服務中斷噩夢的工程師和開發人員，現在就買這本書吧！

這本書涵蓋了哪些內容

第1章 簡介，探討了SRE領域相對較新的發展狀況，並概述了用於本書的可供上手實踐的框架。

第2章 監控，討論了在監控時使用的工具和方法。在本章之後，一個很好的實驗就是設置對服務的監控，即使它們隻是為測試而編寫的虛假服務，你也應該去監控它們隨著時間是否有所變化。

第3章 事故響應，解釋了該如何應對中斷，並讓團隊為最壞的情況做好準備。本章還專注於圍繞團隊協作建立即時響應與輪換的最佳實踐繫統，以及構建流程以盡量減輕由生產事故造成的壓力。

第4章 事後回顧，讓你能為自己、你的團隊和你的組織撰寫事後回顧報告，以促進事後回顧。本章還討論了要收集的數據，以及如何借助通信跟蹤未來的工作。

第5章 測試和發布，回顧了有關測試和發布的常見實踐方案。

第6章 容量規劃，介紹了一些有關預算的基礎知識，並討論了如何為基礎架構的擴容制訂計劃。

第7章 構建工具，討論了如何從提高響應力的角度來編寫軟件，還探討了如何發現新項目，如何定義這些項目及如何規劃它們。然後，討論了如何實施這些項目並進行軟件的長期維護，以及如何反思自己所做的工作。

第8章 用戶體驗，概述了有關用戶體驗和用戶測試的基礎知識，並討論了安全性和性能預算問題。

第9章 網絡基礎，幫助你深入了解網絡基礎知識。

第10章 Linux和雲基礎，介紹了Linux和常見雲服務的基礎知識。

本書配套資源

?本書中所有用Go語言編寫的代碼都基於Go 1.10版本。讀者可以到其官網獲取最新的版本。

?本書中所有用Ruby語言編寫的代碼都基於Ruby 2.5版本。讀者可以到其官網獲取最新的版本。

本書使用的約定

本書中使用了一些文本約定。

代碼塊示例如下。

"hello world"

end

當希望讀者注意代碼塊中的特定部分時，相關的行或項目將以粗體顯示，示例如下。

"hello world"

end

end

粗體：表示第一次出現的新術語、重要單詞。例如，會出現如下所示的文本。

服務水平指標 Service Level Indicator（SLI）可能是業務最重要的指標。