障害調査・インシデントレスポンスのためのログ設計

### このガイドの目的 システム障害時、復旧時間を短縮（MTTR短縮）するために必要なログの書き方と、調査手順を定義します。 ### 役立たずなログ vs 使えるログ - **NG**: `Error occurred.` (これだけでは何も分からない) - **OK**: `OrderProcessingFailed: order_id=123, reason=InventoryShortage, duration=150ms` ### 調査を高速化する3種の神器 1. **Request ID / Trace ID**: ユーザーの1クリックが、複数のマイクロサービスをどう流れたかを追跡するためのID。これが無いと「どこで詰まったか」を探すのに数時間かかります。 2. **Context**: エラーログには必ず「ユーザーID」「テナントID」「入力パラメータ」を含めてください。再現確認に必須です。 3. **Structured Logging**: JSONで出力し、「特定のテナントのエラー率」などを集計可能にしてください。 ### トラブル時の初動手順 1. **影響範囲の特定**: ログを `status >= 500` で検索し、発生件数と継続時間を確認。 2. **原因の切り分け**: 特定のサーバーだけか？特定のリリースバージョンからか？ 3. **詳細調査**: Trace IDを使って、エラーの前後のログ（Infoレベル）を確認し、ストーリーを再構築する。