書名：網站可靠性工程工作手冊｜導入SRE的實用方法

作者簡介

Betsy Beyer, Niall Richard Murphy, Dave Rensin, Kent Kawahara & Stephen Thorne等人，都是Google SRE團隊的現任與過往成員，負責管理與維護Google的正式系統環境

書籍目錄

前言一
前言二
序言
譯序


第一章 SRE 與 DevOps 如何琴瑟和鳴


【第一篇 基礎】
第二章 實施 SLO
第三章 SLO 工程案例研究
第四章 監控
第五章 就 SLO 告警
第六章 消滅苦工
第七章 簡單性



【第二篇 實踐】
第八章 on-call
第九章 事故回應
第十章 事後檢討文化：從失敗中學習
第十一章 管理負載
第十二章 非抽象大型系統設計簡介
第十三章 資料處理流水線
第十四章 組態設定的設計與最佳實踐
第十五章 組態設定的細節
第十六章 金絲雀發布



【第三篇 流程】
第十七章 識別過載並從其中復原
第十八章 SRE 積極參與模型
第十九章 SRE：跨越疆界
第二十章 SRE 團隊之生命週期
第二十一章 SRE 組織變革管理


結論
附錄A SLO 文件範本
附錄B 範例犯錯預算政策
附錄C 事後檢討分析結果
索引

推薦序/導讀/自序

當我們撰寫《網站可靠性工程》一書時有個目標：闡釋Google生產工程和運維的基本原理與原則。那本書是我們的一次嘗試，希望能與業界的同行們分享我們團隊的最佳實踐和教訓。我們當時假定那本SRE 書可能只會吸引為數不大多的工程師—他們的工作牽涉到大型並且注重可靠性的任務或協作，而且以該書內容的份量與焦點，可能不會引起太多關注。

結果證明，我們很高興在這兩點看法上都搞錯了。

讓我們感到驚訝和欣喜的是，第一本SRE 書在發布後這段令人興奮的期間內，是計算（computing）領域的暢銷書。此外，在購買或下載後並未被束之高閣，而是真被閱讀了。我們收到了來自世界各地關於本書、SRE 團隊、SRE 實踐與成效的相關問題。我們受邀去解說書中的內容、方法和事故。邀約實在出乎意料的多，以致於我們只能謝絕一些外部的邀約，因為實在是排不出時間。

人怕出名豬怕肥，這SRE 書成名創造了機會讓我們得以更多人力（「雇用更多人吧！預約更多講演吧！」），或透過一些更能擴增的辦法應付。出乎少數讀者意料，作為SRE工程師，我們選擇了後者。我們決定寫第二本書—增補了我們最常受邀講解的內容，回應了讀者們閱讀第一本書時最常提出的問題。
在我們收到的許多關於第一本SRE書不同的問題、請求和評論中，有兩個主題特別有趣；如果不予解決，將妨礙SRE經驗教訓之充分有效利用。這些主題可以大致歸納成：
．原則聽起來挺有意思，但我如何在我的專案╱團隊╱公司中付諸實踐？
．SRE的方法在我這兒鑿枘不投；只在Google的文化裡才行得通，而且只有達到Google的規模才有意義。

這本SRE書的目的是：（a）在第一本書概述的原則中添加更多施行細節，以及（b）打消這樣的念頭：SRE只能在「Google規模」或「Google文化」中實踐。

本書是前一本著作的手冊—不是新版，這兩本書應該相互參照。若已熟悉前作，那您可以從本書得到最大的收穫。本書將大致沿襲第一本的結構。希望您能夠對照著閱讀這些章節。本書中的每一章都假定您熟悉上一本著作中的對應部分；目標是讓您一邊閱讀一邊印證時，在原則和實踐之間來回對照參考。如此一來，兩本書是相輔相成的。接下來，關於本書的價值觀：聽一些讀者說當我們在描述Google的運維發展歷程時，太過於自我中心了。有讀者認為我們已經脫離了Google以外的現實，而且沒能解釋我們的想法與DevOps原則之間如何互為表裡。這是一個相當不錯的指正，我們虛心接受，體現在此書中。

無論如何，我們確實覺得SRE作為一門專業，其高度武斷剛愎的本質還是頗有用武之地。對我們來說這是一種功用，而不是問題。我們並沒提倡SRE是建構和運行高可靠性系統的唯一方式（或甚至是一體適用的最佳方式）。只是對我們而言，這是至今最成功的方式。我們還會談談SRE和DevOps之間彼此如何相互關聯共鳴。重點是請記住，它們沒有相互矛盾。

我們先承認，這本書必然不會包羅萬象。即使在Google範疇內，SRE專業也是一個很廣闊的領域，而且如今在Google外部也廣泛施行，因此演進更加快速。本書會著重在回答第一本書中最常被問及的實作細節，而不是面面俱到、泛泛而談。

最後，這系列書的創作初衷並非想要被奉為圭臬。請不要這樣看待它們。即使這麼多年過去了，還是發現有許多狀況和案例，需要我們去調整（或在某些案例中，取代）先前堅持的信念。SRE 是一門專業，也是一趟旅程。

