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