　　大型軟件係統生命周期的絕大部分都處於“使用”階段，而非“設計”或“實現”階段。那麼為什麼我們卻總是認為軟件工程應該首要關注設計和實現呢？在《SRE：Google運維解密》中，Google SRE的關鍵成員解釋瞭他們是如何對軟件進行生命周期的整體性關注的，以及為什麼這樣做能夠幫助Google成功地構建、部署、監控和運維世界上現存的軟件係統。通過閱讀《SRE：Google運維解密》，讀者可以學習到Google工程師在提高係統部署規模、改進可靠性和資源利用效率方麵的指導思想與具體實踐——這些都是可以立即直接應用的寶貴經驗。
　　任何一個想要創建、擴展大規模集成係統的人都應該閱讀《SRE：Google運維解密》。《SRE：Google運維解密》針對如何構建一個可長期維護的係統提供瞭非常寶貴的實踐經驗。

作者簡介

　　Betsy Beyer，是Google 紐約負責SRE 的一名技術文檔作傢。她之前曾為遍布全球的Google 數據中心與Mountain View 硬件運維團隊編寫文檔。在搬到紐約之前，Betsy 是Stanford 大學技術性寫作課程的講師。她曾經學習國際關係與英文文學，並在Stanford和Tulane 獲得學曆。

　　Chris Jones，是Google App Engine 的一名SRE。Google App Engine 是一個PaaS 服務，每天處理超過280 億個請求。他的辦公室在舊金山，他之前的工作包括Google 廣告統計、數據倉庫，以及用戶支持係統的維護。在之前，Chris 曾經在學校IT 行業任職，同時參與過競選數據分析，以及一些BSD 內核的修改。他有計算機工程、經濟學，以及技術政策學的學位。同時他也是一名有執照的職業工程師。

　　Jennifer Petoff，是Google SRE 團隊的一名項目經理，工作地點在都柏林，愛爾蘭。她曾經負責管理大型全球項目，包括：科學研究、工程、人力資源，以及廣告等。Jennifer在加入Google 之前，曾在化工行業任職八年。她獲得瞭Stanford 大學的化學博士與學士學位，同時她還擁有Rochester 大學的心理學學位。

　　Niall Murphy，是Google 愛爾蘭團隊廣告SRE 的負責人。他擁有20 年互聯網行業經驗，目前是INEX（愛爾蘭網絡互聯樞紐）的主席。他曾經寫作以及參與寫作很多科技文章與書籍，包括O’Reilly 齣版的IPv6 Network Administration，以及很多RFC。他目前在參與書寫愛爾蘭互聯網發展史。他擁有計算機科學、數學，以及詩歌學的學曆（他當時一定是想錯瞭！）。他目前與妻子和兩個兒子居住在都柏林。

　　孫宇聰，前Google SRE（2007-2015），山景城總部，曾參與構建運維Youtube 全球CDN網絡，2008年奧運會直播項目，構建維護海量視頻編碼傳輸係統。後參與Google內部雲平颱運維工作，負責運維全球百萬級彆服務器集群，以及Borg、Omega等大規模集群理係統。2015年加入Coding，任CTO一職。迴國後，積極推動國內容器化運維架構升級。目前是開放運維聯盟之應用運維規範製定組，高可用運維規範製定者。

精彩書評

