随着越来越多的公司转向构建微服务及其他形式的分布式系统，系统的复杂性与日俱增。虽然无法消除复杂性，但通过实践混沌工程，可以发现系统中的漏洞，并在其影响客户之前，避免停机事故。本书会展现混沌工程背后的历史，讨论奠定混沌工程基础的理论、定义和原则，研究整个软件行业实现混沌工程的方式，分析传统软件无法企及的实例，以及混沌工程实践的未来。

无

谨以此书献给“老伙计”David Hussman译注1。正是他最初带来了星星之火，才让混沌工程社区渐成燎原之势。
混沌工程已然腾飞。在各个垂直领域，成千上万的各种类型和规模的公司都将混沌工程作为核心实践，以使公司的产品和服务更安全、更可靠。虽然相关主题的资源（尤其是会议演讲）十分丰富，但都无法描绘混沌工程的全貌。
Nora和Casey着手编写了这本完整讨论混沌工程的书。因为整个行业都在广泛实践混沌工程，而且该学科也在不断地发展，所以编写本书并不轻松。本书会展现混沌工程背后的历史，讨论奠定混沌工程基础的理论、定义和原则，研究整个软件行业实现混沌工程的方式，分析传统软件无法企及的示例，以及混沌工程实践的未来。
排版约定
本书中使用以下排版约定：
斜体（Italic）
表示URL、电子邮件地址、文件名和文件扩展名。
等宽字体（Constant width）
用于程序清单，以及段落中的程序元素，例如变量名、函数名、数据库、数据类型、环境变量、语句以及关键字。
O'Reilly 在线学习平台（O'Reilly Online Learning）
40多年来，O'Reilly Media致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。
我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O扲eilly的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O扲eilly和200多家其他出版商提供的大量文本和视频资源。有关的更多信息，请访问http://oreilly.com。
如何联系我们
对于本书，如果有任何意见或疑问，请按照以下地址联系本书出版商。
美国：
O'Reilly Media，Inc.
1005 Gravenstein Highway North
Sebastopol，CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
要询问技术问题或对本书提出建议，请发送电子邮件至bookquestions@oreilly.com。
本书配套网站https://oreil.ly/Chaos_Engineering上列出了勘误表、示例以及其他信息。
关于书籍、课程、会议和新闻的更多信息，请访问我们的网站http://www.oreilly.com。
我们在Facebook上的地址：http://facebook.com/oreilly
我们在Twitter上的地址：http://twitter.com/oreillymedia
我们在YouTube上的地址：http://www.youtube.com/oreillymedia
致谢
本书就像任何大部头一样，有无数的人在幕后奉献了宝贵的时间、精力和情感。我们在此感谢所有提供帮助的人。正是由于你们的付出，我们才得以完善本书的内容构思，让本书顺利付梓。
很荣幸能与O扲eilly的优秀编辑和工作人员一起工作。Amelia Blevins、Virginia Wilson、John Devins和Nikki McDonald都为本书做出了很大贡献。从许多方面来说，Amelia和Virginia对本书所付出的努力一点也不比作者少。
感谢以下审校者的倾情奉献：Will Gallego、Ryan Frantz、Eric Dobbs、Lane Desborough、Randal Hansen、Michael Kehoe、Mathias Lafeldt、Barry O扲eilly、Cindy Sridharan和Benjamin Wilms的评论、建议和更正极大地提高了本书的质量，加深了我们对这一复杂领域的理解，促使我们在工作中进行更多的研究。本书是大家协作的结晶，并通过审校工作得到了升华。
我们在此衷心感谢本书各篇章的作者—John Allspaw、Peter Alvaro、Nathan Aschbacher、Jason Cahoon、Raji Chockaiyan、Richard Crowley、Bob Edwards、Andy Fleener、Russ Miles、Aaron Rinehart、Logan Rosen、Oleg Surmachev、Lu Tang和Hao Weng。显然，你们每个人对本书的贡献都是必不可少的。没有你们，就没有本书。
感谢David Hussman、Kent Beck和John Allspaw。谨以此书献给David。他鼓励我们跳出硅谷，在更广的范围传播混沌工程。在很大程度上，正是由于他的支持和鼓励，混沌工程才能实际落地，立足于软件工程界的学科之林。同样，Kent Beck鼓励我们扩大混沌工程的影响，以转变人们构建、部署和运维软件的方式。John Allspaw鼓励我们在瑞典隆德大学学习人因学和系统安全，为我们提供了解释混沌工程基础的语言。他向我们介绍了韧性工程译注2领域。该领域已被证明是混沌工程的基础，并且可帮助我们在观察社会技术系统（例如大规模部署的软件）时，发现安全问题（包括可用性和安全性）。在隆德大学学习期间，所接触的讲师和同人也深刻地影响了我们的思想，尤其是Johan Bergstrom和Anthony “Smokes” Smoker。
我们衷心感谢上述所有人。在你们的影响下，我们更有勇气来推动混沌工程前进。你们所做的贡献，我们会永远铭记。

