如果用一個詞語來描述 Google 的歷史，那就是不斷地“擴大規(guī)�！保╯caling up）。Google 的成長經(jīng)歷，是計算機行業(yè)中數(shù)一數(shù)二的成功故事，標志著整個社會向 IT 為中心的商業(yè)模式的轉(zhuǎn)變。Google 很早就開始實踐 IT 與商業(yè)模式的結合，也是向社區(qū)推廣DevOps 理念的先行者。本書就是由來自公司各個部門，切身參與甚至主導了整個行業(yè)轉(zhuǎn)型實踐的人寫成的。
　　Google 是在一個系統(tǒng)運維工程師行業(yè)轉(zhuǎn)型的階段發(fā)展壯大的。Google 的發(fā)展史就像是對傳統(tǒng)的系統(tǒng)運維理念發(fā)出的革命宣言：我們無法按照傳統(tǒng)方式運維Google 系統(tǒng)，必須要思考一種新的模式，但是同時我們也沒有時間等待其他人驗證和支持我們的理論。在Principles of Network and System Administration（參見文獻[bur99]）一書的介紹中，我提出了一種觀點：系統(tǒng)運維本質(zhì)上是人與計算機共同參與的一項系統(tǒng)性工程。當時的一些評論者對這種觀點表示了強烈的反對：“這個行業(yè)還遠遠沒有成熟到可以稱為一項工程”。在那時，我甚至對整個運維行業(yè)產(chǎn)生了懷疑，認為這個行業(yè)在個人英雄主義與神秘色彩中已經(jīng)永久地迷失了自己，無法前進。但是，這時Google 誕生了，Google 的高速發(fā)展將我的預言變成了現(xiàn)實。我之前的定義變成了一個具體的詞語：SRE，站點可靠性工程師。我的幾個朋友切身參與了這個新職業(yè)的創(chuàng)立，用軟件工程理念和自動化工具定義了這個行業(yè)。一開始，他們顯得很神秘，Google 公司內(nèi)的體驗和整個行業(yè)也格格不入，Google 太特殊了！ 隨著時間的推移，公司內(nèi)外交流逐漸增多。這本書的目標就是將SRE 的一些思考和實踐帶給整個行業(yè)，以促進交流。
　　在本書中，我們不僅僅展示了 Google 是如何建設維護其富有傳奇色彩的大型計算集群的。更重要的是，我們展示了在建設過程中，Google 工程師團隊是如何學習、成長、反復修改，zui后定義出一套完整的工具和科技體系的過程。IT 行業(yè)大多自我封閉，交流過少，很多從業(yè)人員都或多或少地受教條主義的限制。如果Google 工程師團隊能克服這個慣性，保持開放的精神，那么我們也能夠一起和他們面對 IT 行業(yè)內(nèi)zui尖端的挑戰(zhàn)。
　　這本書由一群有共同目標的 Google 工程師寫就的短文組成。本書的作者們聚集在同一個公司旗下，為了同一個目標努力，本身就是一件很特別的事情。在本書的各個章節(jié)之間經(jīng)常能看到軟件系統(tǒng)的共同點，以及工作模式上的共通之處。我們經(jīng)常可以從多個角度分析不同的決策選擇，了解他們是如何一起解決公司內(nèi)部多種利益沖突的。這些文章并不是嚴謹?shù)膶W術研究論文，而是這些人的切身經(jīng)歷。雖然本書的作者們有著不同的工作目標、寫作風格，以及技術背景，但是他們都嘗試著去真誠地描述自己遇到的問題和解決的經(jīng)歷。這和 IT 行業(yè)內(nèi)的普遍文風截然不同，風格迥異。有些作者會宣稱：“不要做A，只有做B 才是正確的�！� 另一些作者會更謹慎，行文更富有哲學性。這其實恰恰代表了整個 IT 行業(yè)內(nèi)不同個性融合的現(xiàn)狀。而我們作為讀者，作為觀察者，并不了解整個Google 的歷史，也沒有參與到具體的決策過程中，無法全面了解當事人所面臨的糾纏不清的挑戰(zhàn)，只能帶著謙遜的態(tài)度遠遠旁觀。在閱讀本書的過程中，相信讀者一定會產(chǎn)生出許多疑問：“他們當時為什么沒有選擇X ？”“ 如果他們選擇了Y，結果會是怎樣？”“ 如果多年之后回頭再看，這個選擇會是正確的嗎?” 這些問題，恰恰是閱讀本書的zui大收獲，因為我們第1次有機會將自己的經(jīng)歷、選擇和本書陳列的決策邏輯相互對應，從中發(fā)現(xiàn)不足和缺陷。
　　這本書的成書過程也堪稱奇跡。今天，我們能感受到整個行業(yè)都在鼓吹厚顏無恥的 “代碼拿來主義”（just show me the code）。開源軟件社區(qū)內(nèi)部正在形成一種“不要問我問題”的風氣，過于強調(diào)平等卻忽略領域?qū)＜业囊庖�。Google 是行業(yè)內(nèi)為數(shù)不多的，愿意投入精英力量鉆研本質(zhì)問題的公司，而且這些公司精英很多都有工學博士學位。工具永遠只是解決方案中的一個小小組件，用來鏈接日益龐雜的軟件、人和海量的數(shù)據(jù)。這本書中沒有萬能藥，沒有什么東西能解決一切問題，但是這恰恰是本書的宗旨：相比zui后的軟件結果、架構設計而言，真實的設計過程、作者本身的思考經(jīng)歷更有價值。實現(xiàn)細節(jié)永遠只是短暫存在的，但是文檔化的設計過程卻是無價之寶。有機會了解到這些設計的內(nèi)幕真是太難得了！
　　這本書，歸根到底，記錄了 Google 這個公司的成長經(jīng)歷。書中的很多故事都是由相互重疊的故事組成的，這恰恰說明了擴展一個計算機系統(tǒng)，要比簡單按照書本上的標準架構放大困難得多。一個公司的成長，意味著整個公司商業(yè)模式和工作模式的擴展，而不是簡單的資源擴張。僅此一點，這本書就物超所值了。
　　自省，是一個在 IT 行業(yè)內(nèi)部并不流行的詞語。我們不斷重復發(fā)明各種系統(tǒng)。很多年以來，只有 USENIX LISA 大會論壇以及其他幾個專注于操作系統(tǒng)的會議會討論一些 IT 基礎設施的設計和實現(xiàn)。很多年后的今天，IT 行業(yè)已經(jīng)天翻地覆，但是本書仍然彌足珍貴：它詳細記錄了Google 邁過分水嶺時期的全過程。很顯然，這些經(jīng)歷沒有辦法完全復制，也許只能被模仿，但是卻可以啟發(fā)讀者，指引未來。本書作者們表現(xiàn)出了極大的真誠，顯示了謙遜的風格，以及極強的凝聚力、領導力。這些文章記錄了作者們的希望、擔憂、成功與失敗的經(jīng)歷。我向這些作者們和編者們的勇氣致敬，正是這種坦率，讓我們能夠作為旁觀者和后來人，從前人的經(jīng)歷中學習到zui寶貴的知識。
　　Mark Burgess
　　In Search of Certainty 一書作者
　　Oslo，2016 年3 月
　　序言
　　軟件工程有的時候和養(yǎng)孩子類似：雖然生育的過程是痛苦和困難的，但是養(yǎng)育孩子成人的過程才是真正需要花費絕大部分精力的地方。但是，傳統(tǒng)軟件工程專業(yè)花費了很多精力討論軟件的開發(fā)過程，而不是其后的維護過程。有統(tǒng)計顯示， 一個軟件系統(tǒng)的40%~90% 的花銷其實是花在開發(fā)建設完成之后不斷維護過程中的。行業(yè)內(nèi)流行的一個說法是：一個系統(tǒng)如果已經(jīng)開發(fā)完成，部署在生產(chǎn)環(huán)境上，那么它就是 “穩(wěn)定的”，就不需要那么多工程師花費精力去優(yōu)化、維護。我們認為這個說法是錯誤的。從這個視角出發(fā)，我們認為如果軟件工程職業(yè)主要專注于設計和構建軟件系統(tǒng)， 那么應該有另外一種職業(yè)專注于整個軟件系統(tǒng)的生命周期管理。從其設計一直到部署，歷經(jīng)不斷改進，zui后順利退役。這樣一種職業(yè)必須具備非常廣泛的技能，但是和其他職業(yè)的專注點都不同。Google 將這個職位稱為站點可靠性工程師（SRE，Site Reliability Engineering）。
　　那么，站點可靠性工程師究竟代表著什么呢？的確，這個詞語并不能夠特別清晰地描述這個職位的意義。基本上每個 Google SRE 都會被經(jīng)常問到這個職位到底代表什么意思，以及他們的日常工作究竟是什么。
　　將這個詞語展開來說：首先，也是zui重要的一點，SRE 是工程師（engineer）。SRE 使用計算機科學和軟件工程手段來設計和研發(fā)大型、分布式計算機軟件系統(tǒng)。有的時候，SRE 和產(chǎn)品研發(fā)團隊共同工作，其他時候我們需要開發(fā)這些系統(tǒng)的額外組件：例如備份系統(tǒng)和負載均衡系統(tǒng)等。理想情況下，同時推進這些組件在多個項目中復用。還有的時候，我們的任務是想出各種各樣的辦法用現(xiàn)有組件解決新的問題。
　　其次，SRE 的關注焦點在于可靠性。Ben Treynor Sloss，Google 負責7×24 運維的副總裁，SRE 名稱的發(fā)明者，宣稱可靠性應該是任何產(chǎn)品設計中zui基本的概念：任何一個系統(tǒng)如果沒有人能夠穩(wěn)定地使用，就沒有存在的意義。因為可靠性 是如此重要，因此SRE 專注于對其負責的軟件系統(tǒng)架構設計、運維流程的不斷優(yōu)化，讓這些大型軟件系統(tǒng)運行得更可靠，擴展性更好，能更有效地利用資源。但是，SRE 并不是無止境地追求完美：當一個系統(tǒng)已經(jīng) “足夠可靠” 的時候，SRE 通常將精力轉(zhuǎn)而投入到研發(fā)新的功能和創(chuàng)造新的產(chǎn)品中。
　　zui后，SRE 的主要工作是運維在分布式集群管理系統(tǒng)上運行的具體業(yè)務服務（service）。不論是遍布全球的存儲服務，還是億萬用戶賴以工作的 E-mail 服務，還是 Google zui初的 Web 搜索服務。SRE 中的“ S” zui開始指代的就是google.com 的運維服務，因為SRE的第1個工作就是維持網(wǎng)站的正常運轉(zhuǎn)。隨著時間的推移，SRE 逐漸接管了 Google 內(nèi)部絕大部分產(chǎn)品系統(tǒng)，包括 Google Cloud Platform 這類開發(fā)者平臺，也包括內(nèi)部的一些非網(wǎng)站類的基礎設施系統(tǒng)，例如 Bigtable。
　　雖然我們在這里將 SRE 的職位定義得比較寬泛，但是在這樣一個互聯(lián)網(wǎng)業(yè)務高速發(fā)展的時代，這個職位的出現(xiàn)毫不奇怪。同樣，雖然在應用系統(tǒng)運營維護的過程中有數(shù)不清的重要環(huán)節(jié)需要關注，我們zui關注的是“可靠性”這一點也不奇怪。在Web 服務領域里，對服務器端軟件的優(yōu)化和修改是相對可控的，變更管理與生產(chǎn)安全又結合得非常緊密，一種類似于 SRE 的職業(yè)早晚會在這個環(huán)境下誕生。
　　雖然 SRE 這個行業(yè)是在 Google 內(nèi)部，從Web 社區(qū)中誕生的，但我們認為這個職業(yè)對其他團隊和組織也有很多值得借鑒的地方。本書是對闡述SRE 發(fā)展過程的一次嘗試：我們既希望將這些寶貴經(jīng)驗共享給其他相關行業(yè)，也希望能從其他行業(yè)中汲取知識，從而更好地定義各種角色和術語。為了這個目的，本書將通用的理論、設計理念和思想，與實際的應用工具介紹等分開。在某些需要結合Google 內(nèi)部信息討論主題的時候，我們相信讀者可以進行類比，將書中的理念與自己的實際環(huán)境相結合，以便得出更為有效的結論。本書中也包含了一些對 Google 內(nèi)部生產(chǎn)環(huán)境的介紹，將 Google 內(nèi)部環(huán)境與外部常見的開源類軟件相對應。這樣可以讓本書的一些設計理念與實踐的結合度更強，應用起來更容易。
　　zui后，我們當然希望社區(qū)內(nèi)出現(xiàn)更多、更可靠的軟件系統(tǒng)。我們知道，創(chuàng)業(yè)企業(yè)甚至中型企業(yè)經(jīng)常對如何應用這些理念和技術感到困惑。可靠性就像安全性，越早關注越好。這就意味著一些小型創(chuàng)業(yè)公司，在應付日常面臨的種種挑戰(zhàn)時，也應該抽出一部分精力來面對可靠性這個話題。這與蓋房子有些類似，如果一開始將整個地基打好并保持繼續(xù)修繕，要比蓋好房子之后再重新修改設計要容易得多。本書第4 部分著重介紹了 SRE 團隊如何進行內(nèi)部培訓、如何加強內(nèi)部溝通等zui佳實踐，很多都可以直接拿來應用。
　　對中型企業(yè)來說，企業(yè)內(nèi)部可能已經(jīng)有這樣的一組人在做著與SRE 非常類似的工作。這些人可能并不叫 SRE 這個名字，甚至可能沒有受到管理層的重視。在這樣的企業(yè)中，提高可靠性zui好的辦法往往就是去認可這些人的工作，并配備足夠的激勵機制。在牛頓被世界正式認可為物理學家之前，他經(jīng)常被稱作是zui后的煉金術師。而這些專注于可靠性的工程師們，正如當年的牛頓一樣，是一個新時代的開拓者。
　　如果一定要為SRE 尋找一個起源的話，誰才能夠被稱為世界上第1個SRE 呢？我們選擇了 Margaret Hamilton，MIT 教授，參與了阿波羅登月計劃的軟件開發(fā)工作。她的工作具有現(xiàn)代SRE 的一切特性。用她自己的話來講：“團隊文化就是從一切經(jīng)歷中不斷學習，包括來自那些我們zui意想不到的地方的經(jīng)歷�！�
　　在Apollo 7 飛船研發(fā)期間的某一天，Margaret 帶著她的小女兒 Lauren 一起來到公司。在 Margaret 忙著和組員們在大型計算機上運行飛行模擬測試的時候，她的小女兒偷偷地按下了控制臺上的 DSKY 鍵。整個模擬程序出乎意料地崩潰了，導致整個火箭發(fā)射程序意外終止。Margaret 和組員調(diào)試后發(fā)現(xiàn)，原來Lauren 意外觸發(fā)了 P01 這段子程序的執(zhí)行，導致了整個模擬過程的失敗。（該子程序是起飛前調(diào)試程序，執(zhí)行時會刪除現(xiàn)存的導航信息，如果在火箭飛行過程中執(zhí)行這段程序，計算機將無法繼續(xù)維持火箭航線，后果將是災難性的。）
　　憑借著 SRE 的直覺， Margaret 為項目組提交了一個軟件改動，申請在飛行程序中增加一項特殊狀態(tài)檢查，以避免飛行員在飛行過程中意外觸發(fā)P01 程序的執(zhí)行。但不幸的是，NASA 管理層認為，這項錯誤發(fā)生的可能性太小，根本不值得為此添加這項修改。于是Margaret 沒有能夠成功提交這項軟件修改。她只能在火箭飛行手冊中添加了一段文字，寫道：“在飛行過程中，請勿觸發(fā)P01 程序�！� （當時增加這段文字時，很多NASA 工程師都認為這很好笑，認為Margaret 是小題大做，幾乎所有人都認為宇航員經(jīng)過如此長時間的專業(yè)訓練，是絕對不會犯如此低級的錯誤的。）
　　幾天后，在Apollo 8 飛船執(zhí)行下一項飛行任務時。宇航員 Jim Lovell、William Anders和Frank Borman 三人執(zhí)行一個長達四天的飛行計劃途中，Jim Lovell 意外地觸發(fā)了 P01程序的執(zhí)行。更巧的是，當天正好是美國圣誕節(jié)，大部分工程師都休假去了�？上攵�知，當時NASA 的一片混亂狀態(tài)。這次不是演習，而是人命關天的危急時刻，如果不能及時解決，三名宇航員將永遠無法安全返回了。所幸，當時 Margaret 的飛行手冊更新中恰恰提到了這種情形，并且提供了重新上傳數(shù)據(jù)以及恢復執(zhí)行的有效辦法，在有限的時間內(nèi)解決了問題，使任務可以繼續(xù)進行。
　　Margaret 曾經(jīng)說過：“無論對一個軟件系統(tǒng)運行原理掌握得多么徹底，也不能阻止人犯意外錯誤�！� 在這次危機過后，Margaret 之前提交的修改申請很快就被批準了。
　　雖然Apollo 8 的事故發(fā)生在幾十年前，但是工程師們一定不會對此感到陌生， 類似的場景總是在不斷重演。希望讀者以史為鑒，只有靠著對細節(jié)的不懈關注，做好充足的災難預案和準備工作，時刻警惕著，不放過一切機會去避免災難發(fā)生。這就是SRE zui重要的理念！歡迎加入SRE 的大家庭！
　　如何閱讀本書
　　這本書是由一系列短文組成的， 由Google SRE 成員和前成員共同寫就。相比之下，這本書更像是一本會議文集。本書的每一章都可以作為一個獨立部分進行閱讀，但是讀者也可以根據(jù)自己的興趣選擇某些章節(jié)重點閱讀。（如果本書中引用了某些額外文章，你可以在參考文獻中找到。）
　　讀者可以按照任何順序閱讀本書，但是我們推薦從第2 章和第3 章開始。這兩章描述了Google 的生產(chǎn)運行環(huán)境，以及SRE 是如何系統(tǒng)化認知與量化“風險”的（畢竟 “風險” 是SRE zui關注的要點）。讀者當然也可以選擇逐章閱讀，本書邏輯上分為以下幾個部分：理念性介紹（第Ⅱ部分）、zui佳實踐（第Ⅲ部分）和管理經(jīng)驗（第Ⅳ部分）。每一部分都配有簡介，并且配有SRE 成員以前發(fā)表的文章的引用地址。
　　最后，本書配有網(wǎng)站https://g.co/SREBook，其中包括了一些有益讀物， 希望讀者能從中獲得閱讀的樂趣。
　　……