SRE：Google運維解密

純陽書評（公衆號:純陽書評／微信號:chimbusco88）谷歌不愧是創新公司中的佼佼者！它的創新能力不止體現在產品和服務，還體現在了組織、人力資源、管理、商業模式等各個方面，而這本書講的則是它在IT運維工作方面的創新。這本書的主題是谷歌公司突破傳統IT運維工作模式和形態，將其發展到一個叫做sre的階段，使這項工作擁有了新的內涵和組織形式，從其變化的幅度來看，已經超越變革的範疇，堪稱正在引領一場包含軟件工程要素的運維革命！ 傳統IT運維工作存在兩大難題。 一是IT運維團隊與軟件工程團隊的摩擦問題一直無法有效協調解決。軟件工程團隊希望能夠不斷地對在線系統進行迭代升級，所謂求新求快。而it運維團隊則希望系統上線以後永不改變，所謂求穩求安，所以兩個團隊總是存在摩擦。 二是IT運維團隊人員的軟件工程技能無法得到培養和發揮，員工的工作成就感無法有效得到滿足。 以上兩點都不利於系統的穩健部署和可靠運行，阻礙了系統可用性、可靠性的穩步提升。 谷歌公司的sre本質上是一種開發運維一體化的理念，一方面強調軟件工程師參與運維工作，與運維工程師共保系統的穩定可靠運行；另一方面運維工程師既要參與系統的研發工作，以在產品階段就提高系統的質量屬性，也要通過開發運維工具，提高運維工作的自動化水平，消除運維工作中的瑣事，讓運維工程師超過50%的時間用於工程開發工作。 通過sre的創設，谷歌成功的破解了傳統運維工作中存在的難題，提高了運維工作的自動化水平，控制了運維團隊的規模，改善了運維工程師的工作狀態，實現了開發與運維的一體化，有力的提升了系統可靠性和服務質量水平。 本書以論文集的形式闡述了谷歌關於sre的理念、實踐和管理經驗，內容新穎，讀起來令人振奮，所以建議所有IT工作者不管是否從事運維工作都要抽時間讀一讀。 可能書中有些理念過於超前，實際工作中不一定具備實施的條件，但是作爲it工作實踐發展的一個新方向，我們要心嚮往之。

運維幹了15年，搞技術8年，搞流程、管理7年。初讀了這本谷歌SRE運維方法論，發現這套理論本質並沒有發明新工作，而是又重新思考定義了一套預防、應對和解決系統故障的體系。這套體系包括： 1. 從“救火英雄”到“消防工程師”的轉變傳統運維（Ops）的範式：反應式： 故障發生 -> 緊急響應 -> 排查修復 -> 恢復服務。運維團隊常常被視爲“救火隊”。英雄主義： 依賴個別資深工程師的個人經驗和臨場發揮，這不可複製，也無法規模化。指標模糊： 對“穩定”和“可用”的定義模糊，通常是“沒報警就是正常”。SRE的範式：前瞻式： 核心是預防。通過設計、自動化、容量規劃等手段，在故障發生前就儘可能地消除風險。工程化： 用軟件工程的方法解決運維問題。自動化一切可以自動化的（如發佈、擴縮容、故障處理），將人力從重複勞動中解放出來，投入到更高價值的工程項目中。數據驅動： 引入 SLO（服務水平目標） 和 SLI（服務水平指標） 等概念，精確地定義“多穩定纔算穩定”，並用 Error Budget（錯誤預算） 來量化風險，科學地平衡新功能發佈與系統穩定性。本質： SRE不是發明了“防火”這件事，而是重新定義了角色——從被動等待火災發生的“救火員”，變成了主動設計防火系統、制定消防規範、進行防火演習的“消防工程師”。 2. 重新定義“故障”：從二元對立到連續光譜傳統上，我們認爲系統“正常”或“故障”。但SRE通過SLO和錯誤預算，引入了一個灰度概念。錯誤預算： 允許的不可用時間。例如，99.9%的SLO意味着一個月有43.2分鐘的不可用時間是“被允許的”。意義： 這讓穩定性和創新速度不再是零和遊戲。只要錯誤預算沒有耗盡，開發團隊就可以放心地發佈新功能。如果預算即將耗盡，則整個團隊（而不僅僅是SRE）都需要集中精力提升穩定性。這本質上是將技術風險轉化爲一種可管理、可度量的資源。 3. 文化變革：共同的責任制這是SRE最核心、也最難被模仿的部分。傳統模式： 開發（Dev）寫代碼，運維（Ops）保穩定。兩者目標常有衝突：開發想快速迭代，運維想減少變更。SRE模式： “You build it, you run it.” 開發團隊需要對服務的全生命週期負責。SRE團隊則作爲顧問、賦能者和“強制函數”，通過提供平臺、工具和最佳實踐，並監督SLO的達成情況，來幫助開發團隊更好地“運行”自己的服務。本質： SRE不是把“運維”的職責從開發身上拿走，而是將“運維”的理念和能力賦予開發。它是一種工作文化和責任劃分的重構。 4. 對“應急響應”的再思考：從慌亂到演練SRE沒有發明“應急響應”，但它將其系統化了。應急預案： 針對預期內的故障，有預先寫好的、經過驗證的應對方案。非相關事件模擬： 通過故意在線上製造故障（如混沌工程），來持續檢驗系統的韌性和團隊的響應能力。覆盤文化： 強調Blameless Postmortem（免責事後覆盤），焦點是找出導致故障的系統性根源並修復它，而不是追究個人責任。這確保了組織能從每一次故障中學習並進化。 谷歌的SRE可以看作是對“如何管理複雜軟件系統”這一經典問題的一次集大成的、系統性的回答。• 它沒有發明新工作，而是重新組合並昇華了已有工作（監控、部署、變更管理、應急響應）的目標和方法。• 它的核心貢獻在於引入了一系列可操作的工程框架（SLO/Error Budget）和深刻的文化原則（共享責任、工程導向、免責覆盤），將原本依賴個人經驗的“運維藝術”，轉變成了可衡量、可複製、可規模化的“運維科學”。 最終，SRE提供了一套通用的語言和思維模型，讓開發、運維、產品經理等不同角色能夠在一個統一的框架下，就係統的可靠性目標進行溝通和決策。這正是它能夠超越谷歌，成爲整個行業標杆的原因。

