混沌工程

第二部分. 行动中的原则

我们 认为，在本书中展示来自不同组织的不同声音非常重要。没有放之四海而皆准的混沌工程计划。本书中的一些观点和指导并不完全一致，这没有关系。我们并不回避不同意见和反对观点。你会发现一些共同的主题，比如在混沌程序中加入一个 "红色大按钮"，也会发现一些相互冲突的观点，比如混沌工程到底是一种测试还是实验。¹

我们特别选择了来自 Slack、谷歌、微软、LinkedIn 和 Capital One 的观点。我们提出了最有说服力的例子和叙述，读者可以根据自己的情况选择最相关的例子和叙述。在复杂系统中，情境为王。

我们 从第 4 章"Slack 的灾难作品剧场 "开始，Richard Crowley 描述了 Slack 混沌工程的特殊方法。Slack 结合了传统系统和现代系统，为探索不同的混沌工程方法提供了目标丰富的环境。理查德选择了一种独特的方法来开展 "游戏日 "活动，他说："通过 20 多次演练，我们发现了漏洞，证明了新旧系统的安全性，并影响了许多工程团队的路线图。

在第 5 章"谷歌 DiRT：灾难恢复测试 "中，杰森-卡洪（Jason Cahoon）带领 我们走进了谷歌类似于 "混沌工程 "的 "DiRT"。这是对混沌工程最有经验的探索之一，因为谷歌运营 DiRT 项目已经有一段时间了。本章探讨了谷歌方法背后的理念："仅仅希望系统在极端情况下表现可靠并不是好策略。你必须预料到事情会失败，在设计时考虑到失败，并不断证明这些设计仍然有效"。它还描述了这个长期项目的重点和价值，强化了我们在复杂系统分析中看到的主题："DiRT不是为了破坏而破坏，它的价值来自于发现你不知道的失效模式"。

"不幸的是，一切都没有按计划进行"，这句话可以用 来概括我们在大规模操作系统中所经历的许多意外。在第 6 章"微软实验的差异和优先级 "中，Oleg Surmachev 就如何确定实验的优先级提供了非常有条理的观点。事件的潜在影响是本章所介绍的众多考虑因素的核心。在寻找 "未知事件/意料之外的后果 "之前，积极探索可能存在的薄弱环节，可以建立一个更强大的系统，并节省不必要的实验。

在第7章"LinkedIn关注会员 "中，罗根-罗森（Logan Rosen ）强调了客户体验的重要性。幸运的是，有很多策略可以最大限度地减少混乱实验中的爆炸半径和对客户的潜在影响。Logan 带我们参观了 LinkedIn 实施此类策略的项目。"虽然一些小的影响可能是不可避免的，但非常重要的一点是，要尽量减少混乱实验对最终用户造成的伤害，并制定一个简单的恢复计划，让一切恢复正常"。

Raji Chockaiyan撰写的第8章"Capital One在金融服务中采用混沌工程的情况和演变 "为本书的 部分画上了圆满的句号。Capital One公司多年来一直在推行混沌工程计划。拉吉记录了这门学科的发展历程，从手工操作的小行动到协调的 "游戏日"，再到他们现在支持的复杂的内部工具。所有这些都是在高度规范的流程和结果的背景下进行的：在银行业，"可观察性和审计跟踪与设计定制实验的能力同样重要"。

通过与这五个用例展开对话，我们希望表明，混沌工程学既有足够的历史，有价值记录和常见的行业实践，又足够年轻，可以灵活多样地诠释和实施。

¹本书作者认为混沌工程是一种实验形式。有些作者不同意这一观点，他们使用了 "测试 "一词。参见第 3 章 "实验与测试 "一节。