掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
大型網站運維:從系統管理到SRE 版權信息
- ISBN：9787121416125
- 條形碼：9787121416125 ; 978-7-121-41612-5
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
大型網站運維:從系統管理到SRE 本書特色
適讀人群 ：開發人員、網站運維人員、SRE人員網易運維專家、SRE團隊Leader顧賢杰領銜撰寫，凝聚了網易10年百億級別大型系統運維經驗，值得閱讀！從Google SRE到網易SRE的實踐之旅，中國技術團隊的實踐總結！
大型網站運維:從系統管理到SRE 內容簡介
運維發展到現在，與很初相比發生了巨大的變化。10 多年的互聯網發展，讓國內的運維 經歷了快速的變革，開始慢慢地和國外接軌，甚至在部分場景有單獨的演化。DevOps 和SRE 作為運維領域的兩個演化方向，在很近幾年獲得了很多關注，也有很多公司進行了相關的實 踐。與DevOps 遍地開花的情況相比，SRE 在國內的發展稍顯低調。《SRE：Google 運維解密》 一書對國內外運維領域有很大沖擊。本書作者作為一直工作在一線的運維工程師，理所當然 地對SRE 相關理念進行了實踐，本書可以說是對SRE 領域階段性的實踐總結。 本書主要對傳統運維和SRE 進行不同對比，讓大家了解運維工程師在實踐SRE 理念 時，關注的點和具體的實踐經驗。本書的前半部分更多地注重SRE 在實際工作中對融入 開發團隊、監控建設、變更管理、容量管理、異常響應、穩定性治理、事故復盤、用戶體 驗管理等方面的實踐和落地。 在對SRE 的工作有了一定了解后，本書會針對重要業務保障場景進行實戰講解。本 書很后部分對SRE 工作中涉及的一些技術進行了概述，以便有興趣的同學了解SRE 相關 的技術點。
大型網站運維:從系統管理到SRE 目錄
第1章 關于SRE 1
1.1 為什么會引入SRE 2
1.2 DevOps和SRE對比 5
1.2.1 DevOps的發展 5
1.2.2 SRE的發展 6
1.3 選擇SRE 8
1.4 SRE的未來 9
第2章 SRE在組織內部的定位 11
2.1 如何介入組織 12
2.2 SRE工作著力點 16
2.3 如何衡量工作 19
2.4 貢獻價值 22
第3章 監控建設 25
3.1 什么是好的監控服務 25
3.1.1 穩定 25
3.1.2 準確 27
3.1.3 易用 29
3.2 監控系統的設計邏輯分析 29
3.2.1 數據生產 30
3.2.2 數據上報 31
3.2.3 數據處理 33
3.2.4 數據存儲 34
3.2.5 數據使用 36
3.3 典型監控應用場景 41
3.3.1 系統監控 41
3.3.2 應用監控 42
3.3.3 終端監控 44
3.3.4 秒級監控 45
3.3.5 監控大盤 46
3.3.6 鏈路監控 46
3.4 報警治理 47
3.5 容器監控 50
3.6 監控智能化 51
第4章 變更管理 53
4.1 變更管理機制 54
4.1.1 傳統運維的變更管理 55
4.1.2 DevOps的變更管理 57
4.1.3 SRE的變更管理 59
4.1.4 變更管理實踐總結 61
4.2 變更控制 62
4.2.1 如何建設好的變更控制 62
4.2.2 制定符合業務需求的變更控制機制 64
4.3 穩定性和迭代速度的權衡 66
4.4 變更風險控制 68
4.5 總結 70
第5章 異常響應 71
5.1 異常的定義 71
5.2 事故/事件定義 73
5.2.1 區分事件和事故 73
5.2.2 事故等級制度 74
5.3 異常響應流程 76
5.4 如何處理值班過程中的異常響應 79
5.5 應急溝通機制 82
5.6 關于線上問題的ROC 84
第6章 服務穩定性治理 88
6.1 SLI/SLO/SLA的制定和落地 88
6.1.1 SLI的制定和應用 89
6.1.2 SLO的計算和應用 90
6.1.3 SLA的計算和應用 91
6.2 故障預防 92
6.3 抑制不可控因素 95
6.4 故障演練 97
6.4.1 故障梳理 97
6.4.2 故障預案 98
6.4.3 混濁工程 98
6.5 故障自愈 100
6.6 業務MTTR 102
6.6.1 關于故障修復MTTR 102
6.6.2 關于故障解決MTTR 104
6.7 災備建設 105
6.8 總結 109
第7章 事故復盤 110
7.1 關于事故復盤 112
7.1.1 事故復盤初級階段 112
7.1.2 事故復盤中級階段 113
7.1.3 事故復盤成熟階段 113
7.2 如何提升事故復盤質量 115
7.2.1 事故復盤深度 116
7.2.2 事故復盤報告 118
7.3 事故分析的邏輯和原則 119
7.4 事故責任的劃分邏輯 123
7.5 事后跟進 126
7.6 基于事故/事件的學習 128
第8章 容量管理 131
8.1 容量管理的目標 131
8.2 容量管理的方法和策略 132
8.2.1 傳統評估方法 133
8.2.2 IT資源成本的構成 133
8.2.3 容量水位的定義 134
8.2.4 容量管理策略 137
8.3 容量分析系統建設 137
8.3.1 業務負載平臺 137
8.3.2 巡檢管理平臺 139
8.3.3 監控系統和CMDB系統 142
8.4 容量優化方式 143
8.4.1 業務容量優化 143
8.4.2 資源容量優化 143
8.4.3 架構容量優化 146
8.5 容量預案 151
8.6 總結 153
第9章 用戶體驗 154
9.1 外部用戶體驗和內部用戶體驗 155
9.1.1 外部用戶體驗 156
9.1.2 內部用戶體驗 158
9.2 影響用戶體驗的要素 159
9.3 外部用戶體驗的改進策略 162
9.4 內部用戶體驗的改進策略 165
9.4.1 數據兼容性 165
9.4.2 工作流程 167
9.4.3 執行效率 169
第10章 重要業務活動保障 172
10.1 重要業務活動的資源準備 173
10.1.1 容量規劃 173
10.1.2 資源交付規劃 175
10.1.3 技術優化 178
10.2 參與運營活動評估 181
10.3 重要業務活動穩定性預案 184
10.4 重要業務活動準備階段的工作重點 187
10.5 重要業務活動的變更執行要求 190
10.6 重要業務活動的運維人力 192
10.7 重要業務活動的收尾 193
第11章 運維操作基礎 196
11.1 網絡基礎 197
11.1.1 ARP 197
11.1.2 路由 200
11.2 4/7層協議 204
11.2.1 4層協議 204
11.2.2 7層協議 208
11.3 內核參數調優 213
11.3.1 TCP網絡堆棧內存 214
11.3.2 TCP連接數優化 215
11.3.3 TCP高并發優化 216
11.3.4 網絡參數額外調整項 217
11.3.5 TCP擁堵算法 218
11.4 常見命令行 221
11.4.1 查看數據指標 222
11.4.2 網絡數據包分析 223
11.5 配置管理工具 227
11.5.1 Ansible 228
11.5.2 CFEngine 229
11.5.3 Chef 231
11.5.4 Puppet 234
11.5.5 Salt 237
11.5.6 配置管理工具的匯總說明 240
11.5.7 云環境下的配置管理工具演化 241
11.6 基礎設施即代碼 242
11.7 關于運維操作的未來 244
第12章 基礎組件運維 245
12.1 負載均衡中間件 245
12.1.1 算法邏輯的影響 246
12.1.2 附加特性的作用 252
12.1.3 負載均衡方案 254
12.1.4 負載均衡總結 256
12.2 消息隊列中間件 258
12.2.1 消息隊列方案的技術決策 259
12.2.2 消息隊列的技術演化 261
12.3 緩存中間件 262
12.3.1 緩存中間件的技術關注點 263
12.3.2 緩存中間件的選型策略 265
12.3.3 緩存中間件的技術演化 270
12.4 數據庫 272
12.4.1 SQL數據庫技術的選擇 273
12.4.2 SQL數據庫的配置注意事項 276
12.4.3 NoSQL數據庫技術的選擇 279
12.4.4 時序數據庫技術 282
12.5 組件運維 283
第13章 云計算和容器 284
13.1 云計算基礎 285
13.1.1 云計算平臺運維 286
13.1.2 云計算平臺上的產品運維 288
13.2 虛擬化 290
13.3 容器 292
13.4 云存儲 296
13.5 云網絡 299
13.6 混合云 302
13.7 云原生 305
13.7.1 云原生的需求情況 305
13.7.2 云原生的發展 307
13.7.3 云原生的展望 309
展開全部
大型網站運維:從系統管理到SRE 節選
2.2 SRE工作著力點 SRE團隊每天都會執行大量的運維操作，線上的運維需求源源不斷，如果不對線上的運維需求進行良好的梳理和歸納，沒有形成針對業務的運維能力輸出，業務團隊很容易將SRE團隊和傳統運維團隊等同看待。在大型公司內部，雖然業務團隊會使用公司共有的基礎設施和流程，但是在某些方面還會形成業務團隊獨有的運作方式和風格。業務團隊獨有的運作方式和風格，可能對SRE團隊推行統一的工具或流程有一定的阻礙。不同的業務風格會非常挑戰SRE團隊的工作能力，可以說這是*考驗SRE團隊工作的部分。 從公司層看，SRE團隊可能會同時對接多個業務線，SRE團隊日常的工作會在多個業務線間來回切換。SRE團隊的日常工作一方面是運維任務跟進；另一方面是針對不同的業務團隊，設計、適配、推廣不同的運維工具或架構。 制定運維計劃后，就得開始考慮將制定的運維計劃落地。針對各個業務團隊情況，SRE團隊在做技術工作前還需要做一些關于人或團隊的工作。 1．融入團隊 如之前所說，在新的業務模式下SRE團隊會直接和業務團隊一起工作，但一起工作并不代表SRE團隊會了解業務團隊。為了能夠順利開展工作，SRE團隊需要對業務團隊有深入的了解，了解業務團隊的成員架構、開發模式、溝通“語言”。只有深入地了解業務團隊后，SRE團隊才能很好地和業務團隊中的其他成員用一樣的“語言”交流。要求SRE團隊成員有開發工程師背景很重要的一個原因就是：只有程序員才知道程序員的術語。當一個程序員說堆棧溢出、自旋鎖、CPU Cache Line等術語時，傳統運維工程師可能無法理解術語真實的邏輯，而SRE工程師和程序員用一樣的術語溝通，可以正確理解對方描述的業務特性和場景。例如，要了解“00后”就得用“00后”的“黑話”。用同樣的“語言”溝通，一般會有更多的認同感，業務團隊和SRE團隊之間的溝通會沒有隔閡。另外了解業務團隊的架構，可以讓業務團隊和SRE團隊之間的溝通和問題處理變得更加高效，不至于出現有問題時卻不知道找誰的情況。 2．建立信任獲得授權 用傳統的運維方式跟進業務時，有時候難免在運維操作或理解上出現誤差，導致業務團隊質疑運維團隊對線上問題的判斷方式和處理邏輯。運維團隊的某個成員搞出一個線上事故后，會發現業務團隊看待他都是戴著有色眼鏡的。傳統運維團隊轉變為SRE團隊后，為了更好地運維線上產品，SRE團隊會尤其注重和業務團隊的關系維護。 團隊間要建立信任，可以說非常簡單，也可以說非常困難，但是*根本的還是看技術，粗暴點說就是，“shut up,show me code”。傳統運維團隊想在技術上讓業務團隊信服，除非很巧合地遇到了線上業務故障，運維團隊用自己的專業技能力挽狂瀾。但不幸的是，更多的時候是運維團隊被業務團隊發現操作不規范和考慮線上問題不全面等問題。簡單來說就是運維工程師感覺自己空有一身“本領”，但是沒有合適的地方輸出，某次操作失誤會導致形象崩塌。所以傳統運維工程師總是處于公司內部人員的“鄙視鏈底端”，就連運維工程師自己也常調侃自己是“背鍋”的。 在傳統運維團隊轉變為SRE團隊的過程中，傳統運維團隊也對這方面問題有過擔憂。但在實際落地時，傳統運維團隊驚喜地發現轉變之后的SRE團隊在獲得團隊信任方面有自己獨特的優勢。相比傳統的運維團隊，SRE團隊深入業務底層，同時具備程序員的“黑話”能力，對線上問題的溝通和判讀會更加容易被開發團隊理解和認可。 例如，之前有一次，SRE團隊的運維工程師直接坐在開發工程師后面和他一起Review線上代碼邏輯，運維工程師通過對代碼邏輯的解讀和討論，迅速地和開發工程師達成了線上運維操作的邏輯和設計。相比傳統運維團隊只憑直覺和經驗去挑戰開發工程師的實現思路，這種工作方式的轉變是一個巨大的飛躍。傳統運維工程師只通過自己的經驗或直覺和開發工程師溝通，很多時候是和開發工程師之間存在一定隔閡的，轉變思路后和開發工程師一起用開發工程師的方式處理問題才是更可行的辦法。 SRE團隊得到業務團隊的信任，往往是為下一步工作做鋪墊的。當業務團隊開始信任SRE團隊的穩定性保障能力后，SRE團隊就可以推動一些運維技術或架構的改變。SRE團隊執行一些穩定性改進策略時，會要求開發團隊配合性地做一些業務邏輯外的事情，因為開發工程師會對業務邏輯外的事情有一些抵觸情緒，如果處理不好，開發工程師會直接改進事項，所以SRE團隊獲得業務團隊在某方面的授權就變得尤為重要。 SRE團隊很有必要在技術之外加強自己的溝通、說服能力。傳統的運維團隊要得到某個事項的授權，一般的流程是說個方案，然后找領導溝通，通過上層領導授權去推動這個事項的落地。SRE團隊則會選擇向業務團隊解釋他的方案，和內部溝通一致后得到授權。相比之前的方式，SRE團隊得到授權的方式顯然更加容易得到業務團隊的支持，更容易推行SRE團隊想推行的東西。 3．推動業務發展 可能有人會說運維團隊和業務發展有什么關系，只要保障業務穩定就好了。這個想法其實是有問題的。公司為什么要有運維團隊？拋開技術不講，從老板的角度看，運維團隊就是為了線上不停擺，為了業務順利發展，為了業務不受損失，整個公司的資源都是為了業務發展而準備的，所以反過來講如果運維團隊能推動業務發展，那么是不是就能獲得更多的資源呢？ 傳統運維團隊其實能做的事情和業務不是很多，更多的是被動地應對業務的需求變化，可以說是被業務拖著走的，這是因為有以下兩個因素。 （1）傳統運維團隊和業務團隊有隔閡，沒有很多的溝通，平時無從談起對業務的了解。 （2）傳統運維團隊處于被動接受需求的一方，了解并深入業務層的特性不是傳統運維的績效指標。 當然這些情況也在發生一些變化，如*近兩年越來越多的運維工程師會有危機感，進而提到要轉型做業務運維工程師。這其實也說明了一個趨勢：傳統運維都意識到了新技術的挑戰，不得不轉型。 從我個人轉變的感觸來說，轉變為SRE后，運維團隊針對業務層面的需求可以做更多的事情。例如，之前有遇到一個業務上“服務發現”的需求，粗看是開發代碼的問題，傳統運維團隊可能就會想這個需求是開發團隊的工作，運維團隊不用參與。但如果細致地分析業務需求和設計邏輯后，就會發現這個需求完全可以通過SRE的工具鏈結合少量的代碼開發來完成。SRE團隊在業務層越深入，開發的工具可能就越完善和豐富，這樣的場景也會越來越多。 另外相比之前系統管理員、應用運維工程師等運維角色，SRE團隊會更加注重以產品的角度看運維，而不只是簡單地完成業務的運維操作需求。SRE團隊通過梳理業務特性、制定業務流程、定制自動化工具等多種方式，主動地改進業務的迭代效率，簡單來說就是提升產品發布等各個環節的能效，同時通過積極的策略（使用自動化工具和SRE手段）來降低迭代速度帶來的不穩定因素。
大型網站運維:從系統管理到SRE 作者簡介
顧賢杰 網易運維專家、SRE團隊Leader，10多年來一直聚焦互聯網業務運維和穩定性建設。在互聯網業務運維方面經驗豐富，曾負責網易博客、相冊、即時通信、支付、電商、賬號系統、云音樂等眾多產品的運維工作。在金融支付機房設計、高性能負載均衡建設、業務雙機房改造部署、災備建設等多個運維領域均有實踐，設計過海量服務器運維工具平臺，負責的產品服務了上億的互聯網用戶。 目前的運維研究方向：海量服務器穩定性治理、基礎設施即代碼、混合云/云原生體系下的運維平臺建設。 徐 赟 網易資深運維開發工程師，運維開發團隊技術Leader。參與并主導杭研運維體系建設，包括監控、流程、發布、審批等運維領域。持續探索運維自動化、智能化、一體化建設，為網易云音樂、網易傳媒、網易支付等上百個產品提供高效穩定的運維服務。 顏中冠 網易技術經理、資深架構師，有16年的互聯網一線研發和架構經驗。曾負責億級統一認證項目，主持網易帳號異地雙機房建設，以及網易云計算業務中臺搭建，負責多個對外億級商業化項目研發。
書友推薦
- >
上帝之肋:男人的真實旅程
- >
回憶愛瑪儂
- >
名家帶你讀魯迅:朝花夕拾
- >
伊索寓言-世界文學名著典藏-全譯本
- >
李白與唐代文化
- >
自卑與超越
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
二體千字文
本類暢銷
