PART I 概覽

第1章 緒論

第2章 從 SRE 的角度看 Google 正式服務環境



PART II 指導原則

第3章 擁抱風險

第4章 服務水準目標

第5章 減少瑣事

第6章 監控分散式系統

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

第8章 發行工程

第9章 簡單化



PART Ⅲ 具體實踐

第10章 基於時間序列資料進行有效警報

第11章 on-call

第12章 有效的故障排除技巧

第13章 緊急應變

第14章 緊急事件管理

第15章 事後檢討：從失敗中學習

第16章 事件追蹤

第17章 測試可靠性

第18章 SRE 部門中的軟體工程實務

第19章 前端伺服器的負載平衡

第20章 資料中心內部的負載平衡系統

第21章 處理系統超載

第22章 處理連鎖故障

第23章 管理關鍵狀態：利用分散式一致化來提高可靠性

第24章 分散式任務排程系統

第25章 資料處理管線

第26章 資料完整性：讀寫一致

第27章 可靠地進行大規模發行



PART Ⅳ 管理

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

第29章 處理插斷性任務

第30章 透過嵌入 SRE 的方式幫助團隊從維運超載中恢復

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

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



PART Ⅴ 總結

第33章 其他產業的實務經驗

第34章 結語



附錄A 系統可用性

附錄B 正式作業環境維運過程中的實踐典範

附錄C 事件狀態範例文件

附錄D 事後檢討範例

附錄E 上線協調檢核表

附錄F 產務會議紀錄範例



參考文獻

索引

關於作者+出版記事

?

序



　　如果用一個語詞來描述Google的歷史，那就是不斷地「擴大規模」（scaling up）。Google的成長經歷是電腦產業中數一數二的成功故事，標記著整個社會朝向IT為中心的商業模式而轉變。Google 很早就開始實踐IT與商業模式的結合，也是向社群推廣DevOps理念的先鋒。本書就是由公司各個部門切身參與、甚至主導了整個產業轉型實踐的人寫成的。



　　Google是在系統維運工程師轉型的階段發展壯大的，它的發展史就像是對傳統的系統維運理念發出的革命宣言：我們無法按照傳統方式維運Google系統，必須要思考一種新的模式，但是同時我們也沒有時間等待其他人驗證和支援我們的理論。在《Principles of Network and System Administration》一書的介紹中，我提出了一種觀點：系統維運本質上是人與電腦共同參與的一項系統性工程。當時有些評論者強烈反對這種觀點：「這個產業還遠遠沒有成熟到可以稱為一項工程」。在那時，我甚至對整個維運產業產生了懷疑，認為這個產業在個人英雄主義與神秘色彩中已經永久地迷失了自己，無法前進。但是，這時Google誕生了，Google的高速發展將我的預言變成了現實，我之前的定義變成具體的詞語：SRE，網站可靠性工程師。我的幾個朋友親身參與這個新職業的創立，用軟體工程理念和自動化工具定義了這個產業。一開始，他們顯得很神秘，Google公司內部的體驗和整個產業也格格不入，Google 太特殊了！久而久之，公司內外交流逐漸增多。這本書的目標就是將SRE的思想和實務介紹給整個產業，以促進交流。



　　本書不僅僅介紹Google如何建設、維護其富有傳奇色彩的大型運算叢集，更重要的是在過程中，Google工程師團隊如何學習、成長、反覆修改，最後定義出一套完整的工具和科技系統。IT產業大多自我封閉、交流過少，很多從業人員都或多或少地受教條主義的限制。如果Google 工程師團隊能克服這個慣性，保持開放的精神，那麼我們也能夠一起和他們面對IT業界最尖端的挑戰。這本書由一群有共同目標的Google工程師寫就的短文集結而成，作者群聚集在同一家公司旗下，為了共同目標努力，本身就是一件很特別的事情。在本書的各個章節之間經常能看到軟體系統的共同點，以及工作模式上的共通之處，我們經常可以從多個角度分析不同的決策選項，了解它們是如何一起解決公司內部的利益衝突。這些文章並不是嚴謹的學術研究論文，而是這些人的切身經歷，雖然本書的作者們有著不同的工作目標、寫作風格及技術背景，但是他們都嘗試真誠地描述自己遇到的問題和解決的經歷，這和IT界的普遍文風截然不同，風格迥異。有些作者會宣稱：「不要做A，只有做B才是正確的」，另一些作者會更謹慎，行文更富有哲理，其實這恰恰代表整個IT產業內不同個性融合的現狀。而我們做為讀者，做為觀察者，並不了解整個Google的歷史，也沒有參與具體的決策過程中，無法完全體會當事人所面臨的糾纏不清的挑戰，只能帶著謙遜的態度遠遠旁觀。在閱讀本書的過程中，相信讀者一定會產生許多疑問：他們當時為什麼沒有選擇X？如果他們選擇Y，結果會是怎樣？如果多年之後回頭再看，這個選擇還會是正確的嗎？這些問題，恰恰是閱讀本書的最大收穫，因為我們第一次有機會將自己的經歷、選擇和本書陳列的決策邏輯相互對應，從中發現不足和缺陷。



　　這本書的成書過程也堪稱奇蹟。今天，我們能感受到整個業界都在鼓吹厚顏無恥的「給我程式碼，其餘免談」（just show me the code）；開源軟體社群內部正在形成一種「別問我問題」的風氣，過於強調平等卻忽略領域專家的意見。Google是業界為數不多的，願意投入菁英力量鑽研本質問題的公司，而且這些公司菁英很多都有工學博士學位。工具永遠只是解決方案中的一個小小元件，用來連結日益龐雜的軟體、人和海量資料。這本書中沒有萬能仙丹，沒有什麼東西能解決一切問題，本書的宗旨是：相對於最終的軟體結果、架構設計而言，真實的設計過程和作者本身的思考經歷更具價值。實作細節常常時過眼雲煙，但是文件化的設計過程卻是無價之寶。有機會了解到這些設計的內幕真是太難得了！



　　總而言之，本書就是Google的成長經歷，實際上就是由相互重疊的故事所組成，書中內容正好說明擴展一套電腦系統，要比簡單按照書本上的標準架構放大困難得多。一家公司的成長，意味著整個公司商業模式和工作模式的擴展，而不只是單純的資源擴張。單就這一點，這本書就物超所值了。



　　IT業界並不流行反躬自省，我們不斷重複發明各種系統。多年來，只有USENIX LISA大會論壇以及其他幾個專注於作業系統的會議會討論一些IT基礎設施的設計和實作。多年後的今天，IT業界已有極大變化，但是本書仍然彌足珍貴：它詳細記錄了Google邁過分水嶺時期的完整過程。很顯然，這些經歷沒有辦法完全複製，也許只能模仿，但是卻可以啟發讀者、指引未來。本書作者們表現出極大的真誠，顯示了謙遜的風格，以及極強的凝聚力、領導力。這些文章記錄作者們的希望、擔憂、成功與失敗的經歷。我向這些作者們和編輯們的勇氣致敬，正是這種坦率，讓我們能夠做為旁觀者和後來人，從前人的經歷中學習到最寶貴的知識。