注：以下内容刚刚译完，尚未定稿，会与正式版有出入。仅供参考。本页试读内容的发布已经获得图灵公司相关编辑的许可。
目录
第2版赞誉、致谢、前言及第1章生产环境的生存法则
1.1 瞄准正确的目标
1.2 应对不断扩大的挑战范围
1.3 多花5万美元来节省100万美元
1.4 让“原力”与决策同在
1.5 设计务实的架构
1.6 总结
第一部分 创造稳定性
案例研究：让航空公司停飞的代码异常
2.1 进行变更
2.2 遭遇停机
2.3 严重后果
2.4 验尸报告
2.5 寻找线索
获取线程转储
2.6 证据确凿
2.7 预防管用吗？让系统稳定运行
3.1 定义稳定性
3.2 延长系统寿命
3.3 系统失效方式
3.4 阻止裂纹蔓延
3.5 系统失效链
3.6 总结稳定性的反模式
4.1 集成点
有多少传入数据？
4.1.1 基于socket的协议
4.1.2 凌晨5点的催命电话
数据包捕获
4.1.3 HTTP协议
4.1.4 供应商的API程序库
4.1.5 应对集成点的问题
4.2 链式反应
每天3次重启系统……
4.3 层叠失效
4.4 用户
4.4.1 网络流量
4.4.1.1 堆内存
4.4.1.2 堆外内存和主机外内存
4.4.1.3 服务器上socket数量
4.4.1.4 已关闭的sockets
4.4.2 难伺候的用户
4.4.3 不受欢迎的用户
会话跟踪
4.4.4 恶意用户
4.5 阻塞的线程
4.5.1 发现阻塞
谨慎使用缓存
4.5.2 程序库
4.6 自黑式攻击
4.6.1 避免自黑式攻击
4.7 放大效应
4.7.1 点对点通信
4.7.2 共享资源
4.8 失衡的系统容量
4.8.1 通过测试来发现
4.9 叠罗汉
公用托管机房的变通方法
4.10 力量倍增器
4.10.1 被放大了的停机事故
4.10.2 控制和防护措施
4.11 缓慢的响应
4.12 无限长结果集
4.12.1 黑色星期一
4.13 总结
- 稳定性的模式
5.1 超时
这一切杂乱真的是必需的吗？
5.2 断路器
5.3 舱壁
5.4 稳态
5.4.1 数据清除
5.4.2 日志文件
为了达到合规性，难道不应该永远保留所有的日志文件吗？
5.4.3 内存中缓存
5.5 快速失败
“我们收到了传真，怎么全是黑的？”
5.6 任其崩溃
5.6.1 有限的粒度
5.6.2 快速更换
5.6.3 监管
5.6.4 重新归队
5.7 握手
5.8 考验机
什么不用mock对象？
5.9 将中间件解耦
5.10 卸下负载
5.11 背压机制
5.12 节速器
5.13 总结
第二部分 为生产环境而设计
案例研究：屋漏偏逢连夜雨
6.1 宝宝的第一个圣诞节
6.2 把脉
6.3 感恩节
6.4 黑色星期五
6.5 生命体征
6.6 进行诊断
6.7 求助专家
6.8 如何应对
6.9 应对奏效吗？
面向恢复的计算
6.10 尾声基础层
7.1 数据中心和云端的联网
7.1.1 网卡和名字
7.1.2 多网络编程
出站连接
7.2 物理主机、虚拟机和容器
7.2.1 物理主机
7.2.2 数据中心的虚拟机
7.2.3 数据中心的容器
虚拟机的虚拟局域网
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 提升明晰性的实现技术
8.3.3 记录日志
8.3.3.1 日志的存放位置
8.3.3.2 日志级别
在生产环境中打开调试级别日志
8.3.3.3 日志读者
8.3.3.4 巫毒运维
8.3.3.5 最后说明
8.3.4 实例的健康度量指标
8.3.5 健康状况检查
8.4 总结互连层
9.1 不同规模的解决方案
9.2 使用DNS
9.2.1 使用DNS进行服务发现
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 控制需求数量
9.4.1 系统如何失效
9.4.2 防止灾难
TIME_WAIT和乱包
9.5 网络路由
“一模一样”的机器
9.6 发现服务
9.7 迁移虚拟IP地址
9.8 总结控制层
10.1 哪些控制层工具适合你？
10.2 机械效益
10.2.1 属于系统失效，而非人为错误
10.2.2 运行得太快也有问题
10.3 平台和生态系统
10.4 开发环境就是生产环境
10.5 整个系统的明晰性
10.5.1 真实用户监控
10.5.2 经济价值高于技术价值
10.5.3 碎片化的风险
10.5.4 日志和统计信息
10.5.5 要监控什么
10.6 配置服务
10.7 环境整备和部署服务
将构建服务器用作攻击媒介
10.8 命令与控制
10.8.1 要控制什么
10.8.2 发送命令
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 安全配置出现失误
11.1.6 敏感数据泄漏
11.1.7 攻击防范不足
11.1.8 伪造跨站请求
11.1.9 使用含有已知漏洞的组件
11.1.10 API保护不足
11.2 最小特权原则
11.2.1 容器和最小特权
11.3 密码的配置
11.4 安全即持续的过程
11.5 总结
第三部分 将系统交付
案例研究：等待戈多
为部署而设计
13.1 机器与服务
13.2 计划停机时间的谬误
13.3 自动化部署
13.4 持续部署
13.5 部署中的各阶段
13.5.1 关系数据库schema
13.5.2 无schema数据库
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 处理其他系统的版本问题
14.3 总结
第四部分 解决系统性的问题
案例分析：被自己的顾客所践踏
15.1 倒计时与新推出系统
15.2 以QA测试为目标
康威定律
15.3 负载测试
15.4 被众多因素所害
15.5 测试还是有差距
15.6 善后适应性
16.1 努力与回报的关系
16.2 过程和组织
颠簸的危险
16.2.1 平台团队
“DevOps团队”的谬误
16.2.2 无痛的发布
16.2.3 进化最重要的部分是灭绝
16.2.4 在团队级别实现自治
无须协调的部署
16.2.5 谨防高效率
16.2.6 小结
16.3 系统架构
16.3.1 进化式架构
分层之祸
关于微服务的提示
16.3.2 松散地集群
16.3.3 显式上下文
16.3.4 创造更多选项
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 总结