《SRE:google運維解密》，正如書名，這是一本以SRE爲視角的介紹google運維過程的書。在實踐中SRE集運維和開發雙重角色爲一身，既是操作員又是設計師，這一點是google SRE和普通的運維人員最大的區別。 google SRE的核心指導思想可以分爲4大類： ● 災難預案與演習 ● 書寫事後總結的文化 ● 自動化與降低日常運維負載 ● 結構化的、理智的決策 以上幾個部分基本上是全書的概要，其中“自動化與降低日常運維負載”部分是google運維的真正祕密，也是本書的精華所在，可惜關鍵點沒有展開說，需要結合其他相關書籍來加深瞭解。再者，google SRE反覆強調的事故總結“對事不對人”確實讓人羨慕，但也要結合國情來分析。對事不對人，知易行難，特別是在我國以計劃經濟爲主的體制下，尤甚！靜態組織架構更注重穩定和控制，資源分配和控制更爲集中，有助於實現規模經濟和效率最大化‌，而動態組織結架構則適用於變化快、競爭激烈的環境，能夠快速調整策略和資源配置，但需要較高的管理水平和協調能力。google的事後總結模式可能只適用於google，畢竟各個行業有所不同，不同的行業內部進行事後總結的原動力各有不同。另外，能夠像google那樣實現高度智能化的公司也不多，假如是人工負責的環節出了問題，如果沒有問責機制，對於某些沒有責任心的人而言就沒有約束力。

通過這本書，快速地大致瞭解了 SRE 和普通交付運維的區別，以及 SRE 在團隊中應該扮演的角色。 谷歌是一家偉大的公司，但它之所以偉大，是由一個一個優秀的個體支撐起來的。谷歌的 SRE 團隊構建了令人驚歎、穩固且可擴展的軟件基礎設施，能夠支撐谷歌各產品線的快速發佈與上線，以及線上運維；同時這個團隊也有自己獨特的文化，積極擁抱並參與到谷歌研發團隊的研發流程中去。 SRE 既是運維繫統的設計者，又是這個系統的一線使用者！ 感覺在國內落地是有一定難度的，只能將其中關鍵的精髓部分逐步引入並注入團隊中。道阻且長，行則將至。

大概瀏覽了本書，感覺SRE核心思想和古代軍事理論孫子兵法有些類似，核心做好三點廟算能力，突發事件處理能力，覆盤總結能力。最後形成自動化機制，達到良性循環的閉環效果。最最後補充一句：三分天註定，七分靠運維。

2200年前，西西里島東南端敘拉古城外蜿蜒的沙灘上，給我一個支點撬起地球的阿基米德，以這樣的方式思考着他想描繪的世界：眼前的沙灘，天下所有沙漠中的沙礫，能不能用一個數字表達出來。他給出了這樣一個表述：十的一百次方。後來的科學證明了阿基米德智慧的超凡卓著。實際上，世界上的沙礫的確沒有那麼多，甚至宇宙中以分子、粒子、原子存在事物的總和都沒有這樣的量。人們將這個人類不可企及的理想量，命名爲googol。 2200年後，兩位斯坦福大學的年輕人產生了一個堪比阿基米德的人生理想，他們想要收集和整理無盡的信息海洋裏的所有信息，幫助需要的人快速準確地找到這片汪洋中的任意一滴水。googol的同音詞google，在漢語中被翻譯爲“谷歌”。

應該有一種職業是專注於整個軟件系統的生命週期管理。對於Google，就是SRE。 內容很不錯，作爲Google長期運維經驗的總結，滿滿乾貨，運維必讀，五星推薦。 從一個運維工程師的角度來看，書中的各種內容都是羨慕嫉妒恨。 花了兩個月的時間，終於看到結語了，感覺自己終於鬆了一口氣，這麼厚的一本書終於看完了。當然是帶着複雜的心情——遠超於我們水平的Google分享出它的運維經驗，甚是驚喜；書中介紹到他們的運維人員爲企業或是世界所作出的貢獻，十分羨慕；在閱讀過程中，處處感受到我們和他們的差距，五味雜陳；當看到某些地方我們原本可以採用更好的方式時，只能嘆息。 對我們來說，運維，依舊有很長的一條路要走。雖然國內的企業，在運維方面，發展也是相當迅速的，尤其是互聯網公司。但還是期盼着什麼時候，國內的運維也能達到世界級領先的水平，帶領運維界進行下一次變革。

讀了好幾遍，每一遍都有新的收穫 SRE需要管理層的認可和支持，這個非常重要，如果管理層都不理解，發生在質疑sre在幹什麼？SRE是不是可以更少人員，SRE是不是就是幹發佈的，是不是幹髒活累活的初級工程師， 那就完了，趕緊跑路吧

紙質書讀過一遍，電子書讀過一遍，今天閒來無事又速讀了一遍劃線筆記。經典就是經典。

技術部分看不太懂，理念方面的經驗值得學習。