ErlangのLet-it-Crash哲学 - 他の場所で適用されますか？

Question

アーラン（またはジョーアームストロング？）アドバイス 防御プログラミングを使用しないでください そして、プロセスをクラッシュさせるために（残骸を追跡しようとする不必要な警備員でコードを汚染するのではなく）私にとって非常に意味があります。

私が疑問に思うのは - このアプローチはErlangのようなプラットフォームにのみ当てはまりますか？ Erlangには、プロセス監督のツリーと再起動プロセスをサポートするシンプルなネイティブサポートを備えたVMがあります。 本当 速い。トップレベルの例外ハンドラー、エラーコード、ヌルの結果などで自分自身を倒すのではなく、監督の木を再現することに、開発の努力を（エルランの世界ではない場合）。

このアプローチの変更は、.NETまたはJavaスペースで（たとえば）うまく機能すると思いますか？

Answer 1

どこでも適用できます. 。ソフトウェアを「クラッシュさせる」パターンでソフトウェアを書くかどうかにかかわらず、ハードウェアが失敗したときに、とにかくクラッシュします。 「Let It Crash」は、現実に耐える必要がある場所に適用されます。 Quoth James Hamilton：

ハードウェアの障害に即時の管理措置が必要な場合、サービスは単に費用対効果と確実にスケーリングしません。サービス全体は、人間の管理的相互作用なしに失敗を乗り切ることができなければなりません。障害回復は非常に単純なパスでなければならず、そのパスは頻繁にテストする必要があります。スタンフォードのアルマンドフォックスは、故障パスをテストする最良の方法は、サービスを正常に停止することは決してないと主張しています。ハードフェールしてください。これは直感に反するように聞こえますが、障害パスが頻繁に使用されない場合、必要なときに動作しません。

ただし、これは「ガードを使用しない」という意味ではありません。しかし、クラッシュすることを恐れないでください！

Answer 2

はい、どこにでも適用できますが、どのコンテキストが使用されることを意図しているかに注意することが重要です。します いいえ @Petermが指摘したように、多くの場合、 @Petermが指摘したように、アプリケーションがクラッシュすることを意味します。目標は、全体としてクラッシュすることはなく、内部でエラーを処理できるシステムを構築することです。私たちの場合、それはTeleCommsシステムであり、年間数分程度のダウンタイムがあると予想されていました。

基本設計は、システムを階層化し、システムの中央部分を分離して、作業を行う他の部分を監視および制御することです。 OTP用語では、私たちが持っています 監督者 と ワーカー プロセス。監督者は、労働者がすべての実際の仕事をしている間にクラッシュしたときに正しい方法でそれらを再開することを目標に、労働者や他の監督者を監視する仕事を持っています。機能を厳密に分離するというこの原則を使用して、システムを適切に層状に構成することで、労働者から監督者にエラー処理を断ち切るエラーを隔離することができます。あなたはaで終わるようにします 小さい フェイルセーフエラーカーネル。正しい場合は、システムの残りの場所でエラーを処理できます。この文脈において、「let-it-crash」哲学が使用されることを意図したものです。

可能な限り少数の場所で実際にそれらを処理することを目標に、どこでもエラーや障害について考えている場所のパラドックスを取得します。

エラーを処理するための最良のアプローチは、もちろんエラーとシステムに依存します。プロセス内で局所的にエラーをキャッチし、そこでそれらを処理しようとするのが最善である場合があります。多くの労働者プロセスが協力している場合は、それらすべてをクラッシュさせて再び再起動することをお勧めします。これを行う監督者です。

何か問題が発生したときにエラー/例外を生成する言語が必要です。そうすれば、それらをトラップしたり、プロセスをクラッシュさせたりすることができます。エラー戻り値を無視するだけでは同じことではありません。

Answer 3

それはフェイルファストと呼ばれます。あなたが失敗に対応できる（そして迅速に行う）人々のチームがあるならば、それは良いパラダイムです。

海軍では、すべてのパイプと電気が壁の外側に取り付けられています（できれば壁のより公共側に）。そうすれば、漏れや問題がある場合、すぐに検出される可能性が高くなります。海軍では、人々は失敗に対応しないことで罰せられているため、非常にうまく機能します。失敗は迅速に検出され、迅速に行動します。

誰かが迅速に失敗に基づいて行動できないシナリオでは、システムを停止できないか、失敗を飲み込んで前進しようとすることがより有益であるかどうかが意見の問題になります。

Answer 4

私は現実世界の状況からのデータに依存するプログラムを書きます。彼らがクラッシュすると、物理的な損害に大きな$$を引き起こす可能性があります（失われた収益の大きな$$は言うまでもありません）。防御的にプログラムしなかった場合、私は一瞬で仕事を終えます。

とはいえ、エルランは、即座に物事を再起動できるだけでなく、再起動したプログラムがポップアップし、見回して「ああ、それが私がやっていたことだった！」と言うことができる特別なケースでなければならないと思います。

Answer 5

私の同僚と私自身は、このトピックについて特にテクノロジーではなく、ドメインの観点から、そして安全性に焦点を当てていることについて考えました。

問題は、「クラッシュさせても安全ですか？」です。または、「エアランの「Let It Crash」のような堅牢性パラダイムを安全関連ソフトウェアプロジェクトに適用することさえ可能ですか？」

答えを見つけるために、産業、特に医学的背景を備えた現実に近いシナリオを使用して、小さな研究プロジェクトを行いました。ここを見てください（http://bit.ly/z-blog_let-it-crash）。ダウンロード用の論文もあります。あなたの考えを教えてください！

個人的には、多くの場合、特に多くのエラー処理が行われる場合（安全関連システム）がある場合は、それが適用可能であり、望ましいと思います。 Erlang（リアルタイムの機能が欠落している、実際の組み込みサポートなし、衣装を着た衣装を使用することは常にありません...）を使用することはできませんが、そうでないことを実装できると確信しています（例：スレッド、例外、メッセージの合格を使用）。私はまだ試していませんが、私はしたいです。

Answer 6

IMHO一部の開発者は、ほとんど価値を追加するコードでチェックされた例外を処理/ラップします。多くの場合、メソッドを処理して価値を追加しない限り、メソッドが元の例外をスローできるようにする方が簡単です。