“可以忽略的深渊：一条通向混沌的道路”--来自Starling Bank的测试

InfoQ主页文章“可以忽略的深渊：一条通往混沌的道路”，来自Starling Bank的测试。

云环境的敌意是弹性架构的礼物，并激发了混沌工程，而混沌工程可能会比激发它的不可预测性更持久。

混沌工程学正在获得一门学科的严格性和外衣，但关键的见解仍然简单而强大。

当Starling Bank从混乱中起步时，他们开始着手将风险从可以忽略的深渊中清除出来。它便宜、容易、有效，而且仍然是一个令人信服的起点。

2016年，Starling实现了自己的简单混沌守护程序，就像他们实现了自己的核心银行系统一样。原因呢？一如既往：简单。

一旦最基本的混乱测试就位，您正在运行的系统预计会出现这种故障，并且是一个为此而构建的开发组织。你已经消除了忽视它的诱惑。

不可靠的实例将我们从架构师与Visio图中的单点故障搏斗的世界带到了工程师理所当然地构建崩溃安全体系结构的世界。在您面前，实例故障足够真实、足够频繁，以至于系统被构建来支持它。在这样做的过程中，我们建立了比我们在裸机上运行的系统更具弹性数量级的系统。

与其说这是理论的改变，不如说是实践的改变。不可靠的例子在很大程度上是世界的一部分，每个人都必须停止忘记它。

因此，随着实例变得更加可靠，以及实时迁移等技术使我们免受这种不可靠性的影响，更不用说具有极高可靠性特征的托管服务的可用性了，这些好处会慢慢消失并被遗忘吗？我们会允许我们的系统再次陷入脆弱吗？

事实上，对于一些人来说，已经是一只混乱的猴子，而不是云的不稳定，让实例失败足以改变他们的心态。自然事件严重到足以成为问题，但还没有严重到改变行为。

你看，这些天我们不会冒险让事情掉进那个可以忽略的深渊。我们给了大自然一个帮助的拳头。

无论你以哪种方式记忆，如果没有在一定程度上不可靠的例子，我们会花更长的时间来养成让它们变得真正不可靠的习惯。自然不可靠孕育了混沌工程。

今天，注入实例故障是入门级的东西。如果您没有烧毁生产中的随机服务器，那么过去几年您在哪里？您的意思是，您没有模拟vPC对等运行速度减慢、EBS抖动和内部DNS中断，同时吊销您的主站点证书并升级您的K8S群集？

我们已经身处这样一个世界，与云可能带来的各种故障模式相比，实例故障看起来绝对是一件非常令人担忧的事情。

云故障模式极难确定，因为云充满了不透明的抽象。有时你甚至不知道一件事是否真的是一件事，更不用说那件事是否会失败，或者它会以不同的方式失败，或者它的失败可能会产生什么影响。任何在云或SRE角色中工作过一段时间的人，都会在某个时候坐在一群工程师中，说出不朽的台词：“谁知道这会发生呢？”

云有一种根本性的不可预测性，这种不可预测性在短期内不会消失。这将使我们在一段时间内保持防守能力。

我们知道，我们对平台运营特征的心理模型是错误的。我们知道我们自己系统的心理模型是错误的。我们知道为第一个心理模型的谎言做准备是愚蠢的，正如相信第二个心理模型的谎言是愚蠢的一样。

混沌工程正在获得一门学科的严格性和外衣，以及一种定义-在一个系统上进行实验，以建立对该系统在生产中承受动荡条件的能力的信心。

湍流和复杂的系统很容易带来足够的恐怖，从而导致混乱。但是，如果我们过于关注复杂性作为不可预测性的根源，我认为我们忽略了一个简单得多的点-这一点与其说是我们所使用的系统，不如说是我们自己的局限性。

想象一下，如果每个抽象都有一个神圣保证的SLA。(他们没有。)。每个类和方法调用，每个库和依赖项。

对于某些SLA(100%，59个)，即使考虑失败也是错误的，更不用说处理或测试了。你花在思考这件事上的时间已经比预期的失败损失更值钱了。在这样的世界里，您仍然会假设没有编译器错误、JVM错误、CPU指令错误-至少在发现这些错误之前是这样。

另一方面，有一些SLA(95%、99.9%)在合理的工作负载下可以有效地保证故障。所以你处理它们，测试它们，你的勤奋就会得到回报。

在这些情况下，我们的行为是正确的。我们理所当然地摒弃荒谬，处理平凡的事情。

然而，当涉及到不太可能发生的事件时，人类的判断相当失败。当处理不太可能的事件的成本(就复杂性而言)看起来令人不快时，我们的直觉往往会强化我们的懒惰。一个系统不一定要动荡或复杂才能暴露这一点。自开发开始以来，开发人员通常都不善于处理错误。

在荒谬和平凡之间潜伏着我所说的不可忽视的深渊。在这里，那些不太可能发生的事件，在我们看来似乎是减少关注的正当理由。

在裸机服务器世界中，“实例”故障被牢牢地置于可以忽略的深渊。这自然导致了脆弱的系统。

云和混沌通过将实例故障重新定位在可以忽略的深渊，修复了脆弱性。

当Starling Bank在混乱中起步时，他们一开始只是简单地、相当不科学地从可以忽略的深渊中消除风险。

这是便宜，简单，有效的，如果你还没有超越这一点，我想建议它可能也非常适合你。

2016年，Starling实现了自己的简单混沌守护程序，就像他们实现了自己的核心银行系统一样。原因与当时和今天做出如此多决策的原因是一样的：简单性。

我记得那个决定。即使在当时，替代方案(带有用于填充磁盘和杀死网络等的恶意脚本)在我们的环境中也不容易使用。它们附带依赖项和配置，这两者都不符合我们的需要。当时我们希望避免基于代理的安排-我们争取尽可能少的活动部件，因此我们开始使用AWS API随意攻击服务器。

