阿曼多·福克斯认为，如果你不能建立防故障系统，你应该能够如此之快，服务的光点变得微不足道恢复至少构建系统。A Research Associate with the University of California Berkeley’s Reliable, Adaptive Distributed systems laboratory (RAD Lab), Fox was one of the leads on the joint Berkeley/Stanford Recovery-Oriented Computing (ROC) Project that investigated techniques for building dependable Internet services that emphasized “recovery from failures rather than failure-avoidance.”
自那以后，福克斯将ROC的一些经验带到RAD实验室，该实验室于2005年启动，获得了谷歌、微软和Sun提供的750万美元资金。联盟成员包括IBM、惠普、北电、NTT-MCL和甲骨文。RAD实验室关注的是困扰大型基于互联网的企业的问题，因为这些环境代表了一种极端的情况，但是Fox说，从中得到的经验教训最终会渗透到企业用户中。足球竞猜app软件编辑总司令约翰·迪克斯要求福克斯解释愿景。
让我们用ROC的审查开始。刚才那是干什么啊？
中华民国项目的理念是事情发生。尽管设计和调试这些复杂的网络系统，我们最大的努力，就难免落得在我们没有想到的方式失败。硬件是不完美的。软件都有漏洞。即使是真的，像Oracle真正行之有效的软件，你会发现在它的错误它已经在外地了。而且，你知道，人类是负责运行这些系统的，有时他们犯错误。
所以ROC项目的理念是，让我们接受这些事情将要发生的事实并开始考虑设计快速恢复而不是设计避免失败，这不是一个现实的目标。提高系统可用性的一种方法是永不失败。但是，另一种改进方法是快速从故障中恢复，这样对可用性的贡献可以忽略不计。
为什么您一开始就假定您永远不能构建不会失败的系统?
因为我们不认为我们有足够的智慧来对抗过去60年的计算机科学史。有很多人致力于通过正确性和其他技术来改进系统和减少错误。这是一件好事。但到目前为止，尽管我们尽了最大的努力，但我想不出有哪一个计算机系统在被设计出来的时候没有发现任何漏洞。
所以，我想我们可以采取这样的立场，无论如何，在未来这一切都会改变。但我们已经说了几十年了。这并不是说我们愚蠢，对吧?我的意思是，在性能，存储密度，网络通信速度方面，看看我们在30年里所能做到的。然后将其与我们在可靠性方面所能做的进行比较。这些系统的复杂性已经到了任何一个人都很难理解其中一个系统是如何工作的地步。
另外，市场现实就是这样，并不是说你要完善整个系统，部署它，然后就不管它了。系统必须进化。添加新特性，获得更多用户，扩大系统规模。所有这些过程都与可靠性背道而驰。最可靠的软件是运行航天飞机的软件，问问那些人他们是如何对软件进行修改的。在修改一行代码之前，他们必须编写数千页的文档和数百小时的设计审查。所以他们有超级可靠的软件，但这是有代价的。
而现实情况是大多数互联网公司不能付出这样的代价。决定它是否能推出一个新功能之前，亚马逊不能有数以百计的设计会议的时间。所以ROC项目基本上是说，你看，我们需要找到一种方式来处理这个问题，在什么商业现实的背景。因为，是的，这些系统的迅速发展。而且，是的，这是很糟糕的可靠性。但是，创新是很多这些系统的价值从何而来。而且我们不会，作为学者，提出了一种方法，它说，你可以修复你的系统的问题，但在快速创新的成本。
所以，这是中华民国的理念。我们实际上在确定两件事情所取得的进展相当数量。我们确定了可以内置到软件系统中的一些具体技术，这将有助于从某些种类的常见问题中恢复，真快。事实上，如此之快，有时你甚至可能没有注意到它，除了在性能上微小的昙花一现。所以，这是一个重要的发现。而且，这些想法也开始找到自己的方式进入一些商业产品。
怎么样一个例子。
确定。我们研究的一个想法叫做微重启。当您有一个奇怪的、意外的、不可恢复的错误并且不知道还有什么错误时，您需要重新启动计算机。有时候这就足够解决问题了。但是重新启动需要很长时间。因此，考虑到应用程序已经使用企业Java bean (EJB)之类的东西发展到这种组件化的体系结构，我们的想法是一次对少量组件应用重新启动的概念。因此，您不必重新启动整个EJB服务器(这可能需要花费几分钟)，而只需重新启动看起来一直在失败的EJB组件。因此，您重置了出现故障的东西，但成本却低得多，因为您只对您认为是问题实际根源的EJB组件进行了重置。
你看到了这种练习的进步吗?
这种做法的变体正在被应用到一些商业产品中。虽然我不确定我是否被允许说具体是哪一个。
微重启是中华民国七个核心研究领域之一，对吧?还有其他的行为吗?
是的。其中有一些我们正在推进到RAD实验室项目中。其中最重要的是使用统计和机器学习来检测和定位系统中难以发现的问题。例如，如果您的整个站点崩溃了，检测起来并不困难。你可能已经被逼疯了，但至少你知道自己被逼疯了。棘手的问题是客户的某个子集得到了不正确的页面视图，或者站点的某些特定功能不能正常工作。因此，你会失去流量。
一些更复杂的站点有各种各样的监测设备来尝试检测这些情况。但监视器并不完美，所以有时这些条件会持续一段时间，然后才会有人发现可能有什么问题。即使你检测到了它，你仍然需要找出是什么引起的。我们在ROC项目中开始研究的一件事就是统计和机器学习。你可以总结这个领域，这里有大量的数据，给我找一些有趣的模式。这是一种粗略的过度简化，但其理念是，你收集了大量的数据，你想做的是提取信息。
所以，在我们的例子中，我们可以为他们正在运行俘获了不少来自Java企业版服务器和网络系统设备的。我们可以收集有关他们在响应用户的工作量行为方式的信息，我们可以挖掘有趣的模式，信息和外观。
例如，当普通用户使用J2EE应用程序服务器时，我们将观察它，并尝试捕获用户请求在系统中所遵循的不同类型的路径。有些用户会浏览商品目录，有些用户会将商品放入购物车，有些用户会结账。你可以把这些路径分组到集合中。如果我建立一个概要文件基础上,然后突然开始看到一个路径,并不适合任何的类别,这将是一个好时机问自己,这是一种新型的行为从来没有用户行使?或者，系统是否有问题，因此用户实际上遵循的路径不是有效路径，或者是我为他设置的路径?
事实证明，该方法实际上是在查找某些类型的只影响一些人还是只影响某些功能，以及不正常的东西像普通服务器日志显示了部分问题的非常有效的。基于路径分析已用于诊断性能问题，错误和系统演化问题在eBay和Tellme公司网络，经营复杂的基于语音识别电话应用。
现在，当然，如果您可以提前预见所有这些可能的问题，您可以让某人手动编写测试用例来持续监视系统，以查看是否出现任何问题。但你不能总是提前预测每个问题，即使你能，也需要很多人来编写这些情况。然后，当然，如果你添加或改变了任何东西，你就引入了一堆新的变量，所以你必须回去重新做那些测试。
所以我们的想法是自动化这项任务。我说，好吧，观察这个系统因为现在我认为它运行正常，然后你就建立了正常的定义。然后你试着找出它的偏差。
就像他们在一些入侵检测系统吗？
是的。但有一个重要的区别。这些统计算法是惊人的，但没有一个是完美的。他们都犯错误，基本上这两种错误是假阴性，其手段有事和你错过它，误报，你发出警报，但实际上这意味着有是不是真的做错什么。所以，我们和入侵检测球员之间的区别是，如果他们采取行动是虚惊一场，并关闭系统，他们已经不便了许多人。如果我们采取行动是虚惊一场，做一个微重启，它是如此之快，你几乎感觉不到它，除非是作为性能昙花一现。
所以，微重启有这个很好的属性，我们正在努力鉴别修复常见的类的问题，如果你尝试其他技术工作，不工作，不花你太多。即来到中华民国出来的真实的东西是统计机器学习，这是在发现这些图案伟大的组合，但有时候会犯了一个错误，与使它没关系上一场虚惊迅速采取行动恢复操作相结合。
别的都ROC的呢？
如果ROC项目是一个三条腿的凳子，那么我只描述了两条腿。第三部分是关于人类操作者:我们如何减少错误的发生，如果他们确实犯了错误，我们如何给他们更好的工具，以便他们能够识别错误并从错误中恢复过来?
统计机器学习的一个问题是算法不容易理解。所以如果我们给操作员看这些算法的分析他们会翻白眼。此外，如果系统出现故障，他们就会受到威胁，所以他们会犹豫是否把控制权交给一个自己甚至不确定自己理解的算法。
因此，在ROC项目接近尾声时，我们所做的一件重要的事情就是将统计机器学习与可视化结合起来，现在我们进入了RAD实验室项目。因此，我们不仅在分析这些算法的输出，我们还根据它们每天必须处理的相同类型的系统行为来展示深入的、信息丰富的图形可视化。
例如，我们曾与一个中等规模的互联网公司叫做E-贝茨，他们允许我们使用他们的实际服务器日志的过程中，他们不得不事件与他们的系统中的若干段，功能失效，他们的网站的一部分下去，不管。而我们所做的就是创建了一个简单的可视化，其中运营商可以看到发生了什么事。我可以告诉你一幅画和，甚至不知道什么图片代表，你将能够点的东西，并说，这是错误的。
运营商习惯于看到视觉模式。而且，如果他们看到在图片的东西，不符合他们的模式，他们马上去提高警觉，说：“噢，它通常不看这种方式。”而且，当他们看到，他们可以点击图片的一部分，并深入到一下统计机器学习算法说，有关这部分数据。
这可能表明，这些页面在过去几个小时内收到的点击量是异常的。特别地，这里是对算法决策贡献最大的三页。然后操作员就可以开始查找这三个页面，看看是否有与这些页面使用方式相关的问题，或者bug。
而我们不仅能够识别所有已实际发生的故障，我们居然发现一对夫妇在他们的数据在那里我们说系统发生故障及其经营者不知道它的地方。这使他们想回到自己的电子邮件日志，看看是否有任何这些事件中真的发生了。
随着时间的推移，操作人员开始更加信任算法，因为他们越来越熟悉算法是如何工作的，更重要的是，他们更加相信算法确实在说一些有意义的事情。
好吧。那么，您是在将这三个核心概念推进到RAD项目中吗?