Erlang 二郎'；s 99.999999%（九个9）可靠性

据报告，已在生产系统中使用超过20年，正常运行时间百分比为99.999999%

我做了如下数学运算：

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

这意味着系统在20年的时间内只有不到1秒的停机时间。我并不是想质疑这一点的有效性，我只是想知道我们如何能关闭一个系统（有意或无意）仅0.631秒。熟悉大型软件系统的人能给我们解释一下吗？多谢各位

---

---

有人知道如何计算一组处理单元（或机器）上的服务停机时间吗？

可靠性数据不应该用来衡量AXD301（相关项目）任何部分在20年内关闭的总时间。它表示在这20年中，

AXD301

系统提供的服务一直处于脱机状态的总时间。细微的差别。正如乔·阿姆斯特朗所说：

AXD301实现了九个9的可靠性（是的，你读对了，99.999999%）。让我们把它放在上下文中：5个9被认为是好的（每年5.2分钟的停机时间）。7个9几乎无法实现。。。但我们做到了9

为什么会这样？没有共享状态，加上复杂的错误恢复模型

如果你再深入一点，在Erlang（包括

AXD301

的案例研究）的原始作者Joe撰写的博士论文中，你会读到：

本章研究的项目之一是爱立信AXD301， 高性能、高可靠性的ATM交换机

因此，只要交换机所在的网络在没有停机的情况下运行，作者就可以说明

AXD301

的“九个9的可靠性”（这是他所说的，避免了细节）。这并不一定意味着Erlang是如此高可靠性的唯一原因

---

编辑：事实上，“20年”本身似乎是一种误解。Joe在同一篇文章中提到了一个20年的数据，但它实际上与九个9的可靠性数据没有联系，这可能来自一个更短的研究（正如其他人所提到的）。

我对这些统计数据的理解是，它是在生产中的所有AXD301系统上计算出来的。我们可以预计，当AXD301出现严重问题时，它将停机超过0.631秒。在此pediod期间，其他AXD301将接管以保持网络运行

但是，当您将所有运行AXD301的总小时数相加时，将失败AXD301的总小时数的比率计算为99.99999%

这就是我对这个数字的理解

---

希望这能有所帮助。

虽然其他人已经解决了您所问的具体案例，但您的问题似乎是基于误解。你问这个问题的方式让我相信你在想，在系统崩溃或停机进行维护后，有一个手动过程可以让系统重新运行

Erlang有几个功能可以消除人工工作时间作为停机时间的来源：

热代码重新加载。在Erlang系统中，很容易编译和加载现有模块的替换模块。BEAM emulator会自动进行交换，而不会明显停止任何操作。毫无疑问，这种转移发生的时间很短，但它是在计算机时间自动发生的，而不是在人类时间手动发生的。这使得在基本上零停机的情况下进行升级成为可能。（如果更换模块出现导致系统崩溃的错误，您可能会停机，但这就是为什么您在部署到生产环境之前进行测试的原因。）

主管。Erlang的OTP库内置了一个监控框架，允许您定义在模块崩溃时系统应如何反应。这里的标准操作是重新启动发生故障的模块。假设重新启动的模块不会立即再次崩溃，系统的总停机时间可能仅为毫秒。一个几乎从不崩溃的可靠系统，在多年的运行时间中，可能只会累积总停机时间的一小部分

进程。这些线程大致相当于其他语言中的线程，只是它们不共享状态，除非通过持久数据存储。除此之外，通信是通过消息传递进行的。因为Erlang进程非常便宜（比OS线程便宜得多），这鼓励采用松散耦合的设计，因此如果进程死亡，系统中只有一小部分会经历停机。通常，主管会重新启动该进程，对系统的其余部分几乎没有影响

异步消息传递。当一个进程想要告诉另一个进程某些事情时，Erlang语言中有一个一流的操作符可以让它这样做。消息发送过程不必等待接收方处理消息，也不必协调所发送数据的所有权。Erlang消息传递系统的异步功能特性解决了所有这些问题。这有助于保持较高的正常运行时间，因为它减少了系统某个部分的停机时间对其他部分的影响

聚类。这是从上一点开始的：Erlang的消息传递机制在网络上的机器之间透明地工作，因此发送过程甚至不必关心接收器是否在单独的机器上。这为在多台机器之间分配工作负载提供了一种简单的机制，每台机器都可以单独下降，而不会影响整个系统的正常运行时间

---

99.9999999%的可用性数据经常被引用，但从根本上说是误导性的统计数据。Mats Cronqvist，AXD301团队成员之一，在旧金山的2010次Erlang工厂会议上（我参加）讨论了这一公关。