作者根據自己的親身經歷和某些大型企業的案例，講述了如何創建高穩定性的軟體系統，分析了設計和實現中導致系統出現問題的原因。全書分為四個部分，每部分內容都由一個研究案例引出。第一部分介紹了如何保證系統的生存，即維護系統正常運行。第二部分介紹了為生產環境而設計，從基礎層、實例層、互連層和控制層等方面構建系統安全性。第三部分講述了交付系統，列出系統在部署過程中有可能出現的問題。第四部分引入適用性和混沌工程的概念，討論了如何解決系統性問題。

邁克爾·尼加德

程序員兼架構師，擁有20餘年的從業經驗，先後為美國政府以及銀行、金融、農業、零售等多個行業交付過運營系統，對如何在不利的環境下構建高性能、高可靠性的軟體有獨到的見解。
 

第1章 生產環境的生存法則 1
1.1 瞄準正確的目標 1
1.2 應對不斷擴大的挑戰範圍 2
1.3 多花5萬美元來節省100萬美元 3
1.4 讓“原力”與決策同在 4
1.5 設計務實的架構 4
1.6 小結 5

第一部分 創造穩定性 7

第2章 案例研究：讓航空公司停飛的代碼異常 8
2.1 進行變更 9
2.2 遭遇停機 10
2.3 嚴重後果 12
2.4 事後分析 12
2.5 尋找線索 13
2.6 證據確鑿 16
2.7 預防管用嗎 18

第3章 讓系統穩定運行 19
3.1 定義穩定性 20
3.2 延長系統壽命 20
3.3 系統失效方式 21
3.4 阻止裂紋蔓延 22
3.5 系統失效鏈 23
3.6 小結 24

第4章 穩定性的反模式 25
4.1 集成點 26
4.1.1 通訊端協議 29
4.1.2 淩晨5點的緊急電話 31
4.1.3 HTTP協議 35
4.1.4 供應商的API程式庫 36
4.1.5 應對集成點的問題 37
4.1.6 要點回顧 37
4.2 同層連累反應 38
4.3 層疊失效 41
4.4 用戶 42
4.4.1 網路流量 42
4.4.2 難伺候的用戶 46
4.4.3 不受歡迎的用戶 47
4.4.4 惡意用戶 50
4.4.5 要點回顧 51
4.5 執行緒阻塞 51
4.5.1 發現阻塞 53
4.5.2 程式庫 55
4.5.3 要點回顧 56
4.6 自黑式攻擊 57
4.6.1 避免自黑式攻擊 57
4.6.2 要點回顧 58
4.7 放大效應 58
4.7.1 點對點通信 59
4.7.2 共用資源 60
4.7.3 要點回顧 61
4.8 失衡的系統容量 62
4.8.1 通過測試發現系統容量失衡 63
4.8.2 要點回顧 63
4.9 一窩蜂 64
4.10 做出誤判的機器 66
4.10.1 被放大的停機事故 66
4.10.2 控制和防護措施 69
4.10.3 要點回顧 69
4.11 緩慢的回應 70
4.12 無限長的結果集 71
4.12.1 黑色星期一 71
4.12.2 要點回顧 73
4.13 小結 74

第5章 穩定性的模式 75
5.1 超時 75
5.2 斷路器 78
5.3 艙壁 80
5.4 穩態 83
5.4.1 資料清除 84
5.4.2 日誌檔 85
5.4.3 記憶體中的緩存 86
5.4.4 要點回顧 86
5.5 快速失敗 87
5.6 任其崩潰並替換 89
5.6.1 有限的細微性 89
5.6.2 快速替換 90
5.6.3 監管 90
5.6.4 重新歸隊 91
5.6.5 要點回顧 91
5.7 握手 91
5.8 考驗機 93
5.9 中介軟體解耦 96
5.10 卸下負載 98
5.11 背壓機制 99
5.12 調速器 101
5.13 小結 102

第二部分 為生產環境而設計 103

第6章 案例研究：屋漏偏逢連夜雨 104

6.1 寶寶的第 一個感恩節 105
6.2 把脈 106
6.3 感恩節 106
6.4 黑色星期五 107
6.5 生命體征 108
6.6 進行診斷 109
6.7 求助專家 110
6.8 如何應對 111
6.9 應對奏效嗎 111
6.10 尾聲 112

第7章 基礎層 114
7.1 資料中心和雲端的聯網 115
7.1.1 網卡和名字 116
7.1.2 多網路程式設計 118
7.2 物理主機、虛擬機器和容器 119
7.2.1 物理主機 119
7.2.2 資料中心的虛擬機器 119
7.2.3 資料中心的容器 120
7.2.4 雲上的虛擬機器 123
7.2.5 雲上的容器 125
7.3 小結 125

第8章 實例層 126
8.1 代碼 128
8.1.1 構建代碼 128
8.1.2 不可變、易處理的基礎設施 129
8.2 配置 130
8.2.1 設定檔 131
8.2.2 易處理基礎設施的配置 131
8.3 明晰性 132
8.3.1 明晰性設計 133
8.3.2 提升明晰性的實現技術 134
8.3.3 記錄日誌 134
8.3.4 實例的健康度量指標 137
8.3.5 健康狀況檢查 138
8.4 小結 138

