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