计算机\分布式

随着越来越多的公司转向构建微服务及其他形式的分布式系统，这些系统的复杂性也与日俱增。虽然无法消除复杂性，但通过实践混沌工程，可以发现系统中的漏洞，并防患于未然。本书向工程师展示了如何在优化系统满足业务目标的同时应对复杂的系统。
两位作者是该领域的杰出人物，他们在Netflix公司合作期间开创了“混沌工程”这一学科。在本书中，他们不仅阐述了混沌工程的目标、方法和价值，还促进了各行业的从业者针对该主题展开交流。本书内容丰富，立足于发展史，面向未来，是打开混沌工程之门的黄金之钥。
通过阅读本书，你将：
? 了解混沌工程如何使组织能够应对复杂性。
? 探索一种方法论来避免应用程序、网络和基础设施出现故障。
? 通过谷歌、微软、Slack和LinkedIn等行业专家的真实故事，学习如何将理论应用于实践。
? 建立思考软件系统内部复杂性的框架。
? 围绕Game Day设计一个混沌工程实施计划，并朝着目标明确的自动化实验方向发展。
? 了解如何设计能够实现持续协作的混沌实验。

“ 复杂的系统会逐渐变得脆弱，这个过程既意想不到，又无法检测。本书作者深入解释了混沌工程的核心实践，提供了真实故事和实践建议，以帮助团队利用混沌工程的思想使系统更具韧性。”
——Michael Lopp
Slack公司前工程副总裁

Casey Rosenthal是Verica公司的首席执行官兼联合创始人。他曾是Netflix公司混沌工程团队的工程经理，在使用分布式系统、人工智能以及将新颖的算法和学术界知识转化为能落地的模型方面拥有丰富的经验。
Nora Jones是Jeli公司的首席执行官兼联合创始人。她是一位敬业且充满自驱力的技术领导者和软件工程师，对分布式系统中人与软件的协同工作充满热情。她在2017年AWS re:Invent大会的主题演讲中为混沌工程运动的发起做出了贡献。

在敏捷软件开发领域，质量内建是一项广受欢迎的实践活动。这种将质量意识贯彻到软件开发各个环节，从而节省返工成本的做法，其本质就是“预防为主”。但片面强调“预防为主”会给人一个错觉，那就是软件系统的任何故障都可以通过“预防”来解决。基于这个错觉，一旦出现了线上事故，那么人们首先就会责备开发、测试和运维人员，因为他们“不能也不该出现失误”。像“绝不能将任何风险引入生产环境”这样的口号，只是人们美好的愿望。“暗债本固有”的客观事实，大家都心知肚明。
在云原生和微服务这些复杂系统盛行的年代，必须承认，一个人的大脑无法承载分布式系统的全部细节。每个人对系统的理解都存在差异，加上沟通时发生的信息损耗，当他们合作开发软件时，就必然会产生不可预知的“暗债”。
然而，这些只是我们所开发的系统的内部暗债。更可怕的是外部暗债，它们潜伏在我们的系统所依赖的外部系统和网络环境中。由于在我们的控制之外，这些外部暗债更难以预测，所以它们“不按常理出牌”就再自然不过了。
我们虽然能凭借“软件测试”和“故障演练”来提升软件质量，但这种经常采用固定测试用例和相同演练流程的手段，却让软件系统在生产环境中无法应对来自外部暗债“不按常理出牌”的种种“恶毒”考验，比如本应通畅的网络出现了延迟，本应能正常写入的磁盘被写满了，本应理智的用户不知为何开始疯狂地反复单击“提交”按钮……
我们就生活在这种充满了非线性和不确定性的世界中。
“预防为主”固然很好，但因为“人无完人”，所以“暗债”必然会产生。而其不可预知的特点导致无法做到“预防暗债”。
让我们重温一下“面向恢复的计算”所信奉的观点：
无论在硬件方面还是软件方面，系统失效都是不可避免的。
建模和分析永远都不会足够完备，用推导的方法预测所有系统失效方式是不可能的。
人的行为是系统失效的主要原因。
这种论断可能太悲观了。面对复杂系统中无法预知和预防的“暗债”，我们还能做什么？
我们可以做下面三件事：
承认“暗债本固有”。
发现故障时修复要快。
随时树立起警示牌。
下次云平台发生故障，我期望能看到这样的故障说明：“我们要为该故障树立起警示牌，并提升故障的发现和修复速度，最终达到在用户尚未察觉的情况下快速发现并修复故障。”
在承认“暗债本固有”的前提下，设计安全的方法来做“不按常理出牌”的实验，以考验软件系统的稳定性，以促进快速发现和修复故障，从而有效地对“预防为主”的质量内建进行补充。
这种工程实践就是混沌工程。

