遗忘的深渊：英国Starling数字银行混沌测试实践之路

关键要点

• 云环境的陷阱催生了弹性架构，它们也是混沌工程的灵感来源。混沌工程的生命力可能会超越不可预测性。
• 混沌工程渐渐有了成为一门学科的严密性，但它的关键思想仍然是简单而强大。
• 当Starling银行开始实践混沌工程时，他们先从消除来自“遗忘的深渊”的风险开始。这样做成本低、简单、有效，而且是一个很好的起点。
• 2016年，Starling银行实现了他们自己的混沌守护进程，就像他们实现了自己的核心银行系统一样。为什么这么说？答案一如既往：简单性。
• 即使是运行最基本的混沌测试，那也说明你的系统存在这样的故障，也就不会想要忽略它们。

不可靠性是云计算给我们这个世界最大的一个礼物。

不可靠性把我们从一个架构师在 Visio 图上描绘单点故障的世界带到了一个工程师全力构建安全架构的世界。故障是真实存在的，而且就在你眼前频繁地发生，所以我们构建的系统需要能够承受这些故障。在这个过程中，我们构建的系统比那些在裸机上运行的系统更具弹性。

与其说这是理论的改变，不如说是实践的改变。不可靠性是这个世界非常重要的一部分，每个人都不能忽略它。

它可以像云团一样发生构造上的变化，迫使我们不断纠正我们的行为。

随着可靠性不断增加，实时迁移等技术将我们与不可靠性隔离开来（更不用说具有极端可靠性的托管服务的普及），这些好处会慢慢消失并被遗忘吗？我们会允许我们的系统再次变得脆弱吗？

我认为不会这样，而混沌就是我们的救赎。

事实上，对一些人来说，是Chaos Monkey（而不是云的不稳定性）把故障摆在他们的面前，足以让他们改变心态。自然发生的故障已经严重到足以成为一个问题，但还没有严重到足以改变人们的行为。

现在我们不再冒险让事情陷入遗忘的深渊，我们会向自然伸出援助之手。

不管你怎么想，某种程度上说，如果没有不可靠性，我们需要花更长的时间来养成提升可靠性的习惯。自然的不可靠性孕育了混沌工程。

复杂性

现如今，注入故障已经是入门级的东西。如果你没有在生产环境中随意烧毁服务器，那么过去几年你都在干什么？你的意思是你没有模拟虚拟机对等运行变慢、EBS 抖动和内部 DNS 中断，或者撤销主站点证书和升级 K8s 集群？

(不要真的这样做)。

我们已经处在这样的一个世界，与云能够给我们带来的故障模式相比，这个世界的故障看起来更像是预先设计的。

云的故障模式非常难以确定，因为云充满了不透明的抽象。有时你甚至不知道一个东西是否是真实的，更不用说它会不会出故障，或者故障有几种不同的方式，或者故障可能会造成怎样的影响。任何在云或 SRE 方面工作过一段时间的人都曾在一群工程师面前说过一句不朽的话：“谁知道会发生这种事？”

云的不可预测性在短期内不会消失，我们不得不在一段时间内继续保持防御性。

这是在我们考虑在云端构建系统之前。

我们都学到了什么？

我们知道，我们的平台运维特征思维模型是错误的。我们知道，我们的系统思维模型是错误的。我们知道，基于第一种思维模型构建系统是愚蠢的，这与相信第二种思维模型同样愚蠢。

混沌工程正逐渐具备成为一门学科所需要的严谨性和定义——通过系统实验建立对系统能力的信心，相信系统可以承受生产环境的恶劣条件。

湍流和复杂的系统很容易带来足够的恐慌，进而进入混沌状态。但是，如果我们过度地将复杂性视为不可预测性的来源，就会忽略一个简单的东西——它与我们使用的系统无关，而更多地与我们自身的局限性有关。

遗忘的深渊

想象一下，如果每一种抽象都有 SLA(实际上没有)，甚至每个类和方法、每个库和依赖。

假设 SLA 是一个简单的百分比(它们从来都不是)。

对于某些 SLA(100%、50 个 9)，你就不应该考虑它们的故障，更不用说处理或测试它们了。你花在思考这件事上的那几秒钟，价值可能已经超过了因为故障而蒙受的预期损失。在这样一个世界里，你仍然会假设没有编译器错误、JVM 错误、CPU 指令错误——至少在这些错误被发现之前是这样的。

而对于某些 SLA(95%、99.9%)，在合理的工作负载下肯定会出故障。所以你需要处理它们，测试它们，你的努力就会得到回报。

在这些情况下，我们的行为是正确的。

然而，当遇到不太可能发生的事情时，人类的判断就会非常糟糕。当处理不太可能发生的事情(就复杂性而言)的成本看起来令人不快时，我们的直觉倾向于变懒惰。这个不一定要让系统变混乱或变复杂才能暴露出这个问题，开发人员的错误处理程序通常都很糟糕。

在荒诞和平凡之间潜伏着“遗忘的深渊”。这里有一些不太可能发生的事件，在我们看来，它们似乎不值得我们关注。

在裸机服务器世界里，“实例”故障绝对是可以忽略的。这自然导致了系统的脆弱。

云和混沌通过将实例故障拉出遗忘的深渊来修复脆弱性。

当 Starling 银行开始实施混沌实践时，他们的出发点很简单，也不强调科学性，就是消除遗忘的深渊所带来的风险。

这种做法成本低、简单、有效，如果你们还没有达到这个程度，可以考虑效仿。

简单的力量

2016 年，Starling 银行实现了他们自己的混沌守护进程，就像他们实现了自己的核心银行系统一样。为什么这么说？答案一如既往：简单性。

