注：以下內容剛剛譯完绣版，尚未定稿胶台，會與正式版有出入。僅供參考杂抽。本頁試讀內容的發(fā)布已經獲得圖靈公司相關編輯的許可诈唬。
目錄
第2版贊譽、致謝默怨、前言及第1章生產環(huán)境的生存法則
1.1 瞄準正確的目標
1.2 應對不斷擴大的挑戰(zhàn)范圍
1.3 多花5萬美元來節(jié)省100萬美元
1.4 讓“原力”與決策同在
1.5 設計務實的架構
1.6 總結
第一部分 創(chuàng)造穩(wěn)定性
案例研究：讓航空公司停飛的代碼異常
2.1 進行變更
2.2 遭遇停機
2.3 嚴重后果
2.4 驗尸報告
2.5 尋找線索
獲取線程轉儲
2.6 證據確鑿
2.7 預防管用嗎讯榕？讓系統(tǒng)穩(wěn)定運行
3.1 定義穩(wěn)定性
3.2 延長系統(tǒng)壽命
3.3 系統(tǒng)失效方式
3.4 阻止裂紋蔓延
3.5 系統(tǒng)失效鏈
3.6 總結穩(wěn)定性的反模式
4.1 集成點
有多少傳入數(shù)據骤素？
4.1.1 基于socket的協(xié)議
4.1.2 凌晨5點的催命電話
數(shù)據包捕獲
4.1.3 HTTP協(xié)議
4.1.4 供應商的API程序庫
4.1.5 應對集成點的問題
4.2 鏈式反應
每天3次重啟系統(tǒng)……
4.3 層疊失效
4.4 用戶
4.4.1 網絡流量
4.4.1.1 堆內存
4.4.1.2 堆外內存和主機外內存
4.4.1.3 服務器上socket數(shù)量
4.4.1.4 已關閉的sockets
4.4.2 難伺候的用戶
4.4.3 不受歡迎的用戶
會話跟蹤
4.4.4 惡意用戶
4.5 阻塞的線程
4.5.1 發(fā)現(xiàn)阻塞
謹慎使用緩存
4.5.2 程序庫
4.6 自黑式攻擊
4.6.1 避免自黑式攻擊
4.7 放大效應
4.7.1 點對點通信
4.7.2 共享資源
4.8 失衡的系統(tǒng)容量
4.8.1 通過測試來發(fā)現(xiàn)
4.9 疊羅漢
公用托管機房的變通方法
4.10 力量倍增器
4.10.1 被放大了的停機事故
4.10.2 控制和防護措施
4.11 緩慢的響應
4.12 無限長結果集
4.12.1 黑色星期一
4.13 總結
- 穩(wěn)定性的模式
5.1 超時
這一切雜亂真的是必需的嗎匙睹？
5.2 斷路器
5.3 艙壁
5.4 穩(wěn)態(tài)
5.4.1 數(shù)據清除
5.4.2 日志文件
為了達到合規(guī)性愚屁，難道不應該永遠保留所有的日志文件嗎？
5.4.3 內存中緩存
5.5 快速失敗
“我們收到了傳真痕檬，怎么全是黑的霎槐？”
5.6 任其崩潰
5.6.1 有限的粒度
5.6.2 快速更換
5.6.3 監(jiān)管
5.6.4 重新歸隊
5.7 握手
5.8 考驗機
什么不用mock對象？
5.9 將中間件解耦
5.10 卸下負載
5.11 背壓機制
5.12 節(jié)速器
5.13 總結
第二部分 為生產環(huán)境而設計
案例研究：屋漏偏逢連夜雨
6.1 寶寶的第一個圣誕節(jié)
6.2 把脈
6.3 感恩節(jié)
6.4 黑色星期五
6.5 生命體征
6.6 進行診斷
6.7 求助專家
6.8 如何應對
6.9 應對奏效嗎梦谜？
面向恢復的計算
6.10 尾聲基礎層
7.1 數(shù)據中心和云端的聯(lián)網
7.1.1 網卡和名字
7.1.2 多網絡編程
出站連接
7.2 物理主機丘跌、虛擬機和容器
7.2.1 物理主機
7.2.2 數(shù)據中心的虛擬機
7.2.3 數(shù)據中心的容器
虛擬機的虛擬局域網
12要素應用程序
7.2.4 云上的虛擬機
7.2.5 云上的容器
7.3 總結機器上的進程
8.1 代碼
8.1.1 構建代碼
8.1.2 不可變和一次性基礎設施
8.2 配置
8.2.1 配置文件
8.2.2 一次性基礎設施中的配置
配置里的屬性的命名
8.3 明晰性
8.3.1 為明晰性而設計
8.3.2 提升明晰性的實現(xiàn)技術
8.3.3 記錄日志
8.3.3.1 日志的存放位置
8.3.3.2 日志級別
在生產環(huán)境中打開調試級別日志
8.3.3.3 日志讀者
8.3.3.4 巫毒運維
8.3.3.5 最后說明
8.3.4 實例的健康度量指標
8.3.5 健康狀況檢查
8.4 總結互連層
9.1 不同規(guī)模的解決方案
9.2 使用DNS
9.2.1 使用DNS進行服務發(fā)現(xiàn)
9.2.2 使用DNS進行負載均衡
9.2.3 使用DNS進行全球服務器負載均衡
9.2.4 DNS的可用性
9.3 負載均衡
9.3.1 軟件負載均衡
9.3.2 硬件負載均衡
9.3.3 健康狀況檢查
9.3.4 會話粘性
9.3.5 按請求類型分隔流量
9.4 控制需求數(shù)量
9.4.1 系統(tǒng)如何失效
9.4.2 防止災難
TIME_WAIT和亂包
9.5 網絡路由
“一模一樣”的機器
9.6 發(fā)現(xiàn)服務
9.7 遷移虛擬IP地址
9.8 總結控制層
10.1 哪些控制層工具適合你？
10.2 機械效益
10.2.1 屬于系統(tǒng)失效唁桩，而非人為錯誤
10.2.2 運行得太快也有問題
10.3 平臺和生態(tài)系統(tǒng)
10.4 開發(fā)環(huán)境就是生產環(huán)境
10.5 整個系統(tǒng)的明晰性
10.5.1 真實用戶監(jiān)控
10.5.2 經濟價值高于技術價值
10.5.3 碎片化的風險
10.5.4 日志和統(tǒng)計信息
10.5.5 要監(jiān)控什么
10.6 配置服務
10.7 環(huán)境整備和部署服務
將構建服務器用作攻擊媒介
10.8 命令與控制
10.8.1 要控制什么
10.8.2 發(fā)送命令
10.8.3 可編寫腳本的界面
10.9 平臺廠商
10.10 工具清單
10.11 總結Security 安全性
11.1 OWASP十大安全漏洞
11.1.1 注入
11.1.2 失效的身份驗證和會話管理
11.1.3 跨站腳本
11.1.4 失效的訪問控制
11.1.4.1 讓URL探測令人望而卻步
11.1.4.2 授予對象訪問權限
11.1.5 安全配置出現(xiàn)失誤
11.1.6 敏感數(shù)據泄漏
11.1.7 攻擊防范不足
11.1.8 偽造跨站請求
11.1.9 使用含有已知漏洞的組件
11.1.10 API保護不足
11.2 最小特權原則
11.2.1 容器和最小特權
11.3 密碼的配置
11.4 安全即持續(xù)的過程
11.5 總結
第三部分 將系統(tǒng)交付
案例研究：等待戈多
為部署而設計
13.1 機器與服務
13.2 計劃停機時間的謬誤
13.3 自動化部署
13.4 持續(xù)部署
13.5 部署中的各階段
13.5.1 關系數(shù)據庫schema
13.5.2 無schema數(shù)據庫
13.5.3 Web資源
13.5.4 推出新代碼
13.5.5 清理
13.6 像行家一樣部署
13.7 總結處理版本問題
14.1 幫助他人處理版本問題
14.1.1 不會破壞API的變更
14.1.2 破壞API的變更
14.2 處理其他系統(tǒng)的版本問題
14.3 總結
第四部分 解決系統(tǒng)性的問題
案例分析：被自己的顧客所踐踏
15.1 倒計時與新推出系統(tǒng)
15.2 以QA測試為目標
康威定律
15.3 負載測試
15.4 被眾多因素所害
15.5 測試還是有差距
15.6 善后適應性
16.1 努力與回報的關系
16.2 過程和組織
顛簸的危險
16.2.1 平臺團隊
“DevOps團隊”的謬誤
16.2.2 無痛的發(fā)布
16.2.3 進化最重要的部分是滅絕
16.2.4 在團隊級別實現(xiàn)自治
無須協(xié)調的部署
16.2.5 謹防高效率
16.2.6 小結
16.3 系統(tǒng)架構
16.3.1 進化式架構
分層之禍
關于微服務的提示
16.3.2 松散地集群
16.3.3 顯式上下文
16.3.4 創(chuàng)造更多選項
16.3.4.1 拆分
16.3.4.2 替代
16.3.4.3 增添和排除
16.3.4.4 反轉
16.3.4.5 移植
16.3.5 小結
16.4 信息架構
16.4.1 消息闭树、事件和命令
16.4.2 讓服務自己控制其資源的ID
16.4.3 URL的兩重性
16.4.4 擁抱多義性
16.4.5 避免概念泄漏
16.4.6 小結
16.5 總結混沌工程
17.1 不可能構建第二個Facebook去做測試
17.2 混沌工程的先驅
17.3 猴子軍團
17.3.1 選擇性加入還是選擇性退出？
17.4 使用自己的混沌猴
17.4.1 先決條件
17.4.2 設計試驗
17.4.3 3種混沌注入
把混沌介紹給身邊的人
17.4.4 有針對性地注入混沌
狡詐的惡意智囊
17.4.5 自動和重復
17.5 從人的方面模擬災難
17.6 總結
