大型軟體系統生命週期的絕大部分都處於「使用」階段，而非「設計」或「實現」階段。那麼，為何我們總是認為軟體工程應該首要關注設計和實現呢？

Google SRE團隊的核心成員在本書中分享了他們是如何對軟體進行生命週期的整體性關注的，以及解說這樣的做法為何能夠幫助Google成功地構建、部署、監控和運維世界上現存最大的軟體系統。您可以從中學習到Google工程師在提高系統部署規模、改進可靠性和資源利用效率方面的思考方式與具體作法。任何一個想要建立、擴展大規模整合系統的人都應該閱讀本書。本書針對如何構建一個可長期維護的系統提供了非常寶貴的實踐經驗。
本書分為以下四個部分：
．簡介：說明何謂網站可靠性工程（SRE）及其與傳統IT業界作法的差異
．原則：介紹SRE日常工作背後的指導原則：SRE的工作模式、行為方式，以及平時維運工作中關注的重點等
．實踐：探討SRE管理大型分散式系統的理念和實踐典範
．管理：介紹Google的訓練與團隊協作的方式

---

名人推薦
「能讓所有公司受益的高科技管理實務，只有Google能夠辦到的創新。」
—Thomas A.Limoncelli, 《The Practice of Cloud System Administration》共同作者

「web高可用性服務管理人員必讀的一本書」
—Adrian Cockcroft, 前任Netflix雲端架構師

「不管是為了自己還是公司，你都應該熟讀本書並動手實踐這些理念」
—Jez Humble, 《Continuous Delivery》、《精實企業》共同作者

Betsy Beyer
Google紐約分部專責SRE 的技術文件作家，之前曾為遍布全球的Google資料中心與Mountain View 硬體維運團隊撰寫文件，在搬到紐約之前，他曾擔任史丹佛大學技術寫作課程的講師。

Chris Jones
Google App Engine 的SRE。每天處理超過280億個請求，Chris之前的工作包括Google廣告統計、資料倉儲及使用者支援系統的維護，更早之前任職於學術單位的IT 部門，並參與競選資料分析，以及一些BSD核心的修改，他擁有電腦工程、經濟學及技術政策學的學位，也是一名有執照的專業工程師。

Jennifer Petoff
Google SRE 團隊的專案經理，工作地點在都柏林、愛爾蘭，她曾經負責管理大型全球專案，包括：科學研究、工程、人力資源及廣告等。

Niall Murphy
Google愛爾蘭團隊廣告SRE的負責人，投身網路業已經近20 年，目前是INEX的主席，他寫過許多科技文章與書籍，包括歐萊禮出版的《IPv6 Network Administration》以及很多RFC，目前正參與撰寫愛爾蘭網際網路發展史，他擁有電腦科學、數學，以及詩歌學的學位，目前與妻子和兩個兒子居住在都柏林。

如果用一個語詞來描述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邁過分水嶺時期的完整過程。很顯然，這些經歷沒有辦法完全複製，也許只能模仿，但是卻可以啟發讀者、指引未來。本書作者們表現出極大的真誠，顯示了謙遜的風格，以及極強的凝聚力、領導力。這些文章記錄作者們的希望、擔憂、成功與失敗的經歷。我向這些作者們和編輯們的勇氣致敬，正是這種坦率，讓我們能夠做為旁觀者和後來人，從前人的經歷中學習到最寶貴的知識。

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 產務會議紀錄範例

參考文獻
索引
關於作者+出版記事