推薦序一
推薦序二
譯者序
序言一
序言二
前言
致謝
作者簡介
第1章進入混沌工程的世界1
1.1什麼是混沌工程2
1.2混沌工程的動機3
1.2.1評估風險和成本，並設定SLI、SLO和SLA3
1.2.2在整體上測試繫統4
1.2.3找到“湧現性”特性5
1.3混沌工程的四個步驟5
1.3.1確保可觀測性7
1.3.2定義穩態8
1.3.3形成假設9
1.3.4運行實驗並證明（或反駁）
你的假設9
1.4什麼不是混沌工程10
1.5初識混沌工程11
1.5.1FizzBuzz即服務11
1.5.2漫漫長夜11
1.5.3後續12
1.5.4混沌工程簡述13
總結13
部分混沌工程基礎
第2章來碗混沌與爆炸半徑17
2.1設置使用本書中的代碼17
2.2場景18
2.3Linux取證10120
2.3.1退出碼20
2.3.2終止進程21
2.3.3內存溢出殺手23
2.4個混沌實驗25
2.4.1確保可觀測性29
2.4.2定義穩態29
2.4.3形成假設30
2.4.4運行實驗30
2.5爆炸半徑31
2.6深入挖掘33
2.6.1拯救世界35
總結36
第3章可觀測性38
3.1應用程序運行緩慢39
3.2USE方法39
3.3資源41
3.3.1繫統概述43
3.3.2block I/O44
3.3.3網絡48
3.3.4RAM52
3.3.5CPU59
3.3.6操作繫統65
3.4應用程序67
3.4.1cProfile68
3.4.2BCC和Python69
3.5自動化：使用時序數據庫71
3.5.1Prometheus和Grafana71
3.6延伸閱讀74
總結75
第4章數據庫故障和生產環境中的
測試76
4.1我們在做WordPress76
4.2弱點78
4.2.1實驗1：磁盤慢了79
4.2.2實驗2：網絡慢了83
4.3在生產環境中測試88
總結90
第二部分混沌工程實戰
第5章剖析Docker93
5.1我的（Docker化的）應用程序
運行緩慢94
5.1.1架構94
5.2Docker簡史95
5.2.1仿真、模擬和虛擬化95
5.2.2VM和容器97
5.3Linux容器和Docker99
5.4Docker原理102
5.4.1使用chroot變更進程的
路徑102
5.4.2實現一個簡單的容器（-ish）
第1部分：使用chroot105
5.4.3實驗 1：一個容器可以阻止
另一個容器寫磁盤嗎107
5.4.4使用Linux命名空間隔離
進程111
5.4.5Docker和命名空間114
5.5實驗2：終止其他PID命名空間
中的進程116
5.5.1實現一個簡單的容器（-ish）
第2部分：命名空間118
5.5.2使用cgroups限制進程的資源
使用120
5.6實驗3：使用你能找到的所有
CPU126
5.7實驗4：使用過多內存128
5.7.1實現一個簡單的容器（-ish）
第 3 部分：cgroups130
5.8Docker和網絡133
5.8.1capabilities和seccomp137
5.9Docker揭秘140
5.10修復我的（Docker化的）應用
程序運行緩慢的問題141
5.10.1啟動Meower141
5.10.2為什麼應用程序運行緩慢143
5.11實驗5：使用Pumba讓容器的
網絡變慢143
5.11.1Pumba：Docker混沌工程
工具143
5.11.2運行混沌實驗144
5.12其他主題147
5.12.1Docker daemon重啟148
5.12.2鏡像layer的存儲148
5.12.3高級網絡148
5.12.4安全149
總結149
第6章你要調用誰？繫統調用
破壞者150
6.1場景：恭喜你升職了150
6.1.1System X：如果大家都在
用，但沒人維護，是不是
廢棄軟件151
6.2簡單回顧繫統調用153
6.2.1了解繫統調用154
6.2.2使用標準C庫和glibc156
6.3如何觀測進程的繫統調用158
6.3.1strace和sleep158
6.3.2strace和System X161
6.3.3strace的問題：開銷162
6.3.4BPF163
6.3.5其他選擇166
6.4為樂趣和收益阻塞繫統調用
第1部分：strace167
6.4.1實驗1：破壞close繫統
調用167
6.4.2實驗2：破壞write繫統
調用171
6.5為樂趣和收益阻塞繫統調用
第2部分：seccomp173
6.5.1seccomp 的簡單方法：使用Docker173
6.5.2seccomp 的困難方法：使用libseccomp175
總結177
第7章JVM故障注入178
7.1場景178
7.1.1FizzBuzzEnterpriseEdition
介紹179
7.1.2環顧FizzBuzzEnterprise-
Edition179
7.2混沌工程和Java180
7.2.1實驗的思路181
7.2.2實驗的計劃182
7.2.3JVM字節碼簡介183
7.2.4實驗的實現190
7.3已有的工具196
7.3.1Byteman196
7.3.2Byte-Monkey198
7.3.3Spring Boot的Chaos
Monkey200
7.4延伸閱讀200
總結201
第8章應用級故障注入202
8.1場景202
8.1.1實現細節：混沌之前204
8.2實驗1：Redis延遲208
8.2.1實驗1的計劃209
8.2.2實驗1的穩態209
8.2.3實驗1的實現210
8.2.4實驗1的執行212
8.2.5實驗1的討論213
8.3實驗2：失敗的請求213
8.3.1實驗2的計劃214
8.3.2實驗2的實現214
8.3.3實驗2的執行215
8.4應用程序與基礎設施216
總結217
第9章我的瀏覽器中有一隻“猴子”218
9.1場景218
9.1.1Pgweb219
9.1.2Pgweb實現細節220
9.2實驗1：增加延遲222
9.2.1實驗1的計劃223
9.2.2實驗1的穩態223
9.2.3實驗1的實現224
9.2.4實驗1的執行226
9.3實驗2：添加故障227
9.3.1實驗2的實現227
9.3.2實驗2的執行229
9.4其他好知道的話題229
9.4.1Fetch API229
9.4.2Throttling230
9.4.3工具：Greasemonkey和Tampermonkey232
總結232
第三部分Kubernetes中的混沌工程
第10章Kubernetes中的混沌235
10.1將東西移植到Kubernetes236
10.1.1High-Profile 項目文檔237
10.1.2Goldpinger是什麼237
10.2Kubernetes是什麼238
10.2.1Kubernetes簡史238
10.2.2Kubernetes能為你做
什麼239
10.3搭建Kubernetes集群241
10.3.1使用Minikube241
10.3.2啟動一個集群241
10.4測試運行在Kubernetes上的
軟件243
10.4.1運行ICANT項目243
10.4.2實驗1：終止50%的
Pod251
10.4.3派對技巧：時尚地終止
Pod256
10.4.4實驗2：引入網絡緩慢257
總結267
第11章自動化Kubernetes實驗268
11.1使用PowerfulSeal自動化
混沌268
11.1.1PowerfulSeal是什麼269
11.1.2安裝PowerfulSeal270
11.1.3實驗1b：終止50%的
Pod271
11.1.4實驗2b：引入網絡緩慢273
11.2持續測試和服務水準目標276
11.2.1實驗3：驗證Pod在創建後
幾秒內是否準備就緒277
11.3雲層282
11.3.1雲提供商API、可用區282
11.3.2實驗4：關閉VM284
總結286
第12章Kubernetes底層工作原理287
12.1Kubernetes集群剖析以及如何
破壞它287
12.1.1控制平面288
12.1.2Kubelet和pause容器295
12.1.3Kubernetes、Docker以及
容器運行時297
12.1.4Kubernetes網絡300
12.2關鍵組件總結304
總結304
第13章混沌工程與人305
13.1混沌工程思維305
13.1.1故障不是一種可能：它會
發生306
13.1.2早失敗與晚失敗307
13.2獲得支持308
13.2.1經理308
13.2.2團隊成員309
13.2.3遊戲日309
13.3將團隊當成分布式繫統310
13.3.1查找知識單點故障：
宅度假312
13.3.2團隊內部的錯誤信息和
信任313
13.3.3團隊中的瓶頸：慢車道上的
生活313
13.3.4測試你的流程：內部
工作314
總結315
附錄
附錄A安裝混沌工程工具318
附錄B突擊測驗答案325
附錄C導演剪輯333
附錄D混沌工程食譜337
後記343

