performance - フェイル ファスト vs. 堅牢性

Question

当社の製品は分散システムです。私が取り組んでいるモジュールはかなり新しく、非常に厳密で、よくテストされています。これらは、最近のベスト プラクティスを念頭に置いて開発されました。その他のモジュールは、レガシー ソフトウェアと見なすことができます。

私は自分が担当しているモジュール内で発生するすべてのことに注意を払っていますが、他のモジュールから送信された不良データを処理するというプレッシャーに常にさらされています。本質的に、私は「フェイル ファスト」原則の開発者であり、その結果、問題が発生した場合、通常はモジュールのエラーの可能性を排除することができます。責めるということではなく、間違った場所でバグを追跡する無駄な労力を節約するだけです。

しかし、私が常に反対している議論は、「このようなものを本番環境で失敗させることはできません。顧客はこれが機能することを期待しています。この問題を回避してみませんか」というものです。そして、これは頑強さの議論になります。受け入れるものにはリベラルであり、送信するものには保守的であることです。

また、これらはほとんど断続的な問題であることにも注意してください。それらは統合テストで見られますが、再現するのは困難です。タイミングと並行性が関係しています。

2 つの原則のバランスをとるのに苦労しています。その理由の 1 つは、例外的なデータを許可して伝播し始めると、問題が発生し、自分のシステムにあまり自信が持てなくなるのではないかという心配です。しかし、他のモジュールが間違ったデータを送信している場合でも、システムを動作させ続けることに反対することはできません。他のモジュールが修正されていない理由は、それらが複雑すぎて壊れやすいためですが、私のモジュールはまだ明確で安全に見えます. しかし、私がプレッシャーに抵抗しなければ、私のモジュールは、私が今まで拒否してきたのと同じ問題をゆっくりと抱え込むことになります.

システムが本番環境で「クラッシュ」することはありませんが、モジュールが単にエラーをオペレータに表示し、サポートに連絡するように依頼する場合があります。クラッシュは大きな問題ですが、エラーを明確に報告しているのであれば、これは正しいことではないでしょうか? 私の同僚は、顧客に問題を見せたくないだけだと思います。しかし、私のモジュールは、顧客の入力ではなく、製品内の他のモジュールからのデータを拒否しています。ですから、私たちは問題に取り組んでいないだけのように思えます。

では、私はもっと現実的になる必要がありますか、それとも自分の立場を維持する必要がありますか?

Answer 1

私は「フェイル ファスト」の好み/原則を共有しています。ただし、これを原則の衝突と考えないでください。理解の衝突です。あなたのカウンターパートには、いくつかの要件が満たされていないことを意味する暗黙の要件 (「ユーザーに悪い時間を見せてはいけません」) があります。この要件について事前に考えたり実装したりする機会がなかったので、この要件はあなたの口に悪い味を残しました。この視点を忘れて、取り組むことができる固定要件を持つ新しいプロジェクトとして再アプローチしてください。

おそらく最良の結果は、表示されたようなエラー メッセージを表示することです。しかし、相手が受け入れるという選択をしたときに、相手から賛同を得る前にそれを実装したようですね。あなたがしていることについての以前のコミュニケーションは、そのようなことに対処できたかもしれません.

アイデアを防ぐ方法には注意してください。他のシステムを「複雑すぎて壊れやすい」と常に言及することは、人々を間違った方向にこすりつけている可能性があります。システムが新しく、理解するのに時間がかかることを簡単に表現してください。それらを理解するために時間を割いて、あなたの能力に対する人々の期待を下げないようにしてください。

Answer 2

止めないとどうなるかによると思います。誰かの給料が間違って処理されていますか? 間違った注文が送信されますか? それは立ち止まる価値があるでしょう。