建造自己的房子是不是很疯狂？当然不是。一开始，它并不比以下内容复杂：

事实上，…。让我们仔细考虑一下。我们实际上还需要多复杂才能变得更复杂呢？

非常简单。即使没有这样的标志，您也可以取消部署您的混沌服务，或者将您的混沌组缩减到零或其他什么。在您的上下文中可接受的控件类型会有所不同。只要记住，如果你想要摆脱混乱，你可能真的不想要混乱-而且没有风险让它通过自己的弹性奇迹重新焕发生机。

永远{ 如果SwitchedOn()&；&；RollD6()==6{ 日志(“嘿，大家好，顺便说一下，我现在要杀死一台服务器，好吗？”) Kill RandomServer() Log(“现在就做。没有回头路了。Soz。“) } 睡眠(一些分钟()) }。

太原始了！但它切中了基本问题。当您在调查事件时，您的数据显示服务器正在蒸发，您确实需要这些日志行。

顺便说一句，Starling过去曾使用这样的日志行来证明某些与DR相关的审计要求。能够用真实的实际证据来证明事情是非常有趣的。

而且(我觉得有必要指出)您还需要您的其他服务的可观察性。记住，你想要证明你可以杀死一台服务器，并且告诉你，对你来说重要的事情都不会受到影响。

从这里你可以打开一个复杂的世界。你可以变得更可爱更狡猾。今天，你可以看到商业产品和开放源码软件项目来获得灵感，你当然可以用现实生活中的事件来激发你的混乱。

我想说的是：你在那里有正在运作的混乱，它已经是你系统演变中的一股非常强大的力量。

从现在开始，直到永远，您都知道您的系统不容易受到某类问题的影响。看到那些选择有多强大了吗？特别是如果你像Starling Bank那样早做的话。

更重要的是，从现在开始，默认情况下，您正在以一种预料到这种失败情况的方式构建系统，而不仅仅是口头上说它。您已经消除了放弃它的诱惑。你已经挤压了“可以忽略”的深渊。

(好的，好的，…。您可能会担心混沌频率的预期会受到重启的阻碍，这可能是由混沌本身造成的不可预测的。到教室后面去。那是什么？随机化种子？输出。)。

混乱政权的持久性是值得评论的。我说的是“永远”，然而一些人的经验是，他们对混乱的冒险甚至在他们开始之前就已经被免疫拒绝了。文化一直无法转变到可以在横冲直撞的猴子背后看到真正原因的地步。当人们开始接受他们的系统的脆弱性是生活中的一个事实时，就会发生这种情况。

文化在演变，优先事项在转移，工程师被重新分配，架构在成长和演变，规模不断扩大，流行病改变了我们周围的世界。还有一些代码，今天在Starling的生产环境中运行，做的是简单的事情。目前还没有出现过一支混乱的团队。代码是每个人的责任，但它已经运行了四年多。它得到了维护、修复和移动，其重要性也得到了认识和尊重。

它很快就发展了运行其他对我们很重要的实验的能力，比如杀死自动伸缩组中的所有服务器，这实际上是取消了Starling架构中的整个服务。在我们的非生产环境中，这可以通过Slackbot按需调用，并且所有工程师都可以用来调查或验证假设。

这正好处在可以忽略的深渊中。这很少发生，但确实发生了。如果您认为同一伸缩组中三个不同可用区的三台服务器同时丢失的可能性极小，请记住它们都在运行相同的代码，并且部署在大致相似的时间点。我们正在模拟一种我称之为“内在”(由我们自己的发展引起)而不是“外在”(由环境引起)的失败类型。如果我们将错误的更改推送到所有服务器，我们可以很容易地将它们全部删除。

我们添加了导致数据库故障转移的功能。服务因忽略其数据库可能消失的可能性而臭名昭著，原因有两个：i)非常罕见；ii)人们普遍认为您无能为力。I)把我们带回了可以忽略的深渊。Ii)是完全错误的。您可以做一些事情，即按兵不动，并准备好在您可以联系数据库的那一刻再次开始工作，除非您仔细考虑过，否则这不太可能是您的服务的行为。

无论什么实验来来去去，在每个人的脑海中纠结着混乱的事情仍然是一个简单的知识，那就是混沌守护进程就在那里，它总是愤怒的，它总是杀死服务器。当人们(无论是技术还是商业)了解服务器故障是怎么回事时，你就朝着解释、正常化和嵌入更有趣的实验迈出了重要的一步。

所以，不要不做简单的事情。不要绕道配置灵性混乱猴子。把大量的注意力放在简单的事情上。简单的事情可以成为文化的一部分。它们见效快。

永远不要忘记，您正在改进的系统是一个由技术和为其工作的人员组成的系统。确定哪些恐惧在你可以忽略的深渊中萎靡不振，并利用混乱将它们拉到公开的地方。

格雷格·霍金斯是科技、金融科技、云和DEVOP的独立顾问，也是英国国内外银行和金融技术公司的顾问。他在2016年至2018年担任Starling Bank的首席技术官，在此期间，这家金融科技初创企业获得了银行牌照，从无到有，在两个移动平台上都从零到突破了100K的下载大关。他至今仍是Starling Bank的高级顾问。Starling从无到有构建了全栈银行系统，成为英国第一个公开可用的基于云的活期账户，第一家拥有支持PSD2的开放API的英国银行，并在2018年、2019年和2020年被评为最佳英国银行和最佳英国活期账户。

InfoQ上上周内容的综述每周二都会发布。加入一个超过25万名高级开发人员的社区。 查看示例。

选择您的国家/地区我同意InfoQ.com按照本隐私声明中的说明处理我的数据。