Erlangの99.9999999％（ナインナイン）の信頼性
Erlang は、稼働時間の割合が99.9999999％で、20年以上にわたって実稼働システムで使用されていることが報告されました。
私は次のように数学をしました：
20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s
つまり、システムのダウンタイムは20年間で1秒未満です。私はこれの妥当性に異議を唱えようとはしていません。たった0.631秒でシステムを（意図的にまたは偶然に）シャットダウンする方法に興味があります。大規模なソフトウェアシステムに精通している人なら誰でもこれを説明できますか？ありがとうございました。
処理装置（またはマシン）のクラスターでサービスのダウンタイムを計算する方法を知っている人はいますか？
信頼性の数値は、AXD301（問題のプロジェクト）の一部が20年以上にわたってシャットダウンされた合計時間を測定するものではありませんでした。 AXD301システムによって提供されるサービスがこれまでオフラインだった20年間の合計時間を表します。微妙な違い。ジョーアームストロングが言うように ここ ：
AXD301は、ナインナインの信頼性を達成しています（そう、あなたはその正しい読み方、99.9999999％）。これをコンテキストに入れてみましょう：ファイブナインは良いと見なされます（ダウンタイムは年間5.2分）。 7ナインはほとんど達成できません...しかし、9を行いました。
どうしてこれなの？共有状態はなく、洗練されたエラー回復モデルがあります。
Erlangの原作者であるJoeが書いた博士論文（AXD301のケーススタディを含む）をもう少し掘り下げると、次のようになります。
この章で検討したプロジェクトの1つは、エリクソンAXD301、、高性能で信頼性の高いATMスイッチです。
そのため、スイッチが属していたネットワークがダウンタイムなしで稼働している限り、著者はAXD301（詳細を避けて、彼が言ったことすべて）に対して「ナインナインの信頼性」と述べることができます。 Erlangがこのような高い信頼性の唯一の原因であるとは限りません。
編集：実際、「20年」自体は誤解のように思えます。ジョーは同じ記事で20年の数字について言及していますが、実際には9から9の信頼性の数字とは関係ありません。
他の人はあなたが質問している特定のケースに対処していますが、あなたの質問は誤解に基づいているようです。あなたが質問した方法は、システムがクラッシュしたりメンテナンスのためにダウンした後、システムを再び稼働させるための手動プロセスがあると考えていると信じさせてくれます。
Erlangには、ダウンタイムの原因として人間の労働時間を削除するいくつかの機能があります。
ホットコードの再読み込み。 Erlangシステムでは、既存のモジュールの代替モジュールを簡単にコンパイルしてロードできます。 BEAMエミュレータは、明らかに何も停止することなく自動的にスワップを実行します。この転送が行われる時間は間違いなくわずかですが、人間の時間で手動で行うのではなく、コンピューターの時間で自動的に行われます。これにより、本質的にzeroダウンタイムでアップグレードを行うことができます。 （交換モジュールにシステムをクラッシュさせるバグがある場合、ダウンタイムが発生する可能性がありますが、実稼働環境にデプロイする前にテストする理由です。）
監督者。 ErlangのOTPライブラリには監視モジュールが組み込まれており、モジュールがクラッシュした場合のシステムの対応方法を定義できます。ここでの標準アクションは、失敗したモジュールを再起動することです。再起動されたモジュールがすぐに再びクラッシュしないと仮定すると、システムに対して請求される合計ダウンタイムはミリ秒の問題になる場合があります。クラッシュすることのほとんどない堅実なシステムでは、実際に数年間の実行時間にわたって、合計ダウンタイムのほんの数分の1が蓄積されるだけです。
プロセス。これらは、他の言語のスレッドにほぼ対応していますが、永続的なデータストアを介した場合を除き、状態を共有しません。それ以外は、通信はメッセージの受け渡しを介して行われます。 Erlangプロセスは非常に安価（OSスレッドよりもはるかに安価）であるため、疎結合設計が促進され、プロセスが停止した場合、システムのごく一部のみがダウンタイムを経験します。通常、スーパーバイザーはその1つのプロセスを再起動しますが、システムの残りの部分にはほとんど影響を与えません。
非同期メッセージパッシング。あるプロセスが別のプロセスに何かを伝えたい場合、それを可能にするErlang言語の第一級の演算子があります。メッセージ送信プロセスは、受信者がメッセージを処理するのを待つ必要はなく、送信されるデータの所有権を調整する必要もありません。 Erlangのメッセージパッシングシステムの非同期機能的性質は、これらすべてを処理します。これは、システムのある部分のダウンタイムが他の部分に与える影響を減らすため、高い稼働時間を維持するのに役立ちます。
クラスタリング。これは前のポイントから続きます。Erlangのメッセージパッシングメカニズムはネットワーク上のマシン間で透過的に機能するため、送信プロセスは受信者が別のマシン上にあることを気にする必要さえありません。これにより、ワークロードを多数のマシンに分割するための簡単なメカニズムが提供されます。各マシンは、システム全体の稼働時間を損なうことなく個別にダウンできます。
99.9999999％の可用性の数値は、頻繁に引用されていますが、基本的に誤解を招く統計です。 AXD-301チームメンバーの1人であるMats Cronqvistは、サンフランシスコで開催された2010 Erlang Factoryカンファレンスで プレゼンテーション（ビデオ） （これに参加しました）可用性統計。彼によると、ブリティッシュテレコムは、AXD-301を使用した「5ノード年」の試用期間（2002年1月から9月まで）と主張しました。トライアルの終了までに、ライブトラフィックを運ぶノードが14個ありました。
クロンクビストは、これはAXD-301の歴史全体、またはアーラン全般を代表するものではなく、ジョーアームストロングがこれを引用し続け、アーランの信頼性に対する誇張された期待につながることに満足していなかったと明確に述べました。 他の人が書いた ファイブナインはより現実的な数字です。
私は熱心なErlangサポーターおよび開発者であり、Erlangの専門家による使用は実際に非常に可用性の高いシステムにつながる可能性があると考えていますが、誇大広告を減らしたいだけです。もちろん、クロンクヴィストの事実の表現は正確であり、そうでないと信じる理由はないと思います。
これらの統計の私の理解は、実稼働中のすべてのAXD301システムで計算されるということです。 AXD301に重大な問題がある場合、0.631秒以上ダウンすることが予想されます。この期間中に、他のAXD301が引き継ぎ、ネットワークの動作を維持します。
ただし、実行中のすべてのAXD301の合計時間数を合計すると、AXD301に障害が発生した時間の比率を計算すると、99.999999％になります。
それが私がこの図を理解する方法です。
この助けを願っています。