可能であれば、ケーキも一緒に食べてください。ユーザーにエラーを報告せず、顧客に診断レポートを送信し、すべての障害を報告することに同意してもらいます。障害のあるモジュールを所有している開発者にバグを報告して、それらを修正してください。そして、バグとは、それらに対してバグを報告することを意味します。または、管理者が修正するコストに見合う価値がないと考えている場合は、修正しないでください。

また、失敗したモジュールに対する単体テストも作成します。特に、間違った出力を生成する原因となった元の入力が何であったかがわかればなおさらです。

結局のところ、あなたのパフォーマンスを評価する人があなたに何を求めているか、特にあなたがメールで問題を説明した後.

Answer 3

簡単に言えば、これは「処理できないものをチェックしない」ように聞こえます。エラーをキャッチして報告できるということは、それを伝播していないということです。しかし、これはまた、エラーを報告できるため、エラーをトラップする何らかのメカニズムがあり、したがって潜在的に自分で処理し、報告するのではなく修正することを意味します。

あなたのエラー レポートは、システムの奥深くで偶然見つけた例外よりも興味深いものだと思います。しかし、それでも、それがあなたがテストしていて作成している例外である場合 (つまり、分母がゼロであるかどうかを確認し、誤ってゼロで除算して例外を上位でキャッチするのではなく、エラーを送信する)、それはあなたを示唆しています問題を修正する方法があるかもしれません。

要するに、両方が必要です。データに可能な限りエラーがないようにする必要がありますが、予期しないことも報告する必要があります。

ドアに鍵をかけ、「私の問題ではない」と腕を組むことはできないと思います。それが「古くて壊れやすいシステム」から来ているという事実は無意味です。あなたのコードは古くて壊れやすいわけではなく、問題を検出したら、統合システム全体の観点から見て、データを「修正」するのに明らかに効率的な場所です。そうです、古いモジュールは他のより劣ったシステムにGIGOし続けますが、それらのレガシーモジュールと新しいモジュールを組み合わせることでまとまりがあり、「システム」を構成します。

ここでの典型的な実際の問題は、このすべての修正コードと新しい機能を記述する時間/価値の方程式です。それは別の議論です。しかし、時間があり、受信データをクリーンアップするためにできることを知っている場合は、「受け入れるものに寛大である」ことが健全なポリシーです。

Answer 4

理由には触れませんが、あなたは正しいです。

私の経験では、PHB には、なぜフェイル ファストにメリットがあるのか​​を理解するために必要な脳の部分が欠けており、必要に応じて必要に応じてエラーを食べることによって定義される「堅牢性」が悪い考えです。絶望的です。彼らはそれを理解するためのハードウェアを持っていません。彼らは、「あなたは良い点を言っていますが、ユーザーはどうですか」と言う傾向があります。

私のアドバイスは、自分の立場に立つことです。永遠に。

Answer 5

みんな、ありがとう。この質問を促したケースは、上記の回答から得た洞察のおかげで、うまく終了しました。

私の最初の反応は、すぐに失敗することに固執することでしたが、これについてもう少し考え、私のモジュールの役割の 1 つは、システムの残りの部分に安定したアンカーを提供することであるという結論に達しました。これは、必ずしも悪いデータを受け入れることを意味するわけではありませんが、問題を表面化し、それらを分離し、解決策が見つかるまで透明性のある方法で処理することを意味します。

このケース用に新しいハンドラーとコード パスを追加することを計画しました。これは、以前は文書化されていなかった特別なユース ケースであるかのように適切に実行されます。

境界での問題に対処する必要があることを繰り返し述べたが、喜んで助けてくれるという議論もありました。私の立場が過度に衒学的であると見なされているという疑いがあり、たとえそれが間違っていたとしても、無害なデータの誤った検証をオフにするだけで解決できると認識されていたので、私は自分の計画を反対側に概説しました. しかし実際には、私の作業方法は主にデータ駆動型であるため、なぜそれが正しくなければならないのか、それによって動作がどのように駆動されるのか、そしてこのデータに対応するためにどのように特別なコード パスを実装するのかを説明しました。

