Armando Fox认为，如果你不能构建防故障系统，你至少应该构建能够快速恢复的系统，这样服务故障就可以忽略不计了。与加州大学伯克利分校的一名研究助理可靠、自适应分布式系统实验室(RAD实验室),福克斯是一个领导的联合伯克利/斯坦福面向计算(ROC)项目调查的技术构建可靠的互联网服务,强调“从失败中恢复而不是失败的避免。”
福克斯自所带有的ROC教训转发到RAD实验室，这是在2005年推出以$ 750万的资金，从谷歌，微软和Sun联盟的成员包括IBM，惠普，北电网络，NTT-MCL和Oracle。该RAD实验室的重点是困扰大型互联网为基础的企业，因为环境代表一个极端的问题，但福克斯说吸取的教训应最终涓滴到企业用户。有个足球雷竞技app主编约翰·迪克斯请福克斯解释这一愿景。
让我们先回顾一下ROC。这到底是怎么回事?
ROC项目的哲学就是事情会发生。尽管我们尽了最大努力来设计和调试这些复杂的Internet系统，但它们不可避免地以我们没有预料到的方式失败。硬件并不完美。软件错误。即使是像Oracle这样经过了很好的测试的软件，你也会在它上市后发现漏洞。你知道，人类负责运行这些系统，有时他们会犯错误。
所以ROC项目理念是，让我们接受这些事情将要发生，并开始有关快速恢复设计，而不是设计来避免失败，这是不是一个真正的现实目标的思考。以提高系统的可用性的方法之一是永远不会失败。但是，以提高另一种方法是使故障恢复如此之快，可用性的贡献可以忽略不计。
为什么您一开始就假定您永远不能构建不会失败的系统?
因为我们不认为我们有足够的智慧来对抗过去60年的计算机科学史。有很多人致力于通过正确性和其他技术来改进系统和减少错误。这是一件好事。但到目前为止，尽管我们尽了最大的努力，但我想不出有哪一个计算机系统在被设计出来的时候没有发现任何漏洞。
所以，我想我们可以采取这样的立场，无论如何，在未来这一切都会改变。但我们已经说了几十年了。这并不是说我们愚蠢，对吧?我的意思是，在性能，存储密度，网络通信速度方面，看看我们在30年里所能做到的。然后将其与我们在可靠性方面所能做的进行比较。这些系统的复杂性已经到了任何一个人都很难理解其中一个系统是如何工作的地步。
另外，市场现实就是这样，并不是说你要完善整个系统，部署它，然后就不管它了。系统必须进化。添加新特性，获得更多用户，扩大系统规模。所有这些过程都与可靠性背道而驰。最可靠的软件是运行航天飞机的软件，问问那些人他们是如何对软件进行修改的。在修改一行代码之前，他们必须编写数千页的文档和数百小时的设计审查。所以他们有超级可靠的软件，但这是有代价的。
而现实是大多数互联网公司无法支付这个价格。在决定是否推出新功能之前，亚马逊不可能召开数百小时的设计会议。所以ROC项目基本上是说，看，我们需要找到一种方法来处理这个问题在商业现实的背景下。因为，是的，这些系统发展得很快。是的，这不利于可靠性。但是创新正是这些系统价值的来源。作为学者，我们不会提出一个解决这个问题的方法说，你们可以修复你们的系统，但要以快速创新为代价。
这就是ROC的哲学。实际上，我们在确定一些事情上取得了相当大的进展。我们确定了一些特定的技术，可以构建到软件系统中，帮助从某些类型的常见问题中恢复，非常快。事实上，它是如此之快，以至于有时你甚至可能没有注意到它，除了性能上的一个小波动。这是一个重要的发现。而且，这些想法开始在一些商业产品中找到它们的方式。
举个例子。
当然。我们的工作就一个念头被称为微重启。当你有一个奇怪的，意外的，不可恢复的错误，不知道还有什么是错的，你重新启动计算机。有时候，这是不足以解决问题。但是，重新启动需要很长的时间。因此，考虑到应用程序已经发展到使用像企业Java Beans（EJB）这个组件化架构，我们的想法就是将同时重新启动的部件数量少的这个概念。因此，而不是重新启动整个EJB服务器，这可能需要几分钟，你的微重启只是似乎已经失败的EJB组件。所以，你重置是失败的事情，但你这样做的成本低得多，因为你只是做给你认为是问题的实际来源的EJB组件。
你已经看到这种做法回升？
这种做法的变体被放进一些商业产品。虽然我不知道我被允许具体哪些说。
微重启是中华民国七个核心研究领域之一，对吧?还有其他的行为吗?
是的。有一些我们正在推进到辐射实验室项目。其中一个大的，是利用统计和机器学习检测和定位系统中难以发现问题的。举例来说，如果你的整个网站的崩溃，这不是很难察觉。你可能会大清洗，但至少你知道你在大清洗。最棘手的问题是那些在您的客户的特定子集越来越不正确的页面浏览量，或您网站的某些特定功能无法正常工作。而且，正因为如此，你失去的流量。
一些更复杂的站点有各种各样的监测设备来尝试检测这些情况。但监视器并不完美，所以有时这些条件会持续一段时间，然后才会有人发现可能有什么问题。即使你检测到了它，你仍然需要找出是什么引起的。我们在ROC项目中开始研究的一件事就是统计和机器学习。你可以总结这个领域，这里有大量的数据，给我找一些有趣的模式。这是一种粗略的过度简化，但其理念是，你收集了大量的数据，你想做的是提取信息。
因此，在我们的例子中，我们可以在Java Enterprise Edition服务器和Internet系统运行时捕获许多仪表。我们可以收集关于它们响应用户工作负载的行为方式的信息，我们可以挖掘这些信息并寻找有趣的模式。
例如，我们会为普通用户使用，并设法捕捉到不同类型的路径用户的请求将通过该系统遵循观看J2EE应用服务器。有些用户会浏览目录的项目，有些是打算把东西放在购物车中，有些是要退房。而且，事实证明，您可以将这些路径到集合。So, if I build up a profile based on that, and then all of a sudden I start seeing a path that doesn’t really fit into any of those categories, that would be a good time to ask myself, is this a new kind of behavior that no user has ever exercised? Or, is there a problem with the system, and because of that users are actually following a path that isn’t really one of the valid paths, or one of the paths that I had set up for him to follow?
事实证明，这种方法实际上非常有效地定位了一些只影响某些人或只影响某些特性的部分问题，这些问题通常不会出现在常规服务器日志中。基于路径的分析已在eBay和Tellme Networks上被用于诊断性能问题、bug和系统演化问题，后者运营着复杂的基于语音识别的电话应用程序。
现在，当然，如果你能预见到所有这些可能出现的问题提前，你可以有有人手动写测试用例不断监视系统，以查看是否有任何问题出现。但是，你不能总是预测每一个问题提前，甚至如果你可以，这是一个很大的人工作到代码的所有这些情况。然后，当然，如果您添加或更改任何东西，你已经介绍了一堆新的变量，所以你不得不回去重新做那些测试。
这样的想法是自动化的任务。我说，没关系，看系统，因为现在我相信这是正常工作，而你建立了什么正常的，其实就是一个配置文件。而且，然后尝试去寻找从偏差。
就像他们在入侵检测系统里做的那样?
是的。但有一个重要的区别。这些统计算法是惊人的，但没有一个是完美的。他们都犯错误，基本上有两种错误，假阴性，意思是发生了什么，你错过了它，和假阳性，意思是你发出警报，但实际上没有什么错。所以，我们和入侵检测人员的区别是，如果他们在假警报的情况下关闭系统，他们会给很多人带来不便。如果我们在一个错误警报上采取行动并进行一次微重启，那么它是如此之快，你几乎不会注意到它，除非它是一个性能问题。
所以，微重启有这个很好的特性，我们正在努力确定其他的技术来解决一些常见的问题，如果你尝试它，它不工作，不会花费你很多。真正来自ROC的是这种统计机器学习的结合，它善于发现这些模式，但有时也会出错，结合快速恢复行动，使它可以在错误警报下采取行动。
还有什么来自中华民国的吗?
如果ROC项目是一个三条腿的凳子，那么我只描述了两条腿。第三部分是关于人类操作者:我们如何减少错误的发生，如果他们确实犯了错误，我们如何给他们更好的工具，以便他们能够识别错误并从错误中恢复过来?
一个与统计机器学习问题是算法是不容易理解。所以，如果我们展示了运营商的这些算法，他们将推出自己的眼睛一个分析。此外，这是他们的上线对接，如果系统出现故障，所以，他们不敢随便翻控制算法他们甚至不知道他们理解。
因此，在ROC项目接近尾声时，我们所做的一件重要的事情就是将统计机器学习与可视化结合起来，现在我们进入了RAD实验室项目。因此，我们不仅在分析这些算法的输出，我们还根据它们每天必须处理的相同类型的系统行为来展示深入的、信息丰富的图形可视化。
例如，我们与一家叫做E-Bates的中型互联网公司合作，他们允许我们使用他们的实际服务器日志，在他们的系统出现故障、功能失效、网站部分瘫痪等情况时，我们可以使用他们的日志。我们所做的是创建一个简单的可视化操作人员可以看到发生了什么。我可以给你看一幅图，你甚至不知道这幅图代表什么，你可以指着某样东西说，这是错的。
操作员习惯于看到视觉模式。而且，如果它们在图片中看到与自己的模式不匹配的东西，它们会立刻警觉起来，说:“哦，通常不是这样的。”“当他们看到这些，他们就可以点击图片的那部分，然后深入到统计机器学习算法对这部分数据的描述。”
这可能表明，这些页面在过去几个小时内收到的点击量是异常的。特别地，这里是对算法决策贡献最大的三页。然后操作员就可以开始查找这三个页面，看看是否有与这些页面使用方式相关的问题，或者bug。
我们不仅能够识别出所有已经发生的故障，我们还在数据中发现了一些地方，我们的系统说发生了故障，而他们的操作员却不知道。这让他们想要回到他们的电子邮件日志，看看在这些事件中是否真的发生了什么。
随着时间的推移，操作人员开始更加信任算法，因为他们越来越熟悉算法是如何工作的，更重要的是，他们更加相信算法确实在说一些有意义的事情。
好吧。那么，您是在将这三个核心概念推进到RAD项目中吗?