人們經常問我是怎麼開始從事混沌工程的。我傾向於告訴他們：因為它有助於改善睡眠。混沌工程不但是“素食主義”友好的，而且在這方面非常有效。下面我來解釋一下。
回到2016年，機緣巧合之下，我幸運地參與了一個基於Kubernetes的前沿項目。現在沒有人會因為選擇Kubernetes而被解雇，但是在那時候風險卻很大。Kubernetes v1.2包含了許多不穩定的組件，並且漏洞修復的發布速度超過了安裝速度。
為了使其發揮作用，我的團隊需要擁有真正的Kubernetes運維經驗，並且需要在短期內完成。我們需要知道它是如何工作的、為什麼出問題、如何修復它，以及如何在發生這種情況時得到警告。我們認為，做到這一點的方法是先破壞它。
後來，我纔知道這種實踐稱為混沌工程，這樣聽起來更酷。事實證明，這種實踐在減少宕機次數方面非常有效。而且，與昂貴的竹炭記憶海綿枕相比，它對提高我的睡眠質量更有幫助。在這幾年裡，混沌工程是我的主要興趣之一。我並不孤單，它正迅速成為全球工程師的寶貴工具。
如今，混沌工程面臨著一些嚴重的問題。特別是充斥了一些奇談怪論（在生產中隨機破壞事物），而且缺乏指導人們如何把它做好的高質量內容以及需要采用的初違反直覺的思維（失敗會發生，所以我們需要做好準備）。
我編寫本書來解決這些問題。我想找到一種合理的、基於科學的方法論，從而使混沌工程適用於任何繫統、軟件或其他方面。我想證明你不必大費周章纔能從中受益，隻需少量投資即可為你帶來很多價值。
如果你是一名對新領域抱有好奇心的軟件工程師或者開發者，並且致力於構建更可靠的繫統（無論繫統規模是大還是小），那麼這本書正是為你而設計的。從Linux內核一直到應用程序或瀏覽器級別，本書都為你提供了正確的工具。
我為本書投入了很多心血，希望你能從中獲得價值，並且收獲快樂。如果你想了解更多信息，可以訪問https://chaosengineering.news。如果你喜歡（或討厭）這本書，我也希望你可以反饋給我！