回答。

質問の背景

マイクロサービスアーキテクチャおよび分散システムへの移行により、サービス間の相互作用中に発生するエラーの可能性と、その処理の複雑さが急増しました。初期のアプローチは、ネットワーク相互作用の不安定さを考慮していないことが多く、その結果、運用中に大規模なインシデントが発生しました。

問題

主な問題は、サービスの障害、機能の劣化、統合エラーの複雑なシナリオが要求事項に十分に形式化されていないことです。これにより、開発者はエラーハンドリングの決定を自主的に行う必要があり、ケースの多様性とテストの難しさを招いています。

解決策

効果的なエラーハンドリングの記述には以下が含まれるべきです：

• エラーのタイプの特定（ネットワーク障害、タイムアウト、サードパーティサービスの失敗、ビジネスロジックのエラー、データの不整合）。
• 各エラータイプに対する反応のシナリオの定義：再試行、トランザクションのロールバック、機能の劣化、アラート、ユーザーメッセージ。
• 故障テスト（フェイルオーバー、優雅な劣化）のための明確なシナリオの導入、特に非特定および連鎖的なインシデントを含む。
• エラーの契約およびフォーマットの文書化（例えば、エラー応答の標準JSON契約）。

主な特徴:

• サービス間でのエラーハンドリングのテンプレートの標準化。
• 機能劣化のシナリオの検証およびビジネスとの調整。
• エラーのトレーシングとログ記録の確保、インシデントの後分析のため。

意地悪な質問。

技術的エラーの処理を要求事項に記載することは必須ですか？開発者の仕事ではないのでしょうか？

必須です。エラーハンドリングのポリシーが反映されていないことは、動作上のエラーや誤解を引き起こすことがよくあります。システムアナリストは、エラー時の動作について明確にする義務があります。

非常に稀なケース（例えば、サービス間の部分的な接続切れ）も記載する必要がありますか？

はい、あまり発生しないエラーが最も複雑なインシデントを引き起こすからです。その影響はビジネスにとって重大である可能性があります。

ビジネスと合意しなければならないエラー時にユーザーに表示されるメッセージは必要ですか？

はい。正確で有益だが、過剰でも恐ろしいメッセージではないものは、ビジネスと合意されるべきです。そうしないと、ユーザー体験と忠誠心が損なわれます。

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

• 幸せなパスだけを説明し、障害シナリオを無視する。
• システムの劣化を考慮しない（バックアップシナリオが記載されていない）。
• ビジネスに対して調整されていないか、ユーザーにとって技術的に難しいエラーメッセージ。

実際の例

ネガティブケース：プロジェクトでは、サービス間のタイムアウト処理シナリオが説明されていませんでした。その結果、ネットワークの不安定さにより、サービスが応答なしで「ハング」しました。プラス：主なシナリオの迅速な実行。マイナス：生産環境での大量の障害、クライアントからのネガティブなフィードバック、「手動」でのインシデントのクローズ。

ポジティブケース：アナリストは、劣化シナリオと再起動、再試行、および正しいメッセージを文書化しました。プラス：障害時のサービスの高い安定性、事故の減少。マイナス：シナリオのアーキテクチャの設計により多くの時間がかかる。