混沌工程

第 4 章 斯拉克的灾难作品剧场

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

理查德-克劳利

如果你的团队和工具天生就不具备混沌工程技术，你该如何 ？在设计系统时，人们认为计算机可以并应该长期使用，而将混沌技术融入系统似乎是一项难以克服的任务。与云计算的后继者相比，在这种思维模式下诞生的复杂系统往往不太适应底层计算机的极端短暂性。这类系统在最佳条件下可能表现非常出色，但一旦出现故障，系统就会迅速退化，有时甚至是灾难性的。

您可能就是这样一个系统的主人。它并不是为适应混乱而设计的，但无论您是否喜欢，随着其规模的扩大和持续的开发要求它做得更多、更快、更可靠，混乱即将来临。没有时间重写了--系统已经处于压力之下。在旧系统上应用新的混沌工程实践很可能会让情况变得更糟。你需要一种不同的策略。

本章介绍了一种策略，通过引入故障和网络分区，以周到、可控的方式，安全、系统地测试不一定在设计时考虑到混沌工程的复杂系统。这是一个过程，而不是自动化过程，它能帮助团队了解软件的易损性，促进改进，并验证系统是否能容忍可以预见的故障。自 2018 年初以来，Slack 一直在积极使用这一流程。通过二十多次演练，它发现了漏洞，证明了新旧系统的安全性，并影响了许多工程团队的路线图。

不过，第一步是确保相关系统甚至在理论上已经做好准备，可以承受你期望它们遇到的各种故障。

改造混沌

要提高系统的容错能力，您可能会用到的工具和技术与现代化系统、云原生系统、更可靠系统或高可用系统相同。让我们回顾一下。

旧系统中常见的设计模式

现有的 系统，尤其是较老的现有系统，比现在新建的系统更有可能假定单台计算机可以使用很长时间。这个简单的假设是许多不容错系统的核心。在那个避免使用备用计算机的时代，我们做出了这样的假设--这是一种浪费，而且从那时起，这种假设就一直存在于我们的系统设计中。

当计算机稀缺时，它们很可能在购买后不久就配备了操作系统和所有配件，并在其整个使用寿命内不断升级。配置过程可能已经实现了高度自动化，尤其是当许多计算机同时出现在装卸区时，但启动该过程可能是人工操作。在规模较小的系统中，更多的配置过程都是人工操作，这种情况并不少见。

故障切换也是如此， ，通常是由人工对某些故障或偏离正常运行的情况作出适当的反应。在特别老旧的系统中，故障和故障切换之间的这段时间就是客户的停机时间。故障切换被认为是罕见的，因此自动化，在某些情况下，甚至文档和培训显然都不值得。

备份和恢复 是现有系统可能落后于最新技术的另一个领域。从积极的方面看，几乎可以肯定正在进行备份。但并不确定这些备份是否可以还原或是否可以快速还原。与故障转移一样，从备份中进行恢复曾一度是一种罕见的情况，显然不值得进行自动化处理。

我们更容易接受不太可能发生的事件的潜在影响--也许它们根本不会发生！当故障率随着规模的扩大而增加，或者当影响变得不那么为企业所接受时，为接受这些风险而构建的现有系统就很难应对了。

为了 的完整性，我想简单谈谈单体问题。一个系统跨过某个阈值就会成为单体系统，这并没有一个精确的阈值--它是相对的。与面向服务的架构相比，单体系统的容错性本身并没有高低之分。不过，它们可能更难改造，因为它们的表面积太大，难以影响增量变化，也难以限制故障的爆炸半径。也许你决定要拆散你的单体，也许你不会。容错 这两条路都可以走。

新系统中常见的设计模式

相比之下，现在设计的系统可能会假定单个计算机会经常出现故障。这种新思维会带来许多后果，但最重要的可能是，系统被设计为可同时在 ...