これは私の立場に重みを与え、反対側がデータを修正することを嫌うというより徹底的な議論につながったと思います。実際の障害よりも、エラーが発生しやすいレガシー システムに対処することの疲れであることが判明しました。比較的単純な解決策がありました。変化を起こすのはただ怖かっただけで、かなり定着した考え方でした。

しかし、すべての課題と可能な解決策を公開した後、最終的にデータを修正することに同意し、これまでのところ問題は解決したようです. 統合テストは現在一貫して合格していますが、ログも追加しており、引き続き監視します。

要約すると、私にとって、両方の原則の統合は、問題を表面化するためにフェイル ファストが不可欠であるということだと思います。しかし、いったんそれらが表面化すると、堅牢性とは、システムを危険にさらすことなく運用を継続するための透過的なパスを提供することを意味します。私はそれを提供することができ、そうすることで相手から好意を得ることができ、最終的にデータを修正することができました.

繰り返しますが、回答してくれたすべての人に感謝します。コメントを評価するには新人すぎますが、提示されたすべての視点に感謝します。

Answer 6

それは、発生しているエラーのクラスによって異なります。システムが壊れているということは、システムの他の部分に悪いデータを供給せずに続行できることを意味する場合は、与えられた入力が何であれ、全力を尽くして作業する必要があります。

私の考えでは、データの純度は稼働中のシステムよりも優先されますが、悪いデータが他の場所に伝播して他のシステムを破壊することは許されません。データを修正して続行できる範囲で、データは安全であり、システムを実行し続けなければならないという理論に基づいて実行する必要があります...

私は物事をデータ ストリームの観点から考えるのが好きです。悪いデータを渡すことは、ストリーム全体を汚染することです。実際の汚染と同じように、一滴がデータの川全体を台無しにする可能性があるため、これは悪いことです (1 つの要素が悪い場合、他に何を信頼できますか?)。しかし、同様に悪いのは、簡単に取り除くことができるものを見つけたために、流れを妨げ、何も通過させないことです. それをフィルタリングし、すべての段階で全員がフィルタリングされている場合、途中でいくつかの不純物が発生したとしても、反対側から明確でクリーンなデータが得られます.

Answer 7

それはトリッキーなものです。モジュールが不正なデータを受け取り、何もせずに戻っても問題ない場合は、ユーザーにエラーを表示するのではなく、エラー ログに書き込むことをお勧めします。

Answer 8

同僚からの質問は、「この問題を回避してみませんか」というものです。

不正なデータを検出して、ユーザーにエラーを報告することは可能だとおっしゃっています。これは通常のアプローチです-関数に送られるデータが悪いことがわかったら、すぐに失敗する必要があります（これは、私がここで読んだ他の回答からの推奨事項です）。

ただし、質問では、ソフトウェアが動作しているドメインを指定していません。入ってくるデータが間違っていることがわかっている場合、そのデータを再度リクエストすることは可能ですか? その状態から本当に回復できるのでしょうか？

ここで「ドメイン」が重要だと言いました。たとえば、ストリーミングされたビデオ データを表示するアプリがあり、ワイヤレス信号が弱くてストリームが破損している可能性がある場合、システムは「すぐに失敗」してエラー メッセージを表示する必要がありますか? それとも、問題の大きさに応じて、より質の悪い画像を表示し、必要に応じて再接続を試みる必要がありますか?

ドメインによっては、不正なデータを検出し、ユーザーに迷惑をかけずにデータの 2 回目の要求を行うことができる場合があります。(これは明らかに、データが2回目に改善されると予想される場合にのみ関連しますが、発生している問題は断続的であり、並行性に関連している可能性があると言っています)...

したがって、フェイルファストは良いことであり、回復できない場合に行うべきことです。そして、間違いなく悪いデータを広めるべきではありません。しかし、回復できる場合 (一部のドメインでは回復可能)、すぐに失敗することが必ずしも最善の方法とは限りません。