Erlang的99.9999999％（九个九）可靠性
据报道Erlang已被用于生产系统超过20年，正常运行时间百分比为99.9999999％。
我做了如下的math：
20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s 这意味着系统在20年内只有不到1秒钟的停机时间。 我不想质疑这个问题的有效性，我只是好奇我们如何才能closures一个系统（有意或无意），只有0.631秒。 任何熟悉大型软件系统的人都可以向我们解释这一点吗？ 谢谢。
有没有人知道如何计算一个处理单元（或机器）集群服务的停机时间？
可靠性数据不应该衡量AXD301 （项目中的任何一个部分）closures20多年的总时间。 它代表了AXD301系统提供的服务在过去的20年中一直处于离线状态的总时间。 细微差别。 正如Joe Armstrong 在这里所说：
AXD301已经实现了9个9的可靠性（是的，你读得对，99.9999999％）。 让我们把它放在上下文中：5个9就算好（5.2分钟的停机时间/年）。 7个9个几乎难以实现…但我们做了9个。
为什么是这样？ 没有共享状态，加上复杂的错误恢复模式。
如果你深入一点，在Erlang的原作者Joe（其中包括一个AXD301的案例研究）的Joe写的博士论文中，你读到：
本章所研究的项目之一是爱立信AXD301，这是一款高性能，高度可靠的ATM交换机 。
所以，只要交换机所属的networking没有停机，笔者就可以说AXD301 “ AXD301可靠性”（这是他所说过的所有的事情，避免具体问题）。 这并不意味着Erlang是这种高可靠性的唯一原因。
编辑：其实“20年”本身似乎是一个误解。 乔在同一篇文章中提到了20年的数字，但实际上并没有连接到九九的可靠性数字，这可能来自一个更短的研究（如其他人已经提到）。
虽然其他人已经解决了你所问的具体情况，但你的问题似乎是基于一种误解。 你问这个问题的方式让我相信你认为有一个手动的过程来让系统在崩溃或重新开始维护之后再次运行。
Erlang有几个function，可以消除人为工作时间造成的停机时间：
-
热码重新加载 。 在Erlang系统中，编译和加载replace模块是很容易的。 BEAM模拟器自动执行交换，而不会明显停止任何事情。 毫无疑问，这种转移发生的时间很短，但在计算机时间内自动发生，而不是在人工时间手动发生。 这使得可以进行基本上无需停机的升级。 （如果replace模块有一个使系统崩溃的错误，您可能会停机，但这就是为什么在部署到生产之前testing的原因。）
-
监事 。 Erlang的OTP库有一个内置的监督框架，可以让你定义系统在模块崩溃时应该如何反应。 这里的标准操作是重新启动发生故障的模块。 假设重新启动的模块不会立即再次崩溃，则对系统收取的总停机时间可能只有毫秒。 一个几乎不会崩溃的可靠系统，在运行几年的过程中，确实只能累积总停机时间的一小部分。
-
过程 。 这些对象大致对应于其他语言的线程，只是除了通过持久数据存储之外，它们不共享状态。 除此之外，沟通通过消息传递发生。 因为Erlang进程非常便宜（比操作系统线程便宜得多），这就鼓励了松散耦合的devise，所以如果一个进程死了，系统中只有一小部分会遇到停机。 通常，主pipe重新启动一个进程，对系统其余部分几乎没有影响。
-
asynchronous消息传递 。 当一个进程想要告诉另一个进程时，Erlang语言中就有一个一stream的运算符，它可以做到这一点。 消息发送过程不必等待接收者处理消息，也不必协调发送的数据的所有权。 Erlang消息传递系统的asynchronousfunction特性负责所有这些。 这有助于保持较长的正常运行时间，因为它减less了系统某一部分的停机时间对其他部分的影响。
-
聚类 。 这是从以前的观点来看：Erlang的消息传递机制在networking上的机器之间透明地工作，所以发送过程甚至不必关心接收机在单独的机器上。 这为在多台机器之间分配工作负载提供了一个简单的机制，每台机器都可以单独下去，而不会损害整个系统的正常运行时间。
99.9999999％的可用性数字是一个经常被引用但是从根本上具有误导性的统计数字。 AXD-301团队成员之一Mats Cronqvist在旧金山举行的2010 Erlang工厂会议上做了演讲 （video） ，讨论了这一精确的可用性统计。 据他介绍，它被英国电信公司声称试用期（我相信从2002年1月到9月）使用AXD-301的“5个节点年”。 试验结束时有14个节点进行现场交通。
Cronqvist特别指出，这并不代表整个AXD-301的历史，或一般的Erlang，他并不高兴Joe Armstrong一直在引用这个，导致对Erlang的可靠性的过度期望。 其他人写道 ，五个九是一个更现实的数字。
应该说，我是Erlang的支持者和开发者，他相信Erlang的专家使用确实可以导致非常高的可用性系统，但只是想减less炒作。 我当然认为克朗奎斯特对事实的表述是准确的，没有理由相信。
我对这些统计数据的理解是，它是在生产中的所有AXD301系统上计算的。 我们可以预料到，当一个AXD301有一个严重的问题，它会下降超过0.631秒。 在此期间，其他AXD301将接pipe，以保持networking运行。
但是，当您将所有运行的AXD301的总小时数相加时，请将发生故障的AXD301的比率设为99.999999％
这就是我理解这个数字的方法。
希望这个帮助。