　　我們都知道 Google公司的分布式係統設計和實現在業界遙遙領先，這些分布式係統多年前就已經運行在百萬颱服務器上，很多公司也都在覬覦這麼多服務器是如何運行和管理的。本書揭開瞭這層神秘的麵紗， SRE就是運行和管理這百萬颱服務器和眾多分布式係統的關鍵。
　　多年前，Google是通過發布技術論文幫助業界解決分布式難題的，如今各種分布式係統百花齊放，如何管理這些係統對傳統的運維技術和理念産生瞭極大的挑戰，現在 Google給我們帶來瞭技術指導和實踐。該書匯集瞭 Google多年生産環境的管理經驗，連編寫工作都采用瞭分布式實現的方法，由各個領域的資深專傢聯閤創作而成。可以把本書看作是一座燈塔，很多公司的集群規模還遠達不到 Google的規模，但是參照本書中的技術指導和實踐，不僅可以加速傳統運維嚮 SRE的進化，更重要的是可以幫助公司高效地運維和管理各種復雜的分布式係統。
　　——呂宏利，Google Ads SRE
　　
　　信息技術領域是英文縮寫詞的高産領域，幾乎所有的新概念、新技術和新産品的推齣甚至一場市場營銷的策劃都會伴隨著新的英文縮寫詞的齣現。 SRE這個縮寫，在公司內部不僅代錶瞭一個全新的運維理念和其伴隨的嶄新的工程領域、一套完整的係統運維體係和其對應的實踐，而且也是我和我的好朋友——本書的譯者孫宇聰一起工作瞭數年的戰鬥集體。而本書的作者們也都是這個大集體中的師長和夥伴。
　　係統運維長久以來都依賴實踐積纍之上的口口相傳，經驗通常是領域從業者手裏掌握的秘訣。本書從實踐齣發，匯集瞭眾多業內優秀的係統運維人員的實戰心得，理論基礎和實操指導並重，係統化地闡述瞭在新一代信息係統架構（大規模、分布式、高並發、多業務、多租戶）下係統運維的理念（當前被廣泛接受並被大量實踐的 DevOps就起源於此）、思路、實踐以及對應的組織架構和人員管理的方方麵麵，是係統運維領域從業人員不可多得的參考和學習資料。本書是對新時代係統運維領域實踐的總結和理論升華。
　　本書的譯者孫宇聰在生活中是一個略顯粗獷的大男人，但對於本書的翻譯，他充分發揮瞭自己在這個領域中多年的從業經驗和對係統運維的深刻理解，細緻入微地做到內容和語言兩個方麵的精準和優美，這在翻譯的技術圖書中是非常難得的。
　　——張矩，鋒瑞資本執行董事，前 Google SRE
　　
　　很高興受譯者孫宇聰邀請為該書寫推薦序，這本書是 Google的 SRE部門多年實踐的總結，孫宇聰本人也在 Google SRE部門工作多年。SRE部門在 Google真正落實瞭 DevOps。 SRE工程師在 Google不隻是維護各種綫上服務的穩定性，還要負責保證各項服務的性能，同時負責管理維護數據中心。美國多傢互聯網公司都在依照 Google的方式來組織和運作 SRE部門，可以說 SRE被 Google發揚光大，Google的 SRE實踐正在成為 DevOps的標準。
　　SRE和傳統的 IT運維有很大區彆，SRE真正實現瞭 DevOps：首先， SRE深度參與開發階段的工作，對應用程序的設計實現方式、依賴庫、運行時的資源消耗都有嚴格的規約；其次，SRE工程師本身也要做不少編程工作，來實現各種工具用以自動解決問題和故障，換句話說，SRE強調的是對問題和故障的自動處理，而非人工乾預；再者，按照 SRE的約定，開發人員自行負責程序上綫部署更新，畢竟開發人員對自己開發的程序更熟悉，易於處理程序上綫過程中遇到的問題。總之，作為 Google的 DevOps實踐，SRE非常注重開發和運維職能的結閤，極大地加快瞭業務應用迭代周期，提升瞭 IT對業務的支撐能力。
　　隨著 DevOps在國內的宣傳推廣，國內的很多企業客戶也逐漸接受瞭 DevOps的理念，但是在具體落地實踐 DevOps的過程中缺乏實際案例作為參照。本書的推齣，方便瞭國內廣大 IT人員在落地 DevOps過程中參照 Google的 SRE實踐。非常感謝孫宇聰把這麼好的一本書翻譯成中文。
　　——王璞，數人雲創始人
　　
　　Google首創瞭 SRE這個職業，並將其 SRE思想體係和方法論貢獻齣來匯集成此書。中文版的及時齣版，使得國內廣大運維從業者可以更高效地賞閱並實踐。很榮幸此書在 GOPS全球運維大會首發，高效運維社區將繼續作為 Google SRE國內第1傳播平颱，推進其和《互聯網應用運維框架及能力模型》（本書譯者孫宇聰先生聯閤撰寫）的融閤，促進其在中國運維行業的落地生根、蓬勃發展。
　　——蕭田國，高效運維社區發起人，開放運維聯盟聯閤主席
　　
　　從接觸 Google SRE的概念開始，就感受到它神秘地存在，直到看到英文版的 SRE書籍，纔知道它對傳統運維的顛覆性。本書的麵世，讓國內更多的運維人員接觸到 Google先進的運維理論與實踐。個人堅信這種理論和實踐的提升與改變，纔是運維人的齣路，運維的業務價值、行業價值便也隨之而來。運維也可以“高大上”地存在！
　　——王津銀，“精益運維”發起人；優維科技創始人；開放運維聯盟發起人之一；開放運維聯盟應用標準規範組組長、起草人
　　
　　大型互聯網應用的部署規模從幾韆颱到幾十萬颱不一，隨著軟件係統的復雜度提升也呈現齣越來越龐大的趨勢，如何通過少數人力管理好龐大復雜的應用環境？如何在環境極度復雜的情況下確保軟件的服務質量？如何在確保質量的情況下優化軟件迭代速度？很多問題睏擾著項目管理者、産品經理、軟件工程師、運維人員。本書從 Google所麵臨的問題、價值觀、解決方案、體係建設、實踐等方麵理論結閤實際，非常具備指導意義，每一個希望提高工作效率、改進工作成果的技術和管理人員都應該認真閱讀理解，結閤自身工作環境進行實踐，找齣一條適閤自己的持續發展之路。
　　——莫顯峰，Ucloud聯閤創始人，CTO
　　
　　Google豐富的産品與服務已成為全球多數網民每天生活的一部分，而支撐這許多應用的是其背後龐大的基礎設施。為瞭更有效地保證用戶體驗，Google建立瞭獨樹一幟的運維體係並稱之為 SRE（Site Reliability Engineering）。絕大部分傳統 IT公司會雇傭係統管理員（ sysadmin）來運維復雜的計算機係統，但由於大部分工作依靠手工操作，所以隨著用戶增長，Sysadmin的團隊也必須相應地增長。Google SRE團隊的精華在於研發軟件係統，將運維自動化以替代傳統模型中的人工操作。這本書詳細地描述瞭 Google SRE的原則與理念，並列舉瞭實際案例來說明如何靈活運用這些準則。
　　孫宇聰在 Google任職八年。他不僅精通基礎設施的各個方麵，還熱衷於鑽研平颱架構。他緻力於為中文讀者解析 Google運維的竅門，於是在繁忙的工作之餘，翻譯瞭這本由他的原同事們撰寫的書。由於 Google的規模很大，許多人可能認為 Google的做法無法效仿，但書中描述的原則與道理是可以觸類旁通的。書中提及許多實用的道理，比如， 100%的可用性是不現實的，需要達到這個目標的成本通常遠超於所能獲得的價值，所以 Google會針對每種産品設定一個錯誤預算（容錯率），既能保證用戶體驗又不影響創新和部署的速度。
　　我希望讀者像我一樣，通過閱讀這本書，能學習到如何更有效地運維自己的産品與平颱。
　　——Joe Zhu，Zenlayer創始人
　　
　　Google SRE團隊通過寫作本書為整個運維行業做齣瞭巨大的貢獻。通過本書，他們將指導思想、實踐和常見的應用架構模式以及團隊建設模式共享齣來，揭示瞭 Google如何能夠持續不斷地建設、部署世界級的工程項目，同時保持世界一流的可靠性標準。每個感興趣的人都應該通讀本書，切身嘗試書裏提到的一些想法。
　　Jez Humble，Continuous Delivery和 Lean Enterprise書籍的共同作者
　　
　　我還記得 Google第1次在運維技術論壇上發錶的演講。感覺就像聽瞭一場野生動物專傢針對兩棲爬行動物的專題介紹。演講非常有意思，但是由於演講的內容和觀眾的日常工作感覺距離太遙遠，因此演講的效果並不好。
　　隨著 IT行業的不斷改變，中小型企業的運維實踐逐漸和 Google接軌。突然之間， Google多年打磨、積纍形成的運維實踐變成瞭熱門的行業焦點。對於一個麵臨日益嚴峻的可靠性、可擴展性、可維護性挑戰的行業，這本書真是太及時瞭！
　　——David N. Blank-Edelman，總監，USENIX董事會成員，以及 SREcon 大會的共同創始人
　　
　　自從我離開 Google這座充滿魔力的城堡，我就一直在等這本書麵世，我一直在用書中的思想理念給同事們布道。
　　——Bjo.. rn Rabenstein，SoundCloud 生産工程團隊負責人， Prometheus（開源項目）開發者，前 Google SRE（2013）
　　
　　Google是 SRE理念的發明者。本書不光介紹瞭這個職位的技術細節，還包括瞭其中的思考過程、團隊目標、設計理念以及學到的寶貴課程。如果你想從起源上瞭解 SRE一詞的意義，應該從本書開始。
　　——Russ Allbery，Google SRE，安全工程師
　　
　　本書的作者們和大傢分享瞭 Google SRE團隊的成長經曆，包括其中走過的彎路。 Google憑藉這些實踐經驗，將 Google服務部署到全世界，同時保持世界一流的可靠性。我高度建議任何一個想要創建、擴展大規模集成係統的人閱讀本書。這本書針對如何構造一個可長期維護的係統提供瞭非常寶貴的實踐經驗。
　　——Rik Farrow，USENIX成員
　　
　　開發一個 Gmail這樣的大型分布式係統已經很難瞭。如何運營維護這樣的一套係統，在保障每天不斷更新的同時保障一流的可靠性就更難瞭。這本書就像一套完備的菜譜，收集瞭 Google在實踐過程中積纍的寶貴經驗。希望通過閱讀本書，讀者能夠繞開一些 Google曾經走過的彎路。
　　——Urs Ho..lzle，Google 基礎架構組資深副總裁

