PDF从故障测试中解放天才
普通用户需要能够自动选择定制故障注入的工具。
Peter Alvaro 和 Severine Tymon
云应用程序的异构性、复杂性和规模使其容错特性的验证充满挑战。公司正在放弃形式化方法，转而采用大规模测试，在测试中，组件会被故意破坏，以识别软件中的弱点。例如，Jepsen 等技术将故障注入测试应用于分布式数据存储，而混沌工程则对生产系统（通常是对实时流量）执行故障注入实验。这两种方法都引起了工业界和学术界的关注。
不幸的是，基础设施可以测试的不同故障组合的搜索空间是难以处理的。现有的故障测试解决方案需要熟练且聪明的用户来提供要注入的故障。这些超级用户，被称为混沌工程师和 Jepsen 专家，必须研究被测系统，观察系统执行情况，然后提出关于哪些故障最有可能暴露真实系统设计缺陷的假设。这种方法从根本上来说是不可扩展且不合原则的。它依赖于超级用户解释分布式系统如何利用冗余来掩盖或改善故障的能力，更重要的是，识别这些冗余不足的能力——换句话说，就是人类的天才。
本文呼吁分布式系统研究社区改进容错测试的现有技术水平。普通用户需要能够自动选择定制故障注入的工具。我们推测，超级用户选择实验的过程——观察执行情况、构建系统冗余模型以及识别模型中的弱点——可以在软件中有效地建模。本文描述了一个验证这一推测的原型，展示了来自实验室和现场的早期结果，并确定了可以使这一愿景成为现实的新研究方向。
未来属于混乱
为用户和客户提供“始终在线”的体验意味着分布式软件必须是容错的——也就是说，它必须被编写为能够预测、检测并掩盖或优雅地处理硬件故障和网络分区等故障事件的影响。编写容错软件——无论是用于涉及少量物理机器交互的分布式数据管理系统，还是用于涉及数万台机器协作的 Web 应用程序——仍然极其困难。虽然验证和程序分析领域的最新技术在学术界不断发展，但工业界却朝着完全相反的方向发展：远离形式化方法（尽管有一些值得注意的例外41），转而采用将测试与故障注入相结合的方法。
以下部分将描述这种趋势的根本原因、迄今为止它为何如此成功，以及为何它在当前的实践中注定要失败。
旧神
古老的迷思：交给专家吧。
曾几何时，分布式系统研究人员和从业人员都确信，解决容错问题的责任可以委派给一小群专家。故障检测、恢复、可靠通信、共识和复制的协议可以一次性实现并隐藏在库中，供非专业人士使用。
这是一个合理的梦想。毕竟，抽象是克服计算机科学复杂性的最佳工具，从不可靠的组件构建可靠的系统是经典系统设计的基础。33 诸如进程对18 和 RAID45 等可靠性技术表明，在某些情况下，部分故障可以在系统的最低级别处理，并成功地对应用程序进行掩盖。
不幸的是，这些方法依赖于故障检测。完美的故障检测器在分布式系统中是不可能实现的，9,15 在分布式系统中，不可能区分延迟和故障。试图掩盖分布式系统中部分故障引起的基本不确定性——例如，RPC（远程过程调用8）和 NFS（网络文件系统49）——遇到了（臭名昭著的）困难。尽管广泛认为这些尝试是失败的抽象，28 但在没有更好抽象的情况下，人们继续依赖它们，这让开发人员、运营商和用户感到沮丧。
在分布式系统中——即通过消息交互的松耦合组件系统——组件的故障仅表现为消息的缺失。检测消息缺失的唯一方法是通过超时，这是一个模棱两可的信号，意味着消息永远不会到来，或者仅仅是尚未到来。超时是一个端到端的问题28,48，最终必须由应用程序来管理。因此，分布式系统中的部分故障会向上冒泡，并阻碍任何抽象尝试。
老卫队
现代的迷思：形式化验证的分布式组件。
如果我们不能依靠天才来隐藏部分故障的幽灵，那么下一个最好的希望就是正面面对它，并配备工具。直到最近，我们中的许多人（特别是学术界人士）都寄希望于形式化方法，例如模型检查16,20,29,39,40,53,54，以帮助“凡人”程序员编写分布式代码，使其能够在分布式执行中普遍存在不确定性的情况下维护其保证。详尽地搜索大规模系统的状态空间是不合理的（例如，无法对 Netflix 进行模型检查），但希望模块化和组合（征服复杂性的下一个最佳工具）可以发挥作用。如果可以对单个分布式组件进行形式化验证，并以保留其保证的方式将它们组合成系统，那么可以通过局部容错的组合获得全局容错。
不幸的是，这同样是白日梦。大多数模型检查器都需要形式化规范；大多数真实世界的系统都没有规范（或者自从设计阶段以来就没有规范，而且已经过了很多版本）。软件模型检查器和其他程序分析工具需要被研究系统的源代码。源代码的可访问性也是一个日益站不住脚的假设。Jepsen 等工具针对的许多数据存储都是闭源的；大规模架构虽然通常由开源组件构建，但却越来越混合（用多种语言编写）。
最后，即使您假设规范或源代码可用，模型检查等技术也不是确保应用程序容错的可行策略，因为正如上一节讨论的那样，在超时的背景下，容错本身是一个端到端属性，不一定在组合下成立。即使您幸运地构建了一个由单独验证的组件组成的系统，也不能保证该系统是容错的——您可能在将它们粘合在一起的“胶水”中犯了一个关键错误。
先锋
新兴的理念：YOLO（You Only Live Once，你只活一次）
现代分布式系统过于庞大、过于异构且过于动态，以至于这些经典的软件质量方法无法扎根。作为回应，从业人员越来越依赖基于测试和故障注入6,14,19,23,27,35的弹性技术。这些“黑盒”方法（扰动和观察整个系统，而不是其组件）更适合测试容错等端到端属性。（可以说）与从内部理解系统如何工作来推导出保证不同，系统的测试人员从外部观察其行为，从而建立对其在压力下正确运行的信心。
最近在这个领域涌现出两个巨头：混沌工程6和 Jepsen 测试。24 混沌工程是一种积极扰动生产系统以提高整体站点弹性的实践，由 Netflix6 开创，但此后 Linkedin52、Microsoft38、Uber47 和 PagerDuty5 都开发了基于混沌的基础设施。Jepsen 对未经修改的分布式数据管理系统执行黑盒测试和故障注入，以寻找正确性违规（例如，显示执行不是线性化的反例）。
这两种方法都是务实的和经验性的。每种方法都通过运行系统并观察其行为来建立对系统在故障下如何运行的理解。这两种方法都提供了一种随用随付的弹性方法：初始集成成本较低，执行的实验越多，对被测系统健壮性的信心就越高。由于这些方法代表了对现有最佳测试实践的直接丰富，并结合了广为人知的故障注入技术，因此它们很容易被采用。最后，也许最重要的是，这两种方法都被证明在识别错误方面是有效的。
不幸的是，这两种技术也都有一个致命的缺陷：它们是手动过程，需要极其复杂的运营商。混沌工程师是站点可靠性工程师的一个高度专业化的子类。为了设计自定义的故障注入策略，混沌工程师通常会与不同的服务团队会面，以了解各种组件及其交互的特性。然后，混沌工程师会针对那些看起来可能存在潜在容错弱点的服务和交互。这种方法不仅难以扩展，因为它必须为每个新的服务组合重复进行，而且其关键货币——被研究系统的心理模型——隐藏在人的大脑中。这些点让人想起行业中更大的（也更令人担忧的）趋势，即走向可靠性祭司制度，7 配备图标（仪表板）和仪式（剧本）。
Jepsen 原则上是一个任何人都可以使用的框架，但据我们所知，迄今为止 Jepsen 发现的所有报告的错误都是由其发明者 Kyle Kingsbury 发现的，他目前经营着一家“分布式系统安全研究”咨询公司。24 将 Jepsen 应用于存储系统需要超级用户仔细阅读系统文档，生成工作负载，并观察被测系统的外部可见行为。然后由运营商从大量的“复仇女神”（nemeses），包括机器崩溃和网络分区中选择那些可能驱动系统返回不正确响应的故障计划。
循环中的人是需要跟上软件进化的系统的死亡之吻。人类的注意力应该始终针对计算机无法完成的任务！此外，混沌和 Jepsen 测试所需的专家既昂贵又稀少。本文的其余部分展示了如何从故障测试过程中解放天才。
我们不需要另一个英雄
关于我们对分布式系统内部结构的可见性的快速变化的假设已经使许多（如果不是全部）经典的软件质量方法过时，而新兴的“基于混沌”的方法由于其对循环中天才的要求而变得脆弱且不可扩展。
本节通过考察加速了久经考验的弹性技术消亡的相同变化的环境如何启用新技术，来介绍我们对自动化故障测试的愿景。我们认为，将专家从故障测试循环中自动化的最佳方法是在软件中模仿他们的最佳实践，并展示复杂的观测基础设施的出现如何使这成为可能。
秩序正在迅速消退
对于大规模分布式系统，传统软件质量方法的三个基本假设正在迅速成为过去。第一个消失的是你可以依靠专家来解决该领域最困难问题的信念。第二个是系统形式化规范可用的假设。最后，任何需要源代码可用的程序分析（广义定义）都必须被排除在外。这些假设的侵蚀有助于解释为何从经典的学术弹性方法转向之前描述的黑盒方法。
在这种新的现实中，理解复杂系统的行为有什么希望吗？幸运的是，从内部理解分布式系统比以往任何时候都更加困难这一事实，导致了允许我们从外部理解它们的工具的快速发展。调用图日志记录最初由 Google 描述；51 类似的系统正在 Twitter4、Netflix1 和 Uber50 中使用，并且该技术此后已标准化。43 可以合理地假设，现代基于微服务的互联网企业已经对其系统进行了检测，以收集调用图跟踪。许多专注于可观测性的初创公司最近涌现。21,34 同时，用于数据处理系统的来源收集技术11,22,42 正在变得成熟，操作系统级别的来源工具也是如此。44 最近的工作12,55 试图从原始日志中推断分布式计算的因果关系和通信结构，即使对于未经检测的系统，也使对结果的高级解释触手可及。
远离专家
关于测试分布式系统。正如他们所提到的，Chaos Monkey 很棒，我也强烈建议让 Kyle 运行 Jepsen 测试。 ——HackerRumor 上的评论员
虽然这句话是轶事，但很难想象有比这更好的例子来说明当前最先进技术的根本不可扩展性。一个人不可能跟上分布式系统实现的爆炸式增长。如果我们能够将人从这个关键循环中移除，我们必须这样做；如果我们不能，我们可能应该认输。
理解如何自动化任何过程的第一步是理解我们想要抽象掉的人工组件。混沌工程师和 Jepsen 超级用户如何在实践中应用他们独特的天才？本节的其余部分描述了两种方法通用的三步配方。
步骤 1：观察系统运行
混沌和 Jepsen 过程的人工元素从有原则的观察开始，广义地定义。
混沌工程师在研究了与给定类别的交互相关的服务的外部 API 后，会与工程团队会面，以更好地了解各个服务实现的细节。25 为了理解服务之间的高级交互，工程师随后将在跟踪存储库中仔细阅读调用图跟踪。3
Jepsen 超级用户通常首先审查产品文档，既要确定系统应该维护的保证，又要了解一些关于系统实现这些保证的机制。从那里，超级用户基于与系统外部 API 的交互构建系统行为模型。由于被研究的系统通常是数据管理和存储系统，因此这些交互涉及生成读取和写入的历史记录。31
理解分布式系统中可能出错的第一步是观察事物正确运行：观察常见情况下的系统。
步骤 2：构建系统如何容忍故障的心理模型
两种方法的共同下一步是最微妙和主观的。一旦对分布式系统的行为（至少在常见情况下）有了心理模型，如何使用它来帮助选择要注入的适当故障？在这一点上，我们不得不涉足猜测：请耐心等待。
容错就是冗余。给定一组固定的故障，我们说一个系统是“容错的”，当且仅当它在发生这些故障的所有执行中都能正确运行。“正确运行”是什么意思？正确性是一个特定于系统的概念，但广义上来说，是用在系统执行过程中保持的属性（例如，系统不变量或安全属性）或在执行期间建立的属性（例如，活性属性）来表达的。我们交互的大多数分布式系统，尽管它们的执行可能是无限的，但仍然提供有限的、有界的、具有结果的交互。例如，广播协议可能在反应式系统中“永远”运行，但每次广播传递给所有组成员都构成一次成功的执行。
通过这种方式看待分布式系统，我们可以修改定义：如果一个系统提供足够的机制来克服给定类别的故障，从而实现其成功的结果，那么该系统就是容错的。
步骤 3：制定针对门面弱点的实验
如果我们能够理解系统获得良好结果的所有方式，我们就可以理解它可以容忍哪些故障（或哪些故障它可能很敏感）。我们断言，（无论他们是否意识到！）混沌工程师和 Jepsen 超级用户根据系统逐个系统地确定要注入哪些故障的过程，正是使用这种推理。目标实验应该练习一种故障组合，这种组合会消除所有对预期结果的支持。
执行实验结果证明是容易的部分。故障注入基础设施，很像可观测性基础设施，近年来发展迅速。与诸如 Chaos Monkey23 等随机的、粗粒度的分布式故障注入方法相比，诸如 FIT（故障注入测试）17 和 Gremlin32 等方法允许以高精度在单个请求的粒度上注入故障。
步骤 4：盈利！
这个过程可以有效地自动化。早先描述的复杂跟踪工具的出现，使得即使从黑盒系统的执行中构建冗余模型也比以往任何时候都容易。故障注入基础设施的快速发展，使得比以往任何时候都更容易在大型系统上测试故障假设。图 1 说明了本节中描述的自动化如何恰好位于现有的可观测性基础设施和故障注入基础设施之间，消耗前者，维护系统冗余模型，并使用它来参数化后者。系统结果的解释和故障注入基础设施已经可用。在当前的技术水平下，将它们拼合在一起的拼图碎片（冗余模型）是一个手动过程。LDFI（在下一节中解释）表明，此组件的自动化是可能的。
对过去的猛烈抨击
在之前的工作中，我们介绍了一种名为 LDFI（沿袭驱动的故障注入）的错误查找工具。2 LDFI 使用在分布式执行模拟期间收集的数据沿袭来构建系统结果的派生图。这些图的功能很像前面“远离专家”部分描述的系统冗余模型。然后，LDFI 将派生图转换为布尔公式，其满足赋值对应于使结果的所有派生无效的故障组合。针对这些故障的实验要么会暴露错误（即，预期结果未能发生），要么会揭示额外的派生（例如，在超时后，系统故障转移到备份），这些派生可用于丰富模型并约束未来的解决方案。
LDFI 的核心是重新应用来自数据管理系统的广为人知的技术，将容错视为物化视图维护问题。2,13 它将分布式系统建模为查询，将其预期结果建模为查询结果，并将诸如“副本 A 在时间 t 处于运行状态”和“节点 X 和 Y 在间隔 i...j 期间存在连接”等关键事实建模为基本事实。然后，它可以提出一个“如何”查询37：对基本数据的哪些更改将导致视图中派生数据的更改？此查询的答案是根据当前模型可能使预期结果无效的故障。
这个想法似乎牵强附会，但 LDFI 方法显示出巨大的希望。最初的原型证明了该方法在协议层面的有效性，识别了复制、广播和提交协议中的错误。2,46 值得注意的是，LDFI 再现了 Kafka 分布式日志26 使用的复制协议中的一个错误，该错误最初由 Kingsbury（手动）识别。30 稍后迭代的 LDFI 部署在 Netflix1，在那里（很像图 1 中的说明），它被实现为一个微服务，该微服务从调用图存储库服务消耗跟踪，并为故障注入服务提供输入。自部署以来，LDFI 已在 Netflix 的面向用户的应用程序中识别出 11 个关键错误。1
来自未来的传言
上一节中介绍的先前研究仅仅是冰山一角。实现分布式系统完全自动化故障测试的愿景仍有许多工作要做。本节重点介绍有希望的新兴研究，并确定有助于实现我们愿景的新方向。
不要过度思考故障注入
在分布式系统弹性测试的背景下，尝试枚举和忠实地模拟每种可能的故障是一种诱人但分散注意力的途径。理解所有故障原因的问题与目标并不直接相关，目标是确保旨在检测和缓解故障的代码（及其配置）按预期执行。
考虑图 2：左侧的图表显示了基于微服务的架构；箭头表示客户端请求生成的调用。右侧放大了一对交互服务。调用者服务中的阴影框表示旨在检测和处理被调用者故障的容错逻辑。故障测试的目标是此逻辑中的错误。在此错误搜索中针对的容错逻辑表示为调用者服务中的阴影框，而注入的故障影响被调用者。
从调用者的角度来看，所有故障的常见效果是显式错误返回、响应损坏和（可能是无限的）延迟。在这些表现形式中，前两种可以通过单元测试充分测试。最后一种很难测试，导致代码分支很少执行。如果我们仅注入延迟，并且仅在组件边界处注入延迟，我们推测我们可以解决与容错相关的大部分错误。
无处不在的解释
如果我们能够提供更好的系统结果解释，我们就可以构建更好的冗余模型。不幸的是，LDFI 等系统的入门障碍是软件开发人员和运营商不愿检测其系统以进行跟踪或沿袭收集。幸运的是，操作系统级别的沿袭收集技术已经成熟，可以应用于未经检测的系统。
此外，容器革命使得在单个虚拟机管理程序中模拟黑盒软件的分布式执行比以往任何时候都更容易。我们正在积极探索从未经修改的分布式软件中收集系统调用级别的沿袭，以便选择自定义的故障注入计划。这样做需要从底层跟踪中推断应用程序级别的因果结构，识别观察到的执行中的适当切割点，最后将执行与故障注入操作同步。
我们还对从甚至更嘈杂的信号（例如原始日志）中推断高级解释的可能性感兴趣。这将使我们能够放宽对被研究系统已检测以收集执行跟踪的假设。虽然这是一个难题，但在 Facebook 开发的 Mystery Machine12 等工作显示出巨大的希望。
迈向更好的模型
LDFI 系统使用派生图表示系统冗余，并将识别可能的错误的任务视为物化视图维护问题。因此，LDFI 能够利用来自数据管理系统研究历史的广为人知的理论和机制。但这只是表示系统如何提供替代计算以实现其预期结果的多种方法之一。
LDFI 方法的一个缺点是它依赖于确定性假设。特别是，它假设如果它已经目睹了一个计算，该计算在特定的偶然性（即，给定某些输入并在存在某些故障的情况下）下产生成功的结果，那么在该偶然性下，任何未来的计算都将产生相同的结果。也就是说，它忽略了分布式系统中固有的时间不确定性。更合适的系统冗余建模方式是拥抱（而不是抽象掉）这种不确定性。
分布式系统本质上是概率性的，并且可以认为更好地以概率方式建模。未来的工作方向包括系统冗余的概率表示，以及探索如何利用这种表示来指导故障实验的搜索。我们鼓励研究界加入进来，探索系统冗余的替代内部表示。
将解释由内而外地翻转
数据库研究中关于数据沿袭的大部分经典工作都集中在与人机交互相关的方面。为什么查询返回特定结果的解释可用于调试查询和初始数据库——给定意外结果，可以对查询或数据库进行哪些更改来修复它？相比之下，在我们设想的系统类别中（以及对于 LDFI 具体而言），解释是推理器内部语言的一部分，用于构建冗余模型，以便驱动故障搜索。
理想情况下，解释应该在两个世界中都发挥作用。毕竟，当诸如 LDFI 之类的错误查找工具识别出与正确性属性的反例时，程序员的工作才刚刚开始——现在他们必须承担分布式调试的繁重工作。围绕调试的工具并没有跟上分布式系统爆炸式发展的步伐。我们继续使用为单站点、统一内存和单时钟设计的工具。虽然我们不确定理想的分布式调试器应该是什么样子，但我们非常确定它看起来不像 GDB（GNU 项目调试器）。36 LDFI 使用的派生图显示了沿袭如何在调试中发挥作用，方法是提供系统如何达到错误状态的简洁、可视的解释。
这条研究路线可以进一步推进。为了理解 LDFI 中错误的根本原因，人工操作员必须审查良好和错误执行的沿袭图，然后检查它们的不同之处。直观地说，如果您可以抽象地从良好结果的解释中减去（假设不完整的）错误结果的解释，10 那么差异的根本原因很可能接近差异的“前沿”。
结论
在用于确定分布式系统是否容错的技术中，正在发生巨大的变化。诸如混沌工程和 Jepsen 之类的故障注入方法的出现是对专家程序员、形式化规范和统一源代码的可用性下降的反应。尽管这些新方法前景广阔，但它们都因依赖于决定注入哪些故障的超级用户而受到阻碍。
为了解决这个关键的缺点，我们提出了一种建模并最终自动化这些超级用户执行的过程的方法。实现这一愿景的使能技术是行业中日益普及的快速改进的可观测性和故障注入基础设施。虽然 LDFI 提供了建设性的证据，证明这种方法是可行且有利可图的，但这仅仅是开始。在以更细的粒度定位故障、构建更准确的系统冗余模型以及在识别出错误时向最终用户提供关于究竟出了什么问题的更好解释方面，还有许多工作要做。我们邀请分布式系统研究社区加入进来，共同探索这个新的且有希望的领域。
相关文章
生产环境中的故障注入
为弹性测试辩护
- John Allspaw，Etsy
https://queue.org.cn/detail.cfm?id=2353017
分布式系统的验证
提高系统正确性信心的实践指南
- Caitie McCaffrey
https://queue.org.cn/detail.cfm?id=2889274
注入错误以获得乐趣和利润
错误检测和纠正功能的好坏取决于我们测试它们的能力。
- Steve Chessin，Oracle
https://queue.org.cn/detail.cfm?id=1839574
参考文献
1. Alvaro, P., Andrus, K., Basiri, A., Hochstein, L., Rosenthal, C., Sanden, C. 2016. Automating failure testing research at Internet scale. In Proceedings of the 7th Symposium on Cloud Computing: 17-28.
2. Alvaro, P., Rosen, J., Hellerstein, J. M. 2015. Lineage-driven fault injection. In Proceedings of the SIGMOD International Conference on Management of Data: 331-346.
3. Andrus, K. 2016. Personal communication.
4. Aniszczyk, C. 2012. Distributed systems tracing with Zipkin. Twitter Engineering; https://blog.twitter.com/2012/distributed-systems-tracing-with-zipkin.
5. Barth, D. 2014. Inject failure to make your systems more reliable. DevOps.com; http://devops.com/2014/06/03/inject-failure/.
6. Basiri, A., Behnam, N., de Rooij, R., Hochstein, L., Kosewski, L., Reynolds, J., Rosenthal, C. 2016. Chaos Engineering. IEEE Software 33(3): 35-41.
7. Beyer, B., Jones, C., Petoff, J., Murphy, N. R. 2016. Site Reliability Engineering. O'Reilly.
8. Birrell, A. D., Nelson, B. J. 1984. Implementing remote procedure calls. Transactions on Computer Systems 2(1): 39-59.
9. Chandra, T. D., Hadzilacos, V., Toueg, S. 1996. The weakest failure detector for solving consensus. Journal of the Association for Computing Machinery 43(4): 685-722.
10. Chen, A., Wu, Y., Haeberlen, A., Zhou, W., Loo, B. T. 2016. The good, the bad, and the differences: better network diagnostics with differential provenance. 在 SIGCOMM 会议论文集: 115-128.
11. Chothia, Z., Liagouris, J., McSherry, F., Roscoe, T. 2016. Explaining outputs in modern data analytics. VLDB 基金会论文集 9(12): 1137-1148.
12. Chow, M., Meisner, D., Flinn, J., Peek, D., Wenisch, T. F. 2014. The Mystery Machine: end-to-end performance analysis of large-scale Internet services. 在第 11 届 Usenix 操作系统设计与实现会议论文集: 217-231.
13. Cui, Y., Widom, J., Wiener, J. L. 2000. Tracing the lineage of view data in a warehousing environment. Transactions on Database Systems 25(2): 179-227.
14. Dawson, S., Jahanian, F., Mitton, T. 1996. ORCHESTRA: A Fault Injection Environment for Distributed Systems. 在 第 26 届国际容错计算研讨会论文集。
15. Fischer, M. J., Lynch, N. A., Paterson, M. S. 1985. Impossibility of distributed consensus with one faulty process. Journal of the Association for Computing Machinery 32(2): 374-382; https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf.
16.Fisman, D., Kupferman, O., Lustig, Y. 2008. On verifying fault tolerance of distributed protocols. 在 系统构造与分析工具和算法，计算机科学讲义 4963: 315-331. Springer Verlag.
17. Andrus, K., Gopalani, N., Schmaus, B. 2014. FIT: failure injection testing. Netflix 技术博客; http://techblog.netflix.com/2014/10/fit-failure-injection-testing.html.
18. Gray, J. 1985. Why do computers stop and what can be done about it? Tandem 技术报告 85.7; http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf.
19. Gunawi, H. S., Do, T., Joshi, P., Alvaro, P., Hellerstein, J. M., Arpaci-Dusseau, A. C., Arpaci-Dusseau, R. H., Sen, K., Borthakur, D. 2011. FATE and DESTINI: a framework for cloud recovery testing. 在 第 8 届 Usenix 网络系统设计与实现会议论文集: 238-252; http://db.cs.berkeley.edu/papers/nsdi11-fate-destini.pdf.
20. Holzmann, G. 2003. The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley Professional.
21. Honeycomb. 2016; https://honeycomb.io/.
22. Interlandi, M., Shah, K., Tetali, S. D., Gulzar, M. A., Yoo, S., Kim, M., Millstein, T., Condie, T. 2015. Titian: data provenance support in Spark. VLDB 基金会论文集 9(3): 216-227.
23. Izrailevsky, Y., Tseitlin, A. 2011. The Netflix Simian Army. Netflix 技术博客; http://techblog.netflix.com/2011/07/netflix-simian-army.html.
24. Jepsen. 2016. 分布式系统安全研究; http://jepsen.io/.
25. Jones, N. 2016. 个人交流。
26. Kafka 0.8.0. 2013. Apache; https://kafka.apache.org/08/documentation.html.
27. Kanawati, G. A., Kanawati, N. A., Abraham, J. A. 1995. Ferrari: a flexible software-based fault and error injection system. IEEE Transactions on Computers 44(2): 248-260.
28. Kendall, S. C., Waldo, J., Wollrath, A., Wyant, G. 1994. A note on distributed computing. 技术报告. Sun Microsystems Laboratories.
29. Killian, C. E., Anderson, J. W., Jhala, R., Vahdat, A. 2007. Life, death, and the critical transition: finding liveness bugs in systems code. 在 网络系统设计与实现: 243-256.
30. Kingsbury, K. 2013. Call me maybe: Kafka; http://aphyr.com/posts/293-call-me-maybe-kafka.
31. Kingsbury, K. 2016. 个人交流。
32. Lafeldt, M. 2017. The discipline of Chaos Engineering. Gremlin Inc.; https://blog.gremlininc.com/the-discipline-of-chaos-engineering-e39d2383c459.
33. Lampson, B. W. 1980. Atomic transactions. 在 分布式系统—架构与实现，高级课程: 246-265; https://link.springer.com/chapter/10.1007%2F3-540-10571-9_11.
34. LightStep. 2016; http://lightstep.com/.
35. Marinescu, P. D., Candea, G. 2009. LFI: a practical and general library-level fault injector. 在 IEEE/IFIP 国际可靠系统与网络会议。
36. Matloff, N., Salzman, P. J. 2008. The Art of Debugging with GDB, DDD, and Eclipse. No Starch Press.
37. Meliou, A., Suciu, D. 2012. Tiresias: the database oracle for how-to queries. SIGMOD 国际数据管理会议论文集: 337-348.
38. Microsoft Azure 文档. 2016. 故障分析服务简介; https://azure.microsoft.com/en-us/documentation/articles/service-fabric-testability-overview/.
39. Musuvathi, M., Park, D. Y. W., Chou, A., Engler, D. R., Dill, D. L. 2002. CMC: A pragmatic approach to model checking real code. SIGOPS 操作系统评论。 在 第 5 届操作系统设计与实现研讨会论文集 36(SI): 75-88.
40. Musuvathi, M., Qadeer, S., Ball, T., Basler, G., Nainar, P. A. Neamtiu, I. 2008. Finding and reproducing Heisenbugs in concurrent programs. 在 第 8 届 Usenix 操作系统设计与实现会议论文集: 267-280.
41. Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker, M., Deardeuff, M. 2014. Use of formal methods at Amazon Web Services. 技术报告; http://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf.
42. Olston, C., Reed, B. 2011. Inspector Gadget: a framework for custom monitoring and debugging of distributed data flows. 在 SIGMOD 国际数据管理会议论文集: 1221-1224.
43. OpenTracing. 2016; http://opentracing.io/.
44. Pasquier, T. F. J. -M., Singh, J., Eyers, D. M., Bacon, J. 2015. CamFlow: managed data-sharing for cloud services; https://arxiv.org/pdf/1506.04391.pdf.
45. Patterson, D. A., Gibson, G., Katz, R. H. 1988. A case for redundant arrays of inexpensive disks (RAID). 在 1988 年 SIGMOD 国际数据管理会议论文集: 109-116; http://web.mit.edu/6.033/2015/wwwdocs/papers/Patterson88.pdf.
46. Ramasubramanian, K., Dahlgren, K., Karim, A., Maiya, S., Borland, S., Alvaro, P. 2017. Growing a protocol. 在 第 9 届 Usenix 云计算热点主题研讨会。
47. Reinhold, E. 2016. Rewriting Uber engineering: the opportunities microservices provide. Uber 工程博客; https://eng.uber.com/building-tincup/.
48. Saltzer, J. H., Reed, D. P., Clark, D. D. 1984. End-to-end arguments in system design. Transactions on Computing Systems 2(4): 277-288.
49. Sandberg, R. 1986. The Sun network file system: design, implementation and experience. 技术报告, Sun Microsystems. 在 1986 年夏季 Usenix 技术会议与展览论文集。
50. Shkuro, Y. 2017. Jaeger: Uber's distributed tracing system. Uber 工程博客; https://uber.github.io/jaeger/.
51. Sigelman, B. H., Barroso, L. A., Burrows, M., Stephenson, P., Plakal, M., Beaver, D., Jaspan, S., Shanbhag, C. 2010. Dapper, a large-scale distributed systems tracing infrastructure. 技术报告. Google 研究; https://research.google.com/pubs/pub36356.html.
52. Shenoy, A. 2016. A deep dive into Simoorg: our open source failure induction framework. Linkedin 工程博客; https://engineering.linkedin.com/blog/2016/03/deep-dive-Simoorg-open-source-failure-induction-framework.
53. Yang, J., Chen, T., Wu, M., Xu, Z., Liu, X., Lin, H., Yang, M., Long, F., Zhang, L., Zhou, L. 2009. MODIST: Transparent model checking of unmodifed distributed systems. 在 第 6 届 Usenix 网络系统设计与实现研讨会论文集: 213-228.
54. Yu, Y., Manolios, P., Lamport, L. 1999. Model checking TLA+ specifcations. 在 第 10 届 IFIP WG 10.5 高级研究工作会议关于正确硬件设计和验证方法 (CHARME 99) 论文集: 54-66.
55. Zhao, X., Zhang, Y., Lion, D., Ullah, M. F., Luo, Y., Yuan, D., Stumm, M. 2014. Lprof: a non-intrusive request flow profiler for distributed systems. 在 第 11 届 Usenix 操作系统设计与实现会议论文集: 629-644.
Peter Alvaro 是加州大学圣克鲁兹分校的计算机科学助理教授，他在那里领导着 Disorderly Labs 研究小组 (disorderlylabs.github.io)。他的研究重点是使用以数据为中心的语言和分析技术来构建和推理数据密集型分布式系统，以使其具有可扩展性、可预测性，并能鲁棒地应对大规模分布式系统中普遍存在的故障和不确定性。他在加州大学伯克利分校获得博士学位，师从 Joseph M. Hellerstein。他是 NSF CAREER 奖的获得者。
Severine Tymon 是一名技术作家，曾为企业和开源软件的内部和外部用户编写文档。她曾在 Pivotal、Microsoft、CNET、VMware 和 Oracle 等行业领导者公司工作过。她的特殊兴趣包括研究和记录分布式系统中的容错。Tymon 在加州大学伯克利分校获得了文学和创意写作学士学位。
版权 © 2017 年归所有者/作者所有。出版权已授权给 。
最初发表于 Queue 杂志第 15 卷，第 5 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Phil Vachon - 王国钥匙
一次不幸的手指误操作引发了当前的危机：客户不小心删除了签署新固件更新所需的私钥。他们有一些令人兴奋的新功能要发布，以及通常的一系列可靠性改进。他们的客户越来越不耐烦，但当被问及发布日期时，我的客户不得不拖延。他们怎么能想出一个有意义的日期呢？他们已经失去了签署新固件发布的能力。
Pat Helland, Simon Weaver, Ed Harris - 大到不能倒
Web 规模的基础设施意味着大量的服务器协同工作，通常是成千上万台服务器朝着同一个目标努力。如何管理这些环境的复杂性？如何引入通用性和简单性？
Steve Chessin - 注入错误以获得乐趣和利润
一个不幸的事实是，任何带有活动部件的东西最终都会磨损和发生故障，电子电路也不例外。当然，在这种情况下，活动部件是电子。除了电迁移（移动的电子逐渐将金属原子推出位置，导致导线变细，从而增加其电阻并最终产生开路）和树枝状生长（相邻导线之间的电压差导致位移的金属原子相互迁移，就像磁铁会相互吸引一样，最终导致短路）的磨损机制外，电子电路也容易受到背景辐射的影响。
Michael W. Shapiro - 现代操作系统中的自愈
每天驾驶连接旧金山和门洛帕克的 101 公路，广告牌上的笑脸微笑地向我保证，2004 年的计算机世界一切安好。他们告诉我，网络和服务器可以自我防御、自我诊断、自我修复，甚至有足够的计算能力从所有这些自省中腾出来执行其所有者分配的任务。
© 保留所有权利。