第9章 互連層 139
9.1 不同規模的解決方案 139
9.2 使用DNS 140
9.2.1 基於DNS的服務發現 140
9.2.2 基於DNS的負載均衡 141
9.2.3 基於DNS的GSLB 142
9.2.4 DNS的可用性 144
9.2.5 要點回顧 144
9.3 負載均衡 144
9.3.1 軟體負載均衡 145
9.3.2 硬體負載均衡 146
9.3.3 健康狀況檢查 147
9.3.4 會話黏性 147
9.3.5 按請求類型分隔流量 148
9.3.6 要點回顧 148
9.4 控制請求數量 148
9.4.1 系統為何會失效 149
9.4.2 防止災難 150
9.4.3 要點回顧 151
9.5 網路路由 151
9.6 發現服務 153
9.7 遷移虛擬IP位址 154
9.8 小結 155

第10章 控制層 156
10.1 適合的控制層工具 156
10.2 機械效益 157
10.2.1 屬於系統失效，而非人為錯誤 158
10.2.2 運行得太快也有問題 158
10.3 平臺和生態系統 159
10.4 開發環境就是生產環境 160
10.5 整個系統的明晰性 161
10.5.1 真實用戶監控 162
10.5.2 經濟價值高於技術價值 162
10.5.3 碎片化的風險 164
10.5.4 日誌和統計資訊 164
10.5.5 要監控什麼 165
10.6 配置服務 166
10.7 環境整備和部署服務 167
10.8 命令與控制 169
10.8.1 要控制什麼 169
10.8.2 發送命令 170
10.8.3 可編寫腳本的介面 170
10.8.4 要點回顧 171
10.9 平臺廠商 171
10.10 工具清單 172
10.11 小結 172

第11章 安全性 173
11.1 OWASP十大安全性漏洞 173
11.1.1 注入 174
11.1.2 失效的身份驗證和會話管理 175
11.1.3 跨站腳本攻擊 178
11.1.4 失效的存取控制 179
11.1.5 安全配置出現失誤 181
11.1.6 敏感性資料洩露 182
11.1.7 防範攻擊不足 183
11.1.8 CSRF 183
11.1.9 使用含有已知漏洞的元件 184
11.1.10 API保護不足 185
11.2 最小特權原則 186
11.3 密碼的配置 187
11.4 安全即持續的過程 187
11.5 小結 188

第三部分 將系統交付 189

第12章 案例研究：等待戈多 190

第13章 為部署而設計 193
13.1 機器與服務 193
13.2 計畫停機時間的謬誤 193
13.3 自動化部署 194
13.4 持續部署 197
13.5 部署中的各個階段 198
13.5.1 關聯式資料庫模式 200
13.5.2 無模式資料庫 202
13.5.3 Web資源 205
13.5.4 推出新代碼 206
13.5.5 清理 208
13.6 像行家一樣部署 209
13.7 小結 210

第14章 處理版本問題 211
14.1 幫助他人處理版本問題 211
14.1.1 不會破壞API的變更 211
14.1.2 破壞API的變更 215
14.2 處理其他系統的版本問題 217
14.3 小結 219

第四部分 解決系統性問題 221

第15章 案例研究：不能承受的巨大顧客流量 222
15.1 倒計時後推出新系統 222
15.2 以QA測試為目標 223
15.3 負載測試 225
15.4 被眾多因素所害 227
15.5 測試仍然有差距 229
15.6 善後 229

第16章 適應性 232
16.1 努力與回報的關係 232
16.2 過程和組織 233
16.2.1 平臺團隊 235
16.2.2 愉快地發佈 236
16.2.3 演化最重要的部分是滅絕 237
16.2.4 在團隊級別實現自治 239
16.2.5 謹防高效率 240
16.2.6 過程和組織小結 242
16.3 系統架構 242
16.3.1 演進式架構 242
16.3.2 鬆散的集群 245
16.3.3 顯式上下文 246
16.3.4 創造更多選項 247
16.3.5 系統架構小結 252
16.4 信息架構 252
16.4.1 消息、事件和命令 253
16.4.2 讓服務自己控制其資源的識別字 254
16.4.3 URL的兩重性 256
16.4.4 擁抱多義性 259
16.4.5 避免概念洩露 260
16.4.6 信息架構小結 261
16.5 小結 261

第17章 混沌工程 262
17.1 不可能構建第二個Facebook去做測試 262
17.2 混沌工程的先驅 263
17.3 猴子軍團 264
17.4 使用自己的混沌猴 265
17.4.1 先決條件 266
17.4.2 設計實驗 266
17.4.3 3種混沌注入 267
17.4.4 有針對性地注入混沌 268
17.4.5 自動和重複 269
17.5 從人的方面模擬災難 270
17.6 小結 271