我还记得，当时其他的替代方案(包括用于填充磁盘和破坏网络的恶意脚本)在我们的环境中也不容易使用。它们需要依赖项和配置，都不满足我们的需求。那时，我们想避免使用基于代理的方案——我们尽量减少可移动的部分，所以我们开始使用 AWS API 来攻击服务器。

自己动手做是不是很疯狂？当然不是。一开始，它并不比这个复杂多少：

forever {  if rollD6() == 6 {     killRandomServer()  }  sleep(someMinutes())}

复制代码

我们还需要多复杂呢？

好吧，必须有可控的灵活性。

forever {  if switchedOn() && rollD6() == 6 {     killRandomServer()  }  sleep(someMinutes())}

复制代码

非常的简单。即使不使用开关，你也可以取消部署混沌服务，或者将混沌规模缩小到零或其他，在你的环境中可用的控制类型会有所不同。只要记住，如果你想关闭混沌，那你可能是真的想要关掉它——而且不存在它通过惊人的韧性重新恢复生机的风险。

还缺了什么？你必须加入可观察性。

forever {  if switchedOn() && rollD6() == 6 {    log(“Hey everyone, by the way I’m killing a server now, okay?”)    killRandomServer()    log(“Done it now. No going back. Soz.”)  }  sleep(someMinutes())}

复制代码

这么的原始！但它确实提供了最根本的东西。当你在诊断一个故障时，数据显示服务器正在关闭，你确实需要这些日志。

凑巧的是，Starling 银行曾经在某些 DR 相关的审计中使用过这样的日志。能够用真实的证据来证明事情是非常有趣的。

而且(我不得不指出)你的其他服务也确实需要可观察性。记住，你需要证明你可以关掉服务器，而且对你来说重要的东西不会受到影响。

你可能已经在监控那些对你重要的东西了。

你可以从这里开始打开一个复杂的世界。你可以变得更可爱，更乖巧。现如今，你可以从商业产品和 OSS 项目中获得灵感，当然你也可以使用真实的事故来激发你的混沌实践。

我想说的是：你的系统里有一个功能混乱的地方，它已经成为系统进化过程中一股非常强大的力量。

从现在开始，直到永远，你都知道你的系统不会在某些问题上不堪一击。看到这有多强大了吗？特别是如果你能像 Starling 银行那样早就开始做的话。

更重要的是，从现在起，默认情况下，你构建的系统应该能够预期到这种故障。你已经打消了忽视它的念头。你已经把它从遗忘的深渊里拉了出来。

固化

混沌的长命值得一提。我会说“永远”，但有些人认为他们在进入混沌之前的尝试已经被免疫排斥。文化无法达到可以在狂暴的猴子背后看到真正原因的地步。当人们开始接受系统脆弱性作为事实时，就会发生这种情况。

文化在演变，优先级次序在改变，工程师被重新分配，架构在成长和演变，大规模的冲击和流行病改变了我们周围的世界。现在还有一些代码在 Starling 银行的生产环境中运行，它们只处理一些简单的任务。他们从来就没有过一个混沌团队。每一个人都在负责这些代码，而它们已经运行了四年多。他们维护、修复和移动这些代码，并知道它们的重要性。

它很快发展出了运行重要实验的能力，比如关闭所有自动伸缩组中的服务器，这实际上是破坏了 Starling 银行架构中的一整个服务。在我们的非生产环境中，这可以通过 slackbot 进行按需调用，并且工程师们可以进行诊断或验证假设。

它就在遗忘的深渊里。这种情况很少发生，但确实发生了。如果你认为在三个不同的可用区域的同一个伸缩组中同时丢失三台服务器是极其不可能的，但请记住，它们都在运行相同的代码，并且是在大致相似的时间点部署的。我们正在模拟一种故障，我称之为“内在故障”(由我们的开发活动导致的)，而不是“外在故障”(由环境引起的)。如果我们向所有服务器推送一个错误的变更，很容易就能将它们搞崩溃。

我们添加了可以导致数据库发生故障转移的能力。服务常常忽视了数据库可能会消失的可能性，原因有二：一个是这种情况非常罕见，一个是人们普遍认为没有什么可做的。第一个原因让我们陷入了遗忘的深渊。第二个原因是完全错误的。你完全可以做一些事情，即静心等待，并在恢复数据库的那一刻让服务进入正常状态，除非你有仔细考虑过，否则这个任务不大可能由服务来完成。

实验来来去去，而每个人心中都有了一个简单的认知，那就是混沌的守护进程一直都在那里，它总是怒气冲冲地破坏着服务器。当人们了解服务器故障发生的原因时，你就向解释、规范和嵌入更有趣的实验迈出了重要的一步。

所以不要拒绝做简单的事情，请把大量的注意力放在简单的事情上。简单的事情也可以成为文化的一部分。它们见效快。

永远不要忘记，你正在改进的系统是一个技术系统，还包括开发这个系统的人。找出遗忘的深渊中有哪些恐怖的东西在折磨你，然后用混沌把它们从深渊中拖出来。

作者简介

Greg Hawkins 是科技、金融科技、云计算和 DevOps 方面的独立顾问，同时也是英国及海外一些银行和金融科技公司的顾问。在 2016 年至 2018 年期间，他担任 Starling 银行的首席技术官。在此期间，这家金融科技初创企业获得了银行业牌照，从零开始，在两个移动平台上都突破了 10 万次下载大关。他现在仍然是 Starling 银行的高级顾问。Starling 银行从零开始构建了完整的银行系统，成为英国第一个公开可用的基于云计算的活期存款账户，第一家拥有支持 PSD2 开放 API 的英国银行，并在 2018 年、2019 年和 2020 年被评为最佳英国银行和最佳英国活期存款账户。

原文链接：

The Abyss of Ignorable: a Route into Chaos Testing from Starling Bank