前言　 xxxi
序言　 xxxv
第Ⅰ部分　概覽
第1 章　介紹　 2
係統管理員模式　 2
Google 的解決之道：SRE　 4
SRE 方法論　 6
確保長期關注研發工作　 6
在保障服務SLO 的前提下最大化迭代速度　 7
監控係統　 8
應急事件處理　 8
變更管理　 9
需求預測和容量規劃　 9
資源部署　 10
效率與性能　 10
小結　 10
第2 章　Google 生産環境：SRE 視角　 11
硬件　 11
管理物理服務器的係統管理軟件　 13
管理物理服務器　 13
存儲　 14
網絡　 15
其他係統軟件　 16
分布式鎖服務　 16
監控與警報係統　 16
軟件基礎設施　 17
研發環境　 17
莎士比亞搜索：一個示範服務　 18
用戶請求的處理過程　 18
任務和數據的組織方式　 19
第Ⅱ部分　指導思想
第3 章　擁抱風險　 23
管理風險　 23
度量服務的風險　 24
服務的風險容忍度　 25
辨彆消費者服務的風險容忍度　 26
基礎設施服務的風險容忍度　 28
使用錯誤預算的目的　 30
錯誤預算的構建過程　 31
好處　 32
第4 章　服務質量目標　 34
服務質量術語　 34
指標　 34
目標　 35
協議　 36
指標在實踐中的應用　 37
運維人員和最終用戶各關心什麼　 37
指標的收集　 37
匯總　 38
指標的標準化　 39
目標在實踐中的應用　 39
目標的定義　 40
目標的選擇　 40
控製手段　 42
SLO 可以建立用戶預期　 42
協議在實踐中的應用　 43
第5 章　減少瑣事　 44
瑣事的定義　 44
為什麼瑣事越少越好　 45
什麼算作工程工作　 46
瑣事繁多是不是一定不好　 47
小結　 48
第6 章　分布式係統的監控　 49
術語定義　 49
為什麼要監控　 50
對監控係統設置閤理預期　 51
現象與原因　 52
黑盒監控與白盒監控　 53
4 個黃金指標　 53
關於長尾問題　 54
度量指標時采用閤適的精度　 55
簡化，直到不能再簡化　 55
將上述理念整閤起來　 56
監控係統的長期維護　 57
Bigtable SRE ：警報過多的案例　 57
Gmail ：可預知的、可腳本化的人工乾預　 58
長跑　 59
小結　 59
第7 章　Google 的自動化係統的演進　 60
自動化的價值　 60
一緻性　 60
平颱性　 61
修復速度更快　 61
行動速度更快　 62
節省時間　 62
自動化對Google SRE 的價值　 62
自動化的應用案例　 63
Google SRE 的自動化使用案例　 63
自動化分類的層次結構　 64
讓自己脫離工作：自動化所有的東西　 66
舒緩疼痛：將自動化應用到集群上綫中　 67
使用Prodtest 檢測不一緻情況　 68
冪等地解決不一緻情況　 69
專業化傾嚮　 71
以服務為導嚮的集群上綫流程　 72
Borg ：倉庫規模計算機的誕生　 73
可靠性是最基本的功能　 74
建議　 75
第8 章　發布工程　 76
發布工程師的角色　 76
發布工程哲學　 77
自服務模型　 77
追求速度　 77
密閉性　 77
強調策略和流程　 78
持續構建與部署　 78
構建　 78
分支　 79
測試　 79
打包　 79
Rapid 係統　 80
部署　 81
配置管理　 81
小結　 82
不僅僅隻對Google 有用　 83
一開始就進行發布工程　 83
第9 章　簡單化　 85
係統的穩定性與靈活性　 85
乏味是一種美德　 86
我絕對不放棄我的代碼　 86
“負代碼行”作為一個指標　 87
最小 API　 87
模塊化　 87
發布的簡單化　 88
小結　 88
第Ⅲ部分　具體實踐
第10 章　基於時間序列數據進行有效報警　 93
Borgmon 的起源　 94
應用軟件的監控埋點　 95
監控指標的收集　 96
時間序列數據的存儲　 97
標簽與嚮量　 98
Borg 規則計算　 99
報警　 104
監控係統的分片機製　 105
黑盒監控　 106
配置文件的維護　 106
十年之後　 108
第11 章　on-call 輪值　 109
介紹　 109
on-call 工程師的一天　 110
on-call 工作平衡　 111
數量上保持平衡　 111
質量上保持平衡　 111
補貼措施　 112
安全感　 112
避免運維壓力過大　 114
運維壓力過大　 114
奸詐的敵人—運維壓力不夠　 115
小結　 115
第12 章　有效的故障排查手段　 116
理論　 117
實踐　 119
故障報告　 119
定位　 119
檢查　 120
診斷　 122
測試和修復　 124
神奇的負麵結果　 125
治愈　 126
案例分析　 127
使故障排查更簡單　 130
小結　 130
第13 章　緊急事件響應　 131
當係統齣現問題時怎麼辦　 131
測試導緻的緊急事故　 132
細節　 132
響應　 132
事後總結　 132
變更部署帶來的緊急事故　 133
細節　 133
事故響應　 134
事後總結　 134
流程導緻的嚴重事故　 135
細節　 135
災難響應　 136
事後總結　 136
所有的問題都有解決方案　 137
嚮過去學習，而不是重復它　 138
為事故保 SRE：Google運維解密下載 mobi epub pdf txt 電子書

SRE：Google運維解密 pdf epub mobi txt 電子書下載

想要找書就要到求知書站

tushu.tinynews.org

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!