希望您會喜歡這本書，而且覺得它能派上用場。本書的編寫協作是出於興趣，不求任何回報。我們很高興有一個不斷成長茁壯的SRE專業社群，可以和大家一起學習進步。一如既往，我們重視您的直接意見回饋，總是因此而受益匪淺。

文章試閱

DevOps的背景
DevOps是一套大致的實踐、準則和文化，旨在打破IT開發、運維、網路和安全的穀倉。為了清楚表達這些理念，John Willis、Damon Edwards、以及Jez Humble提出了CA(L)MS這個有用的首字母略縮詞，幫助記憶DevOps基本原理的關鍵點—代表了文化（Culture）、自動化（Automation）、精實（Lean）； 也參見持續交付、量測（Measurement）及分享（Sharing）。分享和協作是整個DevOps運動的重中之重。在DevOps的方式中，您可以改進一些事物（通常藉由自動化）、測量結果，並與同事們分享這些結果。如此，整個組織也可以進步。所有CALMS的原則，皆有賴崇尚鼓勵與支持的文化氛圍促進之。

DevOps、敏捷開發，以及種種其他業務與軟體再造工程技術，在在體現了於現代世界中，如何把事情辦到最好的普遍世界觀。沒有一個DevOps基本原理的要素是可以輕易彼此分離的，而這本質上是特意為之；然而，有幾個關鍵理念，是可以相對獨立出來個別討論的。

別再有穀倉
第一個關鍵理念是別再有穀倉。這是對以下某些想法的反應：
• 歷史上曾經流行過，但現在看來越來越老套的安排：就是把運維及開發團隊分離。
• 事實上，知識的極度穀倉化、獎勵純粹局部優化、以及缺乏協作，在很多案例中都對業務產生了顯著的負面影響。

意外乃兵家常事
第二個關鍵理念是，意外不僅僅是某個體的個別行為的結果，而是因為當事情不可避免地出錯時，防護措施闕如。例如，一個不良的介面不經意鼓勵了在壓力之下急就章的錯誤行動；當錯誤情況發生時，系統功能不良會使故障無可避免；出毛病的監控系統使人無從得知問題，更不用說出了什麼問題。一些比較傳統、守舊的企業往往具有盲目的文化直（錯）覺，花費九牛二虎之力找到犯錯的人，並懲罰他們。但這樣做難免自食惡果：最明顯的就是，它變相獎勵模糊問題、隱瞞真相和指責他人，在在終究是虧本勾當讓人分散注意力。因此，專注在加速恢復而非預防意外，才是穩賺不賠的生意。

變更應循序漸進
第三個關鍵理念是，變更最好少量而頻繁。試想在一個典型的環境中，有專責變更的委員會，每個月開例會，討論鉅細靡遺的大型主機組態變更計畫，那麼這少量頻繁的變更會是一個激進的新構想。然而，這並不是什麼新構想。以往所有的變更都必須經由資深人員斟酌，並且為效率故應批次處理的陳舊觀念，結果證明竟然或多或少跟最佳實踐背道而馳。做變更是有風險的，沒錯，但正確的應對，是儘可能把您的變更分解為較小的次元件。然後您就可以打造一條穩健並充斥低風險變更的流水線，步步為營把產品從規格、設計以及基礎設施的種種變更中推送出去。這種策略，再結合小規模變更的測試自動化、以及可靠的出錯回滾機制，就促成了變更管理方法論，如持續整合和持續交付或部署。

工具應用與文化息息相關
工具應用是DevOps的一個重要組成部分，這邊特別強調正確的變更管理—今日，變更管理端賴極其特定的工具。然而整體來說，DevOps的倡議者堅決強調組織文化—而不是工具應用—當作是新工作方式採行成功的關鍵。一個良好的文化遇到有毛病的工具應用，仍可以群策群力勉力為之；但反之則不然。俗話說得好，策略只是企業文化的早餐。如同運維，變革本身是艱難的。

量測至關重要
最後，量測在整體業務脈絡中尤其至關重要，比如打破穀倉以及事故解決方面。在這每種環境中，您應以客觀量測的方法，建構「現在發生什麼事了？」的客觀現實，確認您如預期改變當前情況，並且為不同功能間彼此協議的對話，建立客觀基礎（這適用在業務及其他脈絡，比如on-call）。

SRE背景
網站可靠性工程（SRE）這個術語（以及相關的工作職位），是由Google工程副總裁Ben Treynor Sloss所創造的。如我們在前一節中看到的，DevOps是一套廣泛的原則，關乎運維與產品開發之間橫跨整個軟體開發生命週期的協作。SRE是一個職位，是一套我們發現很有效的實踐方式（後面會談到），以及若干使這些實踐增添生氣的信念。如果您認為DevOps是一種基本原理和工作法，就可以論證SRE實作了DevOps所描述的某些基本原理，而且某種程度上比「DevOps工程師」所定義的工作或職位更具體。因此，以某種方式來說，SRE類別實作了DevOps介面。

不像DevOps運動起源於數家公司的領導人或從業人員之間的協作，Google的SRE文化大部分從其周圍的公司繼承過來，甚至在SRE這個術語在業界變得人盡皆知之前。以如此軌跡來看，這個專業整體來說，目前尚未如同DevOps一般預設立場強調文化變革（當然，那並不影射任何事：關於在任意一個組織裡做SRE，文化變革是否必要）。