ACM通信
实践
从失败测试中抽象化天才
信贷:Vitezslav Valka
云应用程序的异构性、复杂性和规模使得验证其容错特性具有挑战性。公司正在从正式的方法转向大规模的测试，在这种测试中，组件被故意妥协，以识别软件的弱点。例如，Jepsen等技术将故障注入测试应用于分布式数据存储，而混沌工程在生产系统上执行故障注入实验，通常是在实时流量上。这两种方法都引起了工业界和学术界的注意。
不幸的是，基础设施可以测试的不同故障组合的搜索空间是难以处理的。现有的故障测试解决方案需要熟练和聪明的用户提供要注入的故障。这些超级用户，被称为混沌工程师和杰普森专家，必须研究被测试的系统，观察系统执行，然后制定关于哪些故障最有可能暴露真正的系统设计缺陷的假设。这种方法从根本上来说是不可扩展和无原则的。它依赖于超级用户解释分布式系统如何利用冗余来掩盖或改善故障的能力，以及识别冗余不足之处的能力——换句话说，就是人类的天才。
本文向分布式系统研究社区发出号召，以提高容错测试的技术水平。普通用户需要能够自动选择要注入的定制错误的工具。我们推测超级用户选择实验以观察执行、构建系统冗余模型和识别模型中的弱点的过程可以在软件中有效地建模。文章描述了验证这一猜想的原型，展示了来自实验室和实地的早期结果，并确定了可以使这一设想成为现实的新的研究方向。
未来是无序的
为用户和客户提供“永远在线”的体验意味着分布式软件必须这样做容错也就是说，必须编写它来预测、检测、屏蔽或妥善处理故障事件(如硬件故障和网络分区)的影响。编写容错软件，无论是涉及少数物理机器交互的分布式数据管理系统，还是涉及数万台计算机合作的Web应用程序，都是极其困难的。当验证和程序分析的艺术状态在学术界继续发展的时候，这个行业正在向相反的方向发展:远离形式化的方法(然而，有一些值得注意的例外，41)以及将测试与故障注入相结合的方法。
在这里，我们将描述这一趋势的潜在原因，为什么它迄今为止是成功的，以及为什么它在当前的实践中注定要失败。
旧神。古老的神话:把它留给专家吧。曾几何时，分布式系统研究人员和实践者相信，解决容错问题的责任可以由一小部分专家承担。用于故障检测、恢复、可靠通信、共识和复制的协议可以一次性实现，并隐藏在库中，供外行人使用。
这是一个合理的梦想。毕竟，抽象是克服计算机科学复杂性的最佳工具，从不可靠的组件组成可靠的系统是经典系统设计的基础。33可靠性技术，例如过程对18和RAID45演示在某些情况下，可以在系统的最低级别处理部分故障，并成功地对应用程序屏蔽。
不幸的是，这些方法依赖于故障检测。完美的故障检测器在分布式系统中是不可能实现的，9，15在这种情况下，拖延和失败是无法区分的。试图掩盖分布式系统(例如，远程过程调用)中部分失败所引起的基本不确定性8)和NFS(网络文件系统)49)遇到了(众所周知的)困难。尽管人们普遍认为这些尝试都是失败的抽象，28在缺乏更好的抽象的情况下，人们继续依赖于它们，这让开发人员、操作人员和用户感到惊愕。
在一个分布式系统中，即一个松散耦合的组件通过消息交互的系统中，一个组件的故障只会表现为没有消息。检测消息缺失的唯一方法是通过超时，这是一种模棱两可的信号，意味着消息永远不会来，或者只是还没有来。超时是一个端到端的问题28，48这最终必须由应用程序来管理。因此，分布式系统中的部分故障会使堆栈膨胀，并挫败任何抽象尝试。
虽然验证和程序分析的技术水平在学术界继续发展，但业界正在朝着相反的方向发展:从形式化方法转向将测试与故障注入结合起来的方法。
老一代卫道士。现代神话:正式验证的分布式组件。如果我们不能依靠天才来隐藏部分失败的幽灵，那么下一个最好的希望就是带着工具直面它。直到最近，我们中的许多人(尤其是学者)都在寻找像模型检查这样的正式方法16，20.，29，39，40，53，54帮助“凡人”程序员编写分布式代码，尽管在分布式执行中存在普遍的不确定性，但仍能保持其保证。穷尽地搜索大型系统的状态空间是不合理的(例如，人们不能对Netflix进行模型检查)，但希望模块化和组合(征服复杂性的次佳工具)能够发挥作用。如果单个分布式组件能够被正式验证，并以一种保持其保证的方式组合成系统，那么就可以通过局部容错的组合来获得全局容错。
不幸的是，这也是一个白日梦。大多数模型检查器都需要正式的规范;大多数现实世界的系统都没有(或者从设计阶段开始，许多版本之前就没有)。软件模型检查器和其他程序分析工具需要所研究系统的源代码。源代码的可访问性也是一个越来越薄弱的假设。Jepsen等工具针对的许多数据存储都是闭源的;大型体系结构，虽然通常是由开源组件构建的，但也越来越多通晓多国语言(用多种语言写成)。
最后，即使您假设规范或源代码是可用的，诸如模型检查之类的技术也不是确保应用程序容错的可行策略，因为正如前面提到的，在超时的上下文中，容错本身是一种端到端属性，在组合下不一定保持。即使你足够幸运，用独立验证的组件构建了一个系统，也不能遵循系统的容错能力，因为你可能在连接组件的胶水上犯了一个严重的错误。
的先锋。新兴的风气:YOLO。现代分布式系统太大、太异构、太动态，这些经典的软件质量方法无法生根。因此，从业者越来越依赖于基于弹性的技术测试而且故障注入。6，14，19，23，27，35这些“黑箱”方法(干扰和观察整个系统，而不是它的组件)(可以说)更适合测试端到端属性，例如容错。而不是从理解系统如何在内部，系统的测试人员从外，建立起它在压力下正常工作的信心。
这一领域最近出现了两大巨头:Chaos Engineering6和Jepsen测试。24混沌工程是一种主动干扰生产系统以增加网站整体弹性的实践，由Netflix首创，6但从那时起，52微软,38乳房,47和PagerDuty5开发了基于混沌的基础设施。Jepsen在未修改的分布式数据管理系统上执行黑箱测试和故障注入，以查找违反正确性的情况(例如，显示执行是不可线性化的反例)。
这两种方法都是实用主义和经验主义的。每个人都建立了对系统在故障下如何运行的理解运行系统观察它的行为。这两种方法都提供了一种现收现付的弹性方法:集成的初始成本很低，并且执行的实验越多，被测试系统的健壮性的信心就越高。因为这些方法直接丰富了测试中现有的最佳实践，并充分理解了错误注入技术，所以很容易采用。最后，可能也是最重要的，这两种方法都被证明可以有效地识别错误。
不幸的是，这两种技术都有一个致命的缺陷:它们是需要极复杂的操作符。混沌工程师是站点可靠性工程师的一个高度专业化的子类。为了设计定制的故障注入策略，混沌工程师通常会与不同的服务团队会面，以建立对各种组件及其交互特性的理解。然后，混沌工程师针对那些看起来可能具有潜在容错弱点的服务和交互。这种方法不仅难以扩展，因为它必须对每一个新的服务组合进行重复，而且它的关键货币——被研究系统的心理模型隐藏在人的大脑中。这些观点让人联想到工业中一个更大(也更令人担忧)的趋势——可靠性——牧师身份，7完成图标(仪表盘)和仪式(剧本)。
原则上，Jepsen是一个任何人都可以使用的框架，但据我们所知，迄今为止由Jepsen发现的所有报告bug都是由它的发明者Kyle Kingsbury发现的，他目前经营着一家“分布式系统安全研究”咨询公司。24在存储系统上应用Jepsen需要超级用户仔细阅读系统文档、生成工作负载并观察被测系统的外部可见行为。然后由操作员从大量的“敌人”组合空间中做出选择，包括机器崩溃和网络分区，这些故障计划很可能导致系统返回错误的响应。
对于那些需要跟上软件发展的系统来说，一个人在循环中是死亡之吻。人类的注意力应该始终集中在计算机无法完成的任务上!此外，混沌和杰普森测试所需的专家是昂贵和罕见的。在这里，我们将展示如何将天才从失败测试过程中抽象出来。
我们不需要另一个英雄
快速变化的关于我们对分布式系统内部可见性的假设已经使许多(如果不是所有的话)经典的软件质量方法过时了，而新兴的“基于混沌的”方法是脆弱的，不可扩展的，因为它们的“天才在循环”的要求。
我们通过观察环境的变化如何加速了经过时间考验的弹性技术的消亡，来展示我们对自动故障测试的看法。我们认为，让专家们自动脱离故障测试循环的最好方法是模仿他们在软件中的最佳实践，并展示复杂的可观察性基础设施的出现是如何使这成为可能的。
订单正在迅速消失。”对于大规模的分布式系统，传统的软件质量方法的三个基本假设正迅速消失在后视镜中。第一个被抛弃的信念是，你可以依靠专家来解决这个领域中最困难的问题。第二种假设是系统的正式规范是可用的。最后，任何需要源代码可用的程序分析(广义的)都必须被排除。这些假设的削弱有助于解释从经典的学术方法转向之前描述的黑箱方法的转变。
在这个新的现实中，理解复杂系统的行为有什么希望呢?幸运的是，从内部理解分布式系统比以往任何时候都要困难，这一事实导致了工具的快速进化，使我们能够从内部理解它们在外面。Callgraph日志首先由谷歌描述;51类似的系统也在推特上使用，4Netflix,1和乳房,50这项技术已经标准化了。43可以合理地假设，一个基于微服务的现代互联网企业已经将其系统配置为收集调用图痕迹的工具。最近出现了一些专注于可观察性的初创公司。21，34同时，数据处理系统的来源收集技术11，22，42正在变得成熟，操作系统级的来源工具也是如此。44最近的工作12，55曾尝试从原始日志中推断分布式计算的因果关系和通信结构，甚至对未使用仪器的系统也能提供高水平的结果解释。
关于测试分布式系统。就像他们提到的，Chaos Monkey非常棒，我也强烈建议让Kyle去做Jepsen测试。
评论员HackerRumor
远离专家。虽然这句话只是坊间传闻，但很难想象还有比这更好的例子来说明当前技术状态的根本不可扩展性。一个人不可能跟上分布式系统实现的爆炸式增长。如果我们能让人类脱离这个关键的循环，我们必须这样做;如果我们做不到，我们也许应该认输。
理解如何自动化任何流程的第一步是理解我们想要抽象掉的人的组成部分。混沌工程师和杰普森超级用户如何在实践中应用他们独特的天赋?下面是这两种方法共有的三步配方。
步骤1:观察系统的运行情况。混沌和杰普森过程中的人为因素始于广义的原则性观察。
混沌工程师在研究了与给定交互类相关的服务的外部API后，将与工程团队会面，以更好地理解单个服务的实现细节。25为了理解服务之间的高级交互，工程师将在跟踪存储库中仔细研究调用图跟踪。3.
Jepsen超级用户通常首先检查产品文档，以确定系统应该支持的保证，并了解它实现这些保证的机制。在此基础上，超级用户基于与系统外部API的交互构建系统行为的模型。由于所研究的系统通常是数据管理和存储，这些交互涉及到生成读和写的历史。31
理解分布式系统中可能出现的问题的第一步是观察事情的走向:在常见情况下观察系统。
步骤2。建立一个系统如何容忍错误的心理模型。这两种方法的共同下一步都是最微妙和主观的。一旦有了分布式系统行为的心理模型(至少在一般情况下)，如何使用它来帮助选择要注入的适当错误呢?在这一点上，我们不得不进行猜测:请容忍我们。
容错就是冗余。给定一些固定的错误集合，如果系统在发生这些错误的所有执行中都正确运行，那么我们就说系统是“容错”的。“正确操作”是什么意思?正确性是一个系统特定的概念，但是，广义地说，它是用两者的属性来表示的维护在整个系统执行过程中(例如，系统不变量或安全属性)或建立了在执行期间(例如，活动属性)。大多数与我们交互的分布式系统，尽管它们的执行可能是无界的，但是提供了有限的、有界的交互结果。例如，一个广播协议可能在响应式系统中“永远”运行，但是每个广播都传递到所有团队成员构成了成功的执行。
通过以这种方式观察分布式系统，我们可以修改定义:一个系统是容错的，如果它提供了足够的机制来实现成功的结果，尽管有给定的错误类型。
步骤3:针对façade中的弱点制定实验。如果我们能够理解系统获得良好结果的所有方式，我们就可以理解系统能够容忍哪些错误(或者对哪些错误敏感)。我们断言(不管他们是否意识到!)混沌工程师和杰普森超级用户在一个系统一个系统的基础上决定注入哪些故障的过程，正是使用了这种推理。一个目标实验应该练习一个排除的错误的组合所有对预期结果的支持程度。
结果证明，进行实验是比较容易的部分。故障注入基础设施与可观察性基础设施一样，近年来发展迅速。与随机的、粗粒度的分布式故障注入方法(如Chaos Monkey)相比，23方法，如FIT(失效注入测试)17和小精灵32允许在单个请求的粒度上高精度地注入错误。
步骤4。利润!这个过程可以有效地自动化。前面描述的复杂的跟踪工具的出现使得构建冗余模型比以往任何时候都更容易，甚至从黑箱系统的执行开始。故障注入基础设施的快速发展使得在大规模系统上测试故障假设比以往任何时候都更容易。图1说明这里描述的自动化如何在现有的可观察性基础设施和故障注入基础设施之间巧妙地匹配，使用前者，维护系统冗余模型，并使用它参数化后者。系统结果和故障注入基础设施的解释已经可用。在目前的技术状态下，将它们组合在一起的拼图(模型的冗余)是一个手工过程。LDFI(我们将对此进行解释)表明该组件的自动化是可能的。
图1。我们对自动故障测试的愿景。
《来自过去的爆炸
在之前的工作中，我们介绍了一个称为LDFI(谱系驱动的故障注入)的错误查找工具。2LDFI使用在模拟分布式执行过程中收集的数据来源进行构建推导过程图对于系统的结果。这些图的功能与前面描述的系统冗余模型非常相似。LDFI然后将推导图转换为布尔公式，其令人满意的分配对应于使结果的所有推导无效的错误组合。针对这些错误的实验将暴露一个错误(即，预期的结果没有发生)或揭示额外的派生(例如，在超时后，系统故障转移到备份)，这些派生可用于丰富模型并约束未来的解决方案。
故障注入基础设施的快速发展使得在大规模系统上测试故障假设比以往任何时候都更容易。
LDFI的核心是重新应用来自数据管理系统的易于理解的技术，将容错视为物化视图维护问题。2，13它将分布式系统建模为查询，将其预期结果建模为查询结果，并将关键事实(如“副本”)建模一个准时起床t以及“节点之间有连接性。X而且Y在时间间隔我.．.j作为基本事实。然后它可以询问如何查询:37对基本数据的哪些更改将导致视图中的派生数据发生更改?根据当前模型，该查询的答案是可能使预期结果无效的错误。
这个想法看起来很牵强，但是LDFI方法显示了很大的希望。最初的原型演示了该方法在协议级别的有效性，可以识别复制、广播和提交协议中的错误。2，46值得注意的是，LDFI在Kafka分布式日志使用的复制协议中复制了一个错误26这是金斯伯里首先(人工)发现的。30.后来的LDFI迭代部署在Netflix上，1在哪里(很像插图图1)它被实现为一个微服务，它使用调用图存储库服务的跟踪，并为故障注入服务提供输入。自部署以来，LDFI已经在Netflix面向用户的应用程序中发现了11个关键bug。1
来自未来的谣言
先前提出的研究只是冰山一角。要实现对分布式系统进行完全自动化的故障测试的愿景，仍然需要进行大量的工作。在这里，我们强调了那些显示出希望并确定了有助于实现我们愿景的新方向的新兴研究。
不要过度考虑错误注入。在分布式系统的弹性测试上下文中，试图列举并忠实地模拟每一种可能的故障是一种诱人但令人分心的方法。理解所有的问题原因的错误并不直接与目标相关，目标是确保用于检测和减轻错误的代码(及其配置)按预期执行。
考虑图2:左边的图表显示了基于微服务的架构;箭头表示由客户端请求生成的调用。右边放大了一对相互作用的服务。调用方服务中的阴影框表示容错逻辑，该逻辑用于检测和处理被调用方的错误。失败测试针对的是这个逻辑中的错误。此错误搜索中的容错逻辑表示为调用者服务中的阴影框，而注入的错误影响被调用者。
图2。错误注入和容错代码。
常见的效果在所有的错误中，从调用者的角度来看，是显式的错误返回、损坏的响应和(可能是无限的)延迟。在这些表现中，前两个可以用单元测试进行充分的测试。最后一种方法难以测试，导致代码分支很少执行。如果我们注入只有延迟，并且只在组件边界上，我们推测我们可以解决大多数与容错相关的错误。
解释无处不在。如果我们能对系统结果提供更好的解释，我们就能建立更好的冗余模型。不幸的是，像LDFI这样的系统进入的障碍是软件开发人员和运营商不愿意将他们的系统用于跟踪或来源收集。幸运的是，操作系统级的来源收集技术已经很成熟，可以应用于未仪器化的系统。
此外，容器革命使得在单个管理程序中模拟黑盒软件的分布式执行比以往任何时候都更容易。我们正在积极探索从未修改的分布式软件中收集系统调用级来源，以便选择定制的定制故障注入计划。这样做需要从低级跟踪推断应用程序级的因果结构，并确定适当的因果结构减少点在观察到的执行中，最后将执行与错误注入操作同步。
我们还对从更有噪声的信号(如原始日志)中推断高层次解释的可能性感兴趣。这将允许我们放松这样的假设，即所研究的系统已被用于收集执行痕迹。虽然这是一个困难的问题，工作如神秘机器12在facebook上开发的软件显示出了巨大的前景。
更好的模型。LDFI系统使用派生图表示系统冗余，并将识别可能bug的任务视为实物化视图维护问题。因此，LDFI能够从数据管理系统研究的历史中开发出易于理解的理论和机制。但这只是表示系统如何提供替代计算以实现预期结果的众多方法之一。
LDFI方法的一个缺点是它依赖于决定论的假设。特别地，它假设，如果它已经见证了在特定偶然性(即给定特定输入并存在特定错误)下产生成功结果的计算，那么在该偶然性下的任何未来计算都将产生相同的结果。也就是说，它忽略了时间的不确定性，这是分布式系统的基础。为系统冗余建模的一个更合适的方法是接受(而不是抽象掉)这种不确定性。
分布式系统本质上是概率性的，并且可以说是更好的概率化建模。未来的工作方向包括系统冗余的概率表示，并探索如何利用这种表示来指导故障实验的搜索。我们鼓励研究界加入探索系统冗余的替代内部表示。
把解释翻过来。在数据库研究中，大多数关于数据来源的经典工作都集中在与人机交互相关的方面。解释为什么一个查询返回一个特定的结果可以用来调试查询和初始数据库给定一个意外的结果，可以对查询或数据库做什么改变来修复它?相比之下，在我们设想的这类系统中(特别是对于LDFI)，解释是推理器内部语言的一部分，用于构建冗余模型，以便驱动通过故障进行搜索。
容器革命使得在单个管理程序中模拟黑盒软件的分布式执行比以往任何时候都更容易。
理想情况下，解释应该在两个世界都发挥作用。毕竟，当像LDFI这样的错误查找工具识别出正确性属性的反例时，程序员的工作才刚刚开始——现在他们必须承担繁重的分布式调试工作。围绕调试的工具没有跟上分布式系统开发的爆炸性步伐。我们继续使用为单一站点、统一内存和单一时钟设计的工具。虽然我们不确定理想的分布式调试器应该是什么样子，但我们很确定它不像GDB (GNU项目调试器)。36LDFI使用的派生图展示了来源如何在调试中发挥作用，它提供了系统如何达到糟糕状态的简明、可视化解释。
这方面的研究可以进一步推进。要理解LDFI中错误的根本原因，操作员必须查看好的和坏的执行的来源图，然后检查它们的不同之处。直观地说，如果你可以抽象地说减去从对好的结果的解释中(假设不完全)对坏结果的解释，10那么，差异的根本原因很可能就在差异的“边界”附近。
结论
用于确定分布式系统是否具有容错能力的技术正在发生巨大变化。错误注入方法的出现，如混沌工程和Jepsen，是对专家程序员、正式规范和统一源代码可用性的侵蚀的反应。尽管这些新方法很有前途，但它们依赖于超级用户，由超级用户决定注入哪些错误。
为了解决这个关键的缺点，我们提出了一种建模的方法，并最终将这些超级用户执行的过程自动化。实现这一愿景的支持技术是快速改进的可观察性和故障注入基础设施，它们在行业中变得越来越普遍。虽然LDFI提供了建设性的证据，证明这种方法是可行的和有利可图的，但这只是一个开始。在更精细地定位故障、构建更精确的系统冗余模型以及为最终用户提供更好的解释方面，还有许多工作要做到底哪里出了问题当发现错误时。邀请分布式系统研究社区加入探索这个新的和有前途的领域。
相关文章
在queue.acm.org
生产故障注入
约翰Allspaw
http://queue.acm.org/detail.cfm?id=2353017
分布式系统的验证
Caitie麦
http://queue.acm.org/detail.cfm?id=2889274
为乐趣和利益注入错误
史蒂夫Chessin
http://queue.acm.org/detail.cfm?id=1839574
参考文献
1.Alvaro, P.等人。互联网规模的自动故障测试研究。在七人会议记录thACM云计算研讨会(2016), 1728。
2.杨文华，杨文华，杨文华，杨文华。地层驱动的断层注入。在ACM SIGMOD数据管理国际会议论文集(2015), 331346。
4.Aniszczyk, C.分布式系统跟踪与Zipkin。Twitter工程;https://blog.twitter.com/2012/distributed-systems-tracing-with-zipkin．
5.巴思，d，注入故障，让你的系统更可靠。DevOps.com;http://devops.com/2014/06/03/inject-failure/．
6.Basiri, A.等人。混沌工程学。IEEE软件33， 3(2016)， 3541。
7.拜尔，B.，琼斯，C.，皮托夫，J.，墨菲，n.r网站可靠性工程。O ' reilly, 2016年。
8.波瑞尔，助理检察官，尼尔森，b。j。正在执行远程程序调用。ACM反式。计算机系统2， 1(1984)， 3959。
9.钱德拉，t.d.， Hadzilacos, V.， Toueg, S.解决共识最弱的失败检测器。J.ACM 43， 4(1996)， 685722。
10.Chen, A.等。优点、缺点和区别:具有不同来源的更好的网络诊断。在ACM SIGCOMM会议论文集(2016), 115128。
11.Chothia, Z.， Liagouris, J.， McSherry, F.， Roscoe, T.解释现代数据分析的输出。在VLDB基金会议记录， 12(2016): 11371148。
12.周，等人。神秘机器:大规模互联网服务的端到端性能分析。在十一届会议记录th操作系统设计与实现Usenix会议(2014), 217231。
13.崔勇，Widom, J. Wiener, J. l .在仓库环境中跟踪视图数据的沿袭。ACM反式。数据库系统25， 2(2000)， 179227。
14.道森，S, Jahanian, F，米顿，T. ORCHESTRA:分布式系统的故障注入环境。在二十六届会议的议事录th容错计算国际研讨会,(1996)。
15.费舍尔，m.j.，林奇，n.a.，帕特森，M.S.一个错误过程的分布式共识的不可能性。j . ACM 32， 2 (1985): 374382;https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf．
16.D.菲斯曼，O.库普弗曼，Y.拉斯蒂格。分布式协议的容错验证。在构建和分析系统的工具和算法，计算机科学课堂讲稿4963，施普林格Verlag(2008)。315331.
17.Gopalani, N.， Andrus, K.， Schmaus, B. FIT:失效注入测试。Netflix科技博客;http://techblog.netflix.com/2014/10/fit-failure-injection-testing.html．
18.为什么电脑会停止工作，我们能做些什么?串联技术报告85.7 (1985);http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf．
19.Gunawi, H.S.等人。FATE和DESTINI:用于云恢复测试的框架。在八人会议记录th网络系统设计与实现Usenix会议(2011), 238252;http://db.cs.berkeley.edu/papers/nsdi11-fate-destini.pdf．
20.Holzmann G。SPIN模型检查器:入门和参考手册。addison - wesley专业,2003年。
21.蜂窝。2016;https://honeycomb.io/．
22.Interlandi, M.等。Titian: Spark中的数据来源支持。在VLDB基金会议记录， 33(2015)， 216227。
23.伊兹拉伊列夫斯基，Y.， Tseitlin, A. Netflix的猿人军队。Netflix科技博客;http://techblog.netflix.com/2011/07/netflix-simian-army.html．
24.Jepsen。分布式系统安全研究，2016;http://jepsen.io/．
26.卡夫卡0.8.0。Apache, 2013;https://kafka.apache.org/08/documentation.html．
27.卡纳瓦提，g.a.，卡纳瓦提，n.a.，亚伯拉罕，J.A.法拉利:一个灵活的基于软件的错误和错误注入系统。IEEE反式。电脑44， 2(1995): 248260。
28.Kendall, s.c.， Waldo, J.， Wollrath, A.， Wyant, G.关于分布式计算的说明。技术报告,1994年。太阳微系统公司实验室。
29.基利安，c.e.，安德森，j.w.， Jhala, R.， Vahdat, A.生，死，和关键的转变:在系统代码中寻找活的bug。网络化系统的设计与实现、(2007);243256.
30.也许可以叫我:卡夫卡，2013年;http://aphyr.com/posts/293-call-me-maybe-kafka．
32.混沌工程的学科。小鬼Inc ., 2017;https://blog.gremlininc.com/the-discipline-of-chaos-engineering-e39d2383c459．
33.兰普森，B.W.原子交易。在分布式系统体系结构与实现高级课程:(1980), 246265;https://link.springer.com/chapter/10.1007%2F3-540-10571-9_11．
34.LightStep。2016;http://lightstep.com/．
35.Marinescu, p.d.， Candea, G. LFI:一种实用的通用库级故障注入器。在IEEE/IFIP可靠系统与网络国际会议(2009)。
36.N.马特洛夫，P.J.萨尔茨曼使用GDB、DDD和Eclipse进行调试的艺术。无淀粉出版社，2008年。
37.Meliou, A. Suciu, D.泰瑞西亚斯:如何查询的数据库oracle。ACM SIGMOD数据管理国际会议论文集(2012), 337348。
38.微软Azure文档。故障分析服务导论，2016;https://azure.microsoft.com/en-us/documentation/articles/service-fabric-testability-overview/．
39.Musuvathi等人。CMC:一种实用的模型检查实际代码的方法。ACM SIGOPS操作系统回顾。在五人会议记录th操作系统设计与实现研讨会(2002), 7588。
40.Musuvathi等人。在并发程序中查找并复制heisenbug。在八人会议记录th操作系统设计与实现Usenix会议(2008), 267280。
41.纽科姆等人。在Amazon Web Services中使用形式化方法。技术报告,2014;http://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf．
42.检查器Gadget:用于自定义监视和调试分布式数据流的框架。在ACM SIGMOD数据管理国际会议论文集(2011), 12211224。
43.OpenTracing。2016;http://opentracing.io/．
44.Pasquier, T.F.人类。，Singh, J., Eyers, D.M., Bacon, J. CamFlow: Managed data-sharing for cloud services, 2015;https://arxiv.org/pdf/1506.04391.pdf．
45.Patterson, D.A, Gibson, G, Katz, R.H.廉价磁盘(RAID)的冗余阵列案例。在1988年ACM SIGMOD数据管理国际会议论文集, 109116;http://web.mit.edu/6.033/2015/wwwdocs/papers/Patterson88.pdf．
46.Ramasubramanian, K.等。不断增长的一个协议。在会议记录th云计算热门话题Usenix研讨会(2017)。
47.重写Uber工程:微服务提供的机会。超级工程,2016;https://eng.uber.com/building-tincup/．
48.萨尔茨，里德，d.p.，克拉克，D.D.系统设计中的端到端论证。ACM反式。计算系统2， 4(1984): 277288。
49.Sun网络文件系统:设计、实现和体验。技术报告，太阳微系统公司。在1986年夏季Usenix技术会议和展览的会议记录。
50.Shkuro, Y. Jaeger: Uber的分布式跟踪系统。超级工程,2017;https://uber.github.io/jaeger/．
51.西格尔曼，B.H.等。大规模分布式系统跟踪基础设施。技术报告。谷歌研究，2010;https://research.google.com/pubs/pub36356.html．
52.Shenoy, A.对Simoorg的深入研究:我们的开源故障诱导框架。Linkedin工程,2016;https://engineering.linkedin.com/blog/2016/03/deep-dive-Simoorg-open-source-failure-induction-framework．
53.杨杰等。周丽丽，周丽丽。MODIST:未修改分布式系统的透明模型检查。在六人会议记录th网络系统设计与实现Usenix研讨会(2009), 213228。
54.Yu, Y, Manolios, P, Lamport, L.模型检查TLA+规范。在十人会议记录thIFIP WG 10.5正确硬件设计和验证方法的高级研究工作会议(1999), 5466。
55.赵，x，等。Lprof:分布式系统的非侵入式请求流分析器。在十一届会议记录th操作系统设计与实现Usenix会议(2014), 629644。
数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.
没有发现记录