吾真本

前言 1
导言：混沌工程的诞生 5
第一部分 搭建舞台 13
第1章 遇到复杂系统 15
1.1 思考复杂性 15
1.2 遇到复杂性 17
1.3 面对复杂性 26
1.4 接纳复杂性 29
第2章 应对复杂系统 30
2.1 动态安全模型 30
2.2 复杂性的经济支柱模型 33
2.3 系统化视角 36
第3章 原则概述 37
3.1 混沌工程是什么 37
3.2 混沌工程不是什么 39
3.3 高级原则 41
3.4 原则的未来 45
第二部分 投入实战 47
第4章 Slack的灾难剧场 49
4.1 旧系统的混沌工程改造 49
4.2 灾难剧场 52
4.3 混沌工程的过程 53
4.4 过程如何演化 59
4.5 获得管理层支持 60
4.6 结果 60
4.7 总结 62
第5章 谷歌DiRT：灾难恢复测试 63
5.1 DiRT测试的生命周期 65
5.2 谷歌的测试范围 77
5.3 总结 79
第6章 微软的多样化故障和实验优先级 81
6.1 为什么一切都如此复杂 81
6.2 实验结果的类别 83
6.3 故障优先级 86
6.4 多样化的程度 87
6.5 大规模部署实验 90
6.6 总结 91
第7章 LinkedIn心中有会员 92
7.1从灾难中学习 93
7.2 细化实验目标 93
7.3 安全地进行大规模实验 95
7.4 LinkedOut实战 96
7.5 总结 105
第8章 采纳并演进混沌工程的第一资本金融公司 106
8.1 第一资本金融公司案例研究 107
8.2 设计实验时需要注意的事项 109
8.3 工具链 110
8.4 团队结构 111
8.5 传播 112
8.6 总结 113
第三部分 人为因素 115
第9章 先见之明 117
9.1 混沌工程与韧性 118
9.2 混沌工程的步骤 118
9.3 混沌工程实验的工具支持 120
9.4 有效的内部合作 122
9.5 总结 127
第10章 人类系统的混沌 128
10.1 系统中的人 128
10.2 工程师团队的适应能力 130
10.3 付诸实践 132
第11章 决策圈中的人 144
11.1 实验的原因、方法和时机 145
11.2 总结 151
第12章 实验选择问题及解决方案 152
12.1 选择实验 152
12.2 可观测性：机会来了 158
12.3 总结 160
第四部分 商业因素 163
第13章 混沌工程的投资回报率 165
13.1 减少事故所带来的好处转瞬即逝 165
13.2 Kirkpatrick模型 166
13.3 投资回报率替代方案示例 168
13.4 附带投资回报率 169
13.5 总结 170
第14章 将心态、科学和混沌开放 171
14.1 协作心态 171
14.2 开放科学与开放源代码 173
14.3 总结 176
第15章 混沌成熟度模型 177
15.1 采用度 177
15.2 复杂性 182
15.3 总结 186
第五部分 持续演进 189
第16章 持续验证 191
16.1 持续验证从何而来 191
16.2 持续验证系统的类型 193
16.3 持续验证示例：ChAP 194
16.4 持续验证的未来用例 197
第17章 介入信息物理系统 199
17.1 信息物理系统的兴起 200
17.2 功能安全遇上混沌工程 200
17.3 信息物理系统的软件 203
17.4 混沌工程超越FMEA 204
17.5 探针效应 206
17.6 总结 208
第18章 当HOP遇上混沌工程 210
18.1 什么是HOP 210
18.2 HOP的主要原则 210
18.3 HOP遇上混沌工程 212
18.4 总结 215
第19章 数据库的混沌工程 216
19.1 为什么我们需要混沌工程 216
19.2 应用混沌工程 218
19.3 检测故障 222
19.4 自动化混沌工程 223
19.5 总结 226
第20章 安全混沌工程的案例 227
20.1 现代安全手段 228
20.2 安全混沌工程与现有方法 231
20.3 安全Game Day 233
20.4 安全混沌工程工具示例：ChaoSlingr 234
20.5 总结 236
第21章 结语 238
作者简介 241
译者简介 241
封面简介 242