回答。

分散ITシステムの発展の歴史の中で、エラーハンドリングと障害シナリオの問題はビジネスロジックに取って代わられ、長い間二次的な役割を果たしてきました。しかし、インフラの規模が拡大し、複雑さが増すにつれて、未整備のエラーハンドリングシナリオが大規模な障害やデータ損失を引き起こすことが明らかになりました。

問題は、複雑なシステムが多様な障害タイプを経験することです。例えば、特定のサービスの利用不可からデータの不整合、通信チャネルの部分的な障害まで。顧客は「障害」の意味を単に明白な故障（例：サーバーが利用できない）と誤解し、サービス間のエラーの連鎖やユーザーエクスペリエンスの劣化を無視することがよくあります。

効果的な解決策は、システムアプローチに基づいています：

• すべての可能な障害点を発見する。
• アーキテクト、QA、デザイナー、運用エンジニアと共に、それらが発生する包括的なシナリオを開発する。
• ビジネスとのシステム動作の合意（例：注文を保留することができるか、操作をキャッシュする必要があるか）。
• すべてのエラーメッセージと処理経路の明確な文書化。

主要な特徴：

• 致命的な障害だけでなく、ソフト/流動的な障害（例：外部サービスの一時的な不具合）の処理。
• UIおよび機能性の劣化シナリオの組み込み。
• 要件開発のすべての段階でのビジネスエラーと技術的障害の区別。

トリッキーな質問。

アプリケーションレベルの例外とインフラレベルの例外の違いは何ですか？

候補者はよくビジネスエラー（例：「ユーザーが見つからない」）を実際の障害（例：「データベースが利用できない」）と混同します。アプリケーションは常に2つのタイプの例外を明確に区別し、異なる処理戦略（ロールバック、通知、アラート）を提供する必要があります。

公開されていない内部APIのためにどのような障害シナリオをモデル化するべきですか？

障害シナリオは任意のAPIに関連しています。たとえ内部APIであっても、障害は常に発生する可能性があり（自動化のコントール内でも）、不正確または欠落したデータで正常に機能するために、明示的にモデル化する必要があります。

システムは最大のUXを維持するために、すべてのエラーをユーザーから隠すべきですか？

いいえ、エラーの完全な隠蔽はユーザーに誤解を与えます。情報提供（ユーザーが次に何をすべきかを理解できるように）と安全性（実装の詳細を明らかにしない）の間にバランスを見つけることが重要です。

一般的なエラーとアンチパターン

• 非形式化された障害処理（デフォルトのcatchに残されている）。
• 部分的な障害時の劣化シナリオの欠如（マイクロサービスの例では、機能しないカートが注文処理を完全にブロックする）。
• 「静かな」障害の蓄積を無視する（例外的な状況に対するアラートやモニタリングがない）。

実生活の例

ネガティブケース： 大規模なe-commerceプロジェクトで、システムアナリストはすべてのネットワークエラーの処理をアーキテクチャに任せました。緊急のアップデートやメールサービスの障害時に、システムは注文通知を送信せず、ユーザーは自分の注文が作成されたかどうかわからなかった。

利点：

• 要件の説明が簡素化された。

欠点：

• データの喪失（注文が作成されたことを証明できない）。
• 製品の立ち上げ後、サポートコストが増加した。

ポジティブケース： システムアナリストはアーキテクトと共に、メールキューの不具合、支払いゲートウェイの障害、検索サービスの劣化という各主要サービスのためのシナリオを個別にモデル化しました。顧客のためのユーザーフレンドリーなメッセージが記述されました。

利点：

• プラットフォームへの顧客の信頼を向上させた。
• オペレーショナルリスクを最小化した。

欠点：

• 文書の量とテストの